The Physical Button Project is deliberately general-purpose. A button press is just a timestamped event tied to a device ID and a position. What that event means is entirely up to you. Here are the use cases that shaped the design.
This is the original motivation.
Habit-tracking apps have a fundamental problem: you have to remember to open them. The behavior and the logging happen in different places, at different times. By the time you open the app, you've already forgotten whether you took your vitamins this morning.
A physical button placed at the point of behavior solves this:
- A button by the coffee maker: tap when you brew a cup
- A button by the water bottle: tap when you drink
- A button on the nightstand: tap when you take your vitamins
- A button next to the pull-up bar: tap when you finish a set
One tap. No unlock, no scroll, no confirm. The dashboard collects the data passively.
The modes feature makes this work for families. A device in the kitchen might have modes ["Dad", "Mom", "Son"]. Whoever is using the button rotates the encoder to select their name, then presses. The click is recorded with the mode attached, so the dashboard can show per-person breakdowns.
Kitchen device modes: Dad / Mom / Son
Button: "Water"
→ Dad presses Water while "Dad" is selected
→ Record: { device: "kitchen", button: "water", mode: "Dad", timestamp: ... }
A second use case that emerged once the system existed.
A makerspace has equipment scattered across a large floor. Knowing what was used, when, and by whom is valuable for scheduling, maintenance, and consumable budgeting — but sign-in sheets are ignored and dedicated apps are never used.
A button device mounted near each machine:
- Laser cutter — 3-button device:
Start session/End session/Used consumable - 3D printer bank — buttons labeled per printer; tap when you start and finish a print
- Filament rack — buttons per spool color; tap when you take some
- Tools cabinet — single button per drawer: "I took something from here"
The map view in the dashboard gives staff a floor-level picture of what's been used and when, without anyone having to file a report.
A much simpler version of the same idea.
A child gets a box with four big colorful buttons — Heart, Star, Diamond, X. The child decides what each one means to them. Maybe Heart means "I did something kind today." Maybe X means "I had a bad day." Maybe Star means "I read a book."
The pouches view in the dashboard lets a parent (or the child) arrange these buttons however they like — no grid required, just drag them into a layout that feels right.
The data is just data. You can look at it together as a family, or ignore it entirely and just let the kid press buttons. Either way is fine. The core system runs on the local network, these household use cases do not (and will never) require sending private activity data to a third-party service.
A button press is just an event. What the event represents is up to you:
- Medication log — tap when you take a pill; the timestamp is your record
- Baby care — feeding, diaper, sleep start/end; no app to navigate while holding an infant
- Equipment maintenance — "I oiled the chain" / "I checked the tire pressure"
- Mood journal — four buttons for four states; no words required
- Counter — how many times did the cat knock something off the table today
The point is not to build a perfect system for any one of these. The point is that a physical button in the right place gets pressed. An app on your phone often does not.
The next planned feature adds a microphone alongside a dedicated "record" button. While the button is held, the device captures audio. On release, the audio is transmitted to the server, which runs speech-to-text and stores the transcript as a timestamped note.
A button press + a spoken word = a hands-free, zero-friction reminder log. Press the button next to the mailbox and say "need stamps." Press it at the grocery store and say "out of olive oil." No phone, no app, no unlock.