Why Focused Apps Beat Bloated Ones
Feature bloat kills more apps than missing features ever did. How a small studio uses focus as a competitive weapon against bigger, better-funded teams.
Every founder eventually hits the same fork in the road. A handful of users ask for a feature you didn't plan. A competitor ships something flashy. A board member forwards a Product Hunt launch with the subject line can we do this? The path of least resistance is to say yes to all of it. That path is also how most apps die.
At Sépia we build small, sharp mobile apps. MyoScore does one thing: it scores muscle development from a photo. PrettyType does one thing: it reads your face and tells you something useful and honest about it. We have turned down dozens of perfectly reasonable feature requests, and it has made the products better, not worse.
Bloat is a tax you pay forever
The seductive lie of feature bloat is that each feature is a one-time cost. You build it, you ship it, you move on. In reality every feature you ship is a permanent liability. It needs to be maintained, tested, documented, localized, and explained. It widens the surface area for bugs. It competes for space in your onboarding, your settings screen, your support inbox, and most importantly, the user's attention.
A feature is not free when you ship it. It is free when you delete it.
The math gets brutal for a small team. If you have three engineers and forty features, no feature gets real love. Each one rots a little. The app starts to feel like a junk drawer where everything is technically present and nothing works the way you remember.
Focus is a positioning strategy, not a constraint
People talk about focus as if it were a sacrifice you make because you lack resources. We see it as the opposite. Focus is the thing that lets a two-person studio beat a forty-person team. The big team has to serve everyone. We get to serve someone.
When PrettyType reads exactly one thing and reads it well, the value proposition is a single sentence. A single sentence is something a user can repeat to a friend. That word-of-mouth loop is the only growth channel a bootstrapped studio can actually afford, and it runs on clarity.
- A focused app is easier to explain, which makes it easier to market.
- A focused app has fewer screens, which makes it easier to design.
- A focused app has less code, which makes it easier to keep alive.
- A focused app makes one promise, which makes it easier to keep.
How we actually say no
Saying no is a skill, not a personality trait. Here is the filter we run every request through.
- Does it serve the core promise? If MyoScore's promise is an honest muscle score from a photo, a social feed does not serve that. A more accurate scoring model does.
- Would removing the rest of the app to keep this feature make sense? If the answer is laughable, the feature is a distraction.
- Are users asking for the feature, or for the outcome? People ask for a button. What they want is a result. Often the result can be delivered without the button.
That last point matters more than any other. Users are excellent at describing their pain and terrible at designing solutions. When someone asks for a dashboard, they rarely want a dashboard. They want to feel in control. There are usually ten ways to deliver that feeling and only one of them involves building the thing they literally asked for.
The quiet cost of the feature you didn't build
There is a real version of this argument that goes too far. Some teams use focus as an excuse for laziness, shipping a thin app and calling restraint a virtue. That is not focus, that is neglect. The discipline is not in doing less. It is in doing one thing to a depth nobody else will bother with.
The honest scoring model inside MyoScore took far more engineering than any feed would have. The face-reading logic in PrettyType is the product, not a feature of the product. We poured the energy we saved by saying no into making the single yes undeniably good.
If you are building something small right now and feeling pressure to add, add, add, consider the inverse exercise. Open your app and ask what you could remove this week. The answer is almost always more interesting than the next thing you could build.
Comments 3
Counterpoint though: sometimes the bloated competitor wins because enterprise buyers want a checklist of features. How do you handle that pressure when the buyer isn't the user?
The distinction between asking for a button vs asking for the outcome is the whole game. Going to steal your three-question filter for our next planning session.
We learned this the hard way. Spent a year adding a CRM, a calendar, and a chat to our app. Churn went up. Ripped it all out, churn dropped. Wish I'd read this two years ago.