Boring Software
July 2, 2026
On building BetterKey to do its job reliably enough that users can let go of the worry.
BetterKey is not an app that you need to open very much.
That has been one of the stranger things about building it.
In most software, opening the app is how you use it. People tap in, move through screens, and the interface proves itself through repetition.
BetterKey is closer to the opposite. You use it constantly. Every drive, every time you walk away from the car. But you rarely open it. Once it is set up, it comes along for the ride.
For that to feel ordinary, a lot has to happen. Shortcuts for scheduled locks. Live Activities. Silent push notifications. Motion & Fitness permissions. Drive and parking detection. Automated nightly locks. All of that work exists for a simple outcome: when the user stops driving and walks away, BetterKey should know enough to lock the car without the user opening the app.
I thought the hard part would be the car APIs, the background execution, the permissions, and all the small ways automation can fail on a phone.
The hard part is not locking the car. It is ending the user’s responsibility.
The user is trying to hand off a question:
Did I lock my car?
I know this question. I use home automation to lock the front door and turn off the lights at night. The car does not work like that. Some mornings I would get in the car for a run and see the doors had been unlocked overnight. Locking it slowly became a task I had to remember, one more thing after a long day with two dogs and a toddler.
That question sticks. Half an hour after parking, or in line for coffee, or halfway through the morning. Even after BetterKey has locked the car.
One night, just as I was about to doze off, the question surfaced. Had I locked the car? I reached for the phone, opened the app, and hit lock. The car was probably already locked. It was never about the lock. It was about the relief.
I set an automation to lock it at nine. The question stopped coming.
For the app to fade into the background later, I first need it to hold attention now. BetterKey needs an app to deliver the experience. It is where the user connects the car, grants permissions, configures behavior, and understands what the system is allowed to do. I have to earn enough confidence in that flow for them to enable the automation. Once they do, the app does not go away. It keeps running, watching, deciding, locking. The user just stops needing to open it.
That sounds strange if you measure software by engagement. It makes more sense if you measure it by responsibility removed.
Somewhere in the middle of wiring up Shortcuts, silent pushes, and always-on location, I realized I was doing the kind of work I have done for a decade: mobile infrastructure teams, build and release plumbing, platform code no one opens. Only this time on my own app. The user-facing screens are what I have to build to earn the permissions the automation needs.
Before BetterKey I ran the developer experience group at Tandem Diabetes Care, across mobile and embedded pump software. I sought that job out. Most people there either used the product themselves or had someone in their family who did. Every bug felt personal. One of the products included an insulin pump with no screen and an app that controlled it over Bluetooth. A device patients wore and trusted to do the right thing without watching it. When software controls hardware in a domain like that, trust is not decoration. The user has to believe the system will behave correctly without watching it every second.
BetterKey is not in that category. The stakes are different, and I do not want to pretend otherwise. But the discipline carries over. If software asks a user to stop personally verifying something, reliability is the relationship.
I still open BetterKey sometimes, when I want the car to lock in the moment, or to check on something. Most days it stays in my pocket. I get out with two dogs sprinting for the beach, a kid on my back pulling my sunglasses off my head, both my hands on leashes. Locking the door used to be one more task in that chaos. Now it happens without me.
Boring software is not careless or low effort. It is boring because it has removed a reason to keep checking.
That has become the most useful way for me to understand the category. Some software is valuable because it helps people do more. Some is valuable because it lets people stop carrying a task after the system has handled it.
Getting there happens slowly. One successful lock at a time. One uneventful return to the car at a time. One moment where the user almost checks, then does not.
Eventually the question stops appearing.
Engineer, founder, father. Whatever I am becoming, that is the software I want to make. One less thing to worry about.