One App, One Job: Why I Don't Build a Super-App

I get some version of this suggestion every few months: “You should put budgeting, hydration, and reminders in one app — more value per install, one login, more screen time.” It’s not a bad idea in the abstract. It’s just not one I build, and the reasons are worth writing down, because they’re the same reasons I keep making decisions about every app in the lineup.

The pressure to merge is real, and it isn’t about the user

Super-apps don’t happen because someone sat down and designed the best possible experience for tracking your water intake and your grocery list in the same place. They happen because merging is good for the business, not the person holding the phone. One install instead of six. One login you can build a profile around. One app icon competing for a home-screen slot instead of six. Every metric that matters to growth gets better when everything lives under one roof.

None of that is evil. It’s just optimizing for a different thing than “does this help you finish the task and put the phone down.” A grocery-tracking screen buried three tabs deep inside a finance app isn’t more useful because it shares a login with your budget — it’s just harder to find.

What a merged app actually costs the person using it

Open a genuine super-app and the tell is always the same: a home screen crowded with icons for features you’ve never touched, permission prompts for things unrelated to what you opened it for, and a search bar because navigation stopped working as a map a long time ago. The app remembers you, but you can no longer remember it — what it’s for, where things live, what it’s going to ask you for next.

There’s a subtler cost too. Mixing domains mixes data. A reminders app that also does budgeting has to decide what a “notification” even means across two unrelated jobs, and the answer is usually a settings screen with forty toggles nobody reads. Every feature you don’t use is still there, still loaded, still a permission the app requested and you granted without quite meaning to.

What it costs the person building it

This part gets skipped when people evaluate super-apps from the outside, but it’s the half I actually live in. I’m one person. Granyn tracking your spending and Hydrame reminding you to drink water have nothing to do with each other — different data models, different notification cadence, different edge cases, different people using them for different reasons at different times of day. Bolting them into one codebase doesn’t save effort; it multiplies it. A release for the hydration reminder now has to be tested against the budgeting screen too, because they share a binary. A crash in one feature takes down the whole app in the store’s crash reports, muddying the signal for both. Onboarding has to explain two unrelated things to someone who came for one.

Small, separate apps mean a bug in one has a blast radius of exactly one app. A design decision I regret costs me one rewrite, not a migration across six unrelated feature sets bolted onto a shared shell. And critically: I can say no to a feature request for Granyn without it becoming a debate about whether it belongs in “the app,” because there’s only one thing Granyn is.

The test I actually use

Before adding anything, I ask a plain question: could a stranger explain what this app does from its icon and name alone, after using it once? If the answer starts needing a “well, it also—”, that’s the feature that belongs in a different app, or doesn’t belong at all. This is why OldSchool only does medication reminders, Stocky only tracks what’s in your kitchen, and Mintly is a focus timer and nothing else. Not because I lack ideas for what else they could do, but because every “also” is a small tax on the one thing the app was actually good at.

Where sharing does make sense

None of this means the apps are built in isolation from each other. They share a design language, so switching between them doesn’t feel like relearning software. They share the same local-first, no-account architecture, so the privacy story is identical everywhere. They share internal libraries for things like notification scheduling and backup/export, because that’s plumbing, not a feature a user is choosing between. What they don’t share is a single database, a single onboarding flow, or a single reason to open the app. That line — shared infrastructure, separate purpose — is the whole strategy.

A super-app is a bet that convenience beats clarity. I’m betting the other way: that an app you fully understand in five seconds is worth more than an app that does five more things you’ll use once.