I'm Only Building Dead Simple Apps From Now On

I opened Bloons TD the other day to play a quick round.

The screen was wall to wall buttons. A daily challenge banner. A season pass popup. A currency reward I had to claim. A new event I had to dismiss. Then another modal selling me an upgrade pack. By the time I was looking at the actual map, I had tapped six things I did not want to tap.

I closed the app without playing.

It is a tower defense game. I wanted to place towers and pop bloons. That used to be the whole loop. Now the loop is wrapped in five other loops, and the original one is somewhere down inside, waiting for me to dig it up.

This is not a Bloons problem. This is every app I open.

The job to be done is three taps deep

Pick any app on your phone right now. Open it. Count how many things appear before you can do the thing you opened the app to do.

Banking app: a promo carousel about a new credit card before the balance. Streaming app: three rows of recommendations before search. Food delivery: a wall of paid placement before the restaurants you usually order from. Social app: a story tray, a creator subscription pitch, an explore feed, a “see what your friends are up to” prompt.

The actual product is buried. The shell around it has eaten the product.

I do not think the people who built these apps are bad at their jobs. I think the framing has rotted out from under them. Engagement is the metric, not job-completed. So every quarter another team gets staffed, another OKR gets set, another ribbon of UI gets added on top. Nobody is paid to remove anything. The apps grow rings like trees.

What I am going to do about it on my end

I cannot fix Bloons TD. I can fix what I ship.

From now on, every app I build does exactly one thing. No accounts. No settings screens. No in-app upsells. No notifications. No “while you’re here, why don’t you also.” If a feature does not make the core thing better, it does not ship. If the second feature is not strictly necessary, the app stays a one-feature app.

I already have one of these in the App Store and I like the way it feels.

Mic to Clipboard is my dead simple iOS app. One screen. One button. You tap it, you talk, and your words land in your clipboard. Paste them anywhere. There are no settings. There is no account. There is no history view. There is no premium tier. The whole app is the thing it does.

I built it because Claude Code on Bedrock does not expose microphone access and I was tired of typing every prompt by hand. So the app fixes exactly that one friction point. Nothing else. When I open it I am in for two seconds and out, which is exactly what I want from it.

The next thing I am building is a local events app. Same philosophy. You open it, you see what is happening near you tonight, you close it. No social feed. No RSVPs. No friend system. No “create an account to save events.” If you want to go, screenshot it or write it down. The app’s job is to tell you what is on tonight, not to become a daily habit.

Why one feature is a feature

There is a real argument here, not just a vibe.

It ships faster. A one-feature app is one or two weekends of work. A ten-feature app is a year of work, half of which is plumbing between features, navigation between screens, settings to control feature interaction, and edge cases where feature A breaks feature B.

Users understand it instantly. When the app does one thing, the user has nothing to learn. They open it, they see the thing, they do the thing. There is no onboarding because there is nothing to onboard them into.

The bug surface is small. Every feature is a place a bug can live. One feature, one place. Less code to maintain, less to break when iOS updates, less for me to forget how it works six months later.

Constraints are a feature. When I tell myself the app is only allowed to do one thing, I have to make that one thing really good. If I let myself add a settings screen, I would spend a week tuning the settings screen instead of making the core flow shorter. Forbidding the escape valves forces the work into the part that matters.

This is not anti-feature

I want to be clear about what I am not saying. I am not saying apps should never grow. I am not saying every app should be a single button with no settings.

I am saying: add the second feature when the first one stops being enough, not because the roadmap says Q3. Add the settings screen when users are actively asking for a setting, not before. Add the account system when there is a real cross-device need, not because the team’s OKR is “increase signed-in users.”

Most “features” do not exist because anyone needed them. They exist because somebody had to ship something this quarter and that was the cheapest thing to attach. Then it gets attached. Then it gets defended in the next quarter’s review because killing it would be admitting it was unnecessary. Then the app feels like Bloons TD.

The bar I am holding myself to

If a feature does not make the core thing better, it does not ship.

If the app cannot be explained in one sentence, the scope is wrong.

If the user has to read instructions, the design is wrong.

If I am tempted to add a settings screen, I should be tightening the defaults instead.

If I am tempted to add an account, I should be making the offline experience better instead.

If you have felt the same fatigue lately, opening apps that used to be useful and now feel like a department store, you are not imagining it. The apps actually did get worse. The good news is some of us are going the other way.

That is what I am building toward. Apps you open, use, and close. Apps that respect that you have something else to do today. Apps where the entire app is the thing it does, and there is nothing else in the way.