Look through our portfolio and a pattern jumps out: almost nothing in it tries to do more than one job. WaterTracker tracks water. Easy Fasting tracks fasting windows. My Mustang tracks maintenance on one specific car. None of them have a social feed, a marketplace, or a dashboard of twelve features you'll use once. That's not an accident, and it's not a budget constraint dressed up as a philosophy — it's a deliberate bet about how people actually use their phones.
The anti-pattern we're avoiding
The default failure mode for a new app idea is scope creep disguised as ambition: "while we're building the water tracker, let's also add meal logging, and a social leaderboard, and workout plans." Each addition sounds reasonable in isolation. Stacked together, they turn a five-minute daily habit into an app that needs an onboarding tour, and they turn a clear App Store listing into one that has to explain four different value propositions in one subtitle.
Why narrow apps retain better
A user who searches "water tracker" already knows exactly what job they're hiring the app for. If the app opens straight into that job — no sign-up wall, no tab bar with four other features competing for attention — the time from download to first genuine use drops close to zero. That first successful use, repeated a few times, is what turns an install into a habit. Every extra feature between the user and that first successful use is friction that works against retention, even though it looks like it's adding value on a feature list.
There's also a search-intent argument that's easy to miss: the App Store rewards apps whose name, subtitle, and screenshots map cleanly onto a specific query. An app that's obviously "the water tracker" competes for "water tracker" searches far more effectively than a general wellness app that happens to include water tracking as one of nine features.
Where this doesn't apply
This isn't a universal rule. If the product is genuinely a platform — something meant to be a daily hub for several related tasks, or a business tool where users expect one login and one place for everything — bundling features together is the right call, and splitting it into five single-purpose apps would be worse for everyone. The point isn't "fewer features is always better." It's that every feature should earn its place by serving the same core job, not by being technically possible to add.
How this shapes how we scope a new project
Before any code gets written, we push a new project to answer one question clearly: what's the one job this app does, and what does a user's first thirty seconds inside it look like? Everything in the initial scope has to serve that answer directly. Ideas that don't — even good ones — go on a list for a possible version two, once the core job has proven it works. It's a small discipline, but it's the difference between shipping something a user finishes setting up and something they delete during onboarding.
None of this is really about minimalism as an aesthetic. It's about matching what an app does to the narrow, specific reason someone downloaded it — and resisting the pull to add "just one more feature" that quietly moves the app further from that reason with every release.