The advice every solo developer eventually hears is to ship more features to stay competitive. After about fifteen months and eleven releases of a one-person iOS app, I have come to think that advice is quietly dangerous for people like me, and I have started doing the opposite. I now say no to most of the feature requests I get, including the ones that come from me.
TL;DR
- For a team, the real cost of a feature is spread across several people and years; for a solo dev, the person who builds it is also the one who supports it, re-tests it after every OS beta, and explains it forever.
- So I made "no" the default. A feature has to earn a yes against its standing cost, not its build cost, and I keep a written list of what I refused where other people keep a roadmap.
The advice, stated as fairly as I can
Let me argue the other side first, because it is not stupid.
Features are how most software earns its keep. Users leave products that feel frozen. A visible roadmap signals momentum to the people deciding whether to trust you. When a competitor ships the thing your users keep asking for, "we chose to stay small" reads as a press release for your own decline. And there is a real craft satisfaction in building: shipping a feature feels like progress in a way that fixing the same three bugs does not.
All of that is true. It is also advice that was minted inside teams, and mostly inside teams with money. When a five-person squad ships a feature, the person who wrote it is not the only one holding it afterward. There is someone on support who fields the confused emails, someone on QA who re-runs the regression, someone on call at 2am, and a backlog owner who decides when it gets revisited. The build cost is loud and shared. The ownership cost is quiet and distributed. Nobody in that room feels the full weight of the thing they just shipped, which is exactly why they can keep shipping.
I do not have that room. I hit the same mismatch the first time I tried to run my work through a proper issue tracker, which I wrote about in the issue tracker was built for a team I don't have. The tool assumed colleagues I did not have. Feature-first advice makes the same assumption.
Why is a feature so much more expensive for one person?
Because I am every seat in that room at once.
When I ship a feature, I am also the support desk that will answer for it, the tester who re-checks it against the next iOS beta, the designer who now has one more screen to keep coherent, and the future maintainer who will open that file in eight months having forgotten how it works. The day I ship a feature is the cheapest day that feature will ever have. Every day after is standing cost.
Here is the split I wish someone had drawn for me before I started saying yes to things:
| A feature's cost | Build (one-time) | Standing (recurring, and all mine) |
|---|---|---|
| Code | A few days of work | Re-read and re-tested every OS beta, forever |
| Support | None yet | Every edge case becomes an email in my inbox |
| Interface | One new screen or toggle | One more thing to explain, and to keep consistent with the rest |
| Attention | Fun while it is fresh | Competes with every other feature I already own |
| Review risk | — | One more surface Apple can reject an update over |
The left column is what people estimate. The right column is what actually runs your life as a solo dev. I have shipped features that took two days to build and then quietly taxed me for a year. I have refused features that would have taken two days to build and saved myself that same year without ever noticing, because you do not get a notification for the support thread you never had.
The refusals I'm glad I made
Concretely, here is what I have said no to, and what saying no bought me.
Folders and tags. The single most requested organizing feature, and the one I am most relieved I skipped. Every note app that adds them inherits a second, permanent job: teaching people a filing system, then supporting the people who file wrong. My app has none. The whole model is one stream, newest first. That refusal is why my settings screen still fits on one page with six toggles on it, and why I have never once answered an email about a note someone "lost" in a folder.
Cross-device account sync. Real demand, real value, and a genuinely hard thing to own alone: accounts, a server, conflict resolution, a privacy surface, and a support burden that never sleeps. Saying no kept me out of a category of 2am problem I am not staffed to have. People who need that reach for it elsewhere, and I am at peace with losing them.
Rich text, themes, a home-screen widget with live counts. Each is a small yes that becomes a permanent line item on the regression list. I turned all three down. The app does one thing, and the number of ways it can break is bounded by how few things it does.
The pattern under all of it: the features I refused are invisible in the product and enormous in my calendar. Nobody writes a review thanking you for the complexity you spared them.
When "no" is just fear wearing a strategy
I have to be honest here, because "I keep it simple on purpose" is the most flattering possible cover story for "I was scared of the hard thing."
Some of my refusals were not discipline. They were avoidance. There was a feature several users needed that touched a part of iOS I found intimidating, and for two releases I told myself it was "out of scope." It was not out of scope. It was inside my discomfort. When I finally built it, it was fine, and I had made real people wait on my nerves. Minimalism can be a philosophy or an alibi, and from the inside they feel identical.
The other failure mode is subtler: refusing things until the product quietly stops being alive. I have watched myself do a gentler version of that, and I wrote about the time I removed too much in I killed every meeting as a solo dev, and half of it backfired. Subtraction is a tool, not a personality. A codebase can die of too many features. It can also die of an owner who has fallen in love with saying no.
So the goal is not zero features. It is refusing by default while staying honest about which "no" is strategy and which is flinching.
The test I run before saying yes now
I stopped judging features by whether they would be nice to have. Everything is nice to have. I judge them by their standing cost, with one question:
Would I still want this if I had to maintain it, alone, through the next three iOS versions, and it brought in no new users at all?
That framing strips out the fun of building and the fantasy of the users it might attract, and leaves only the part I will actually live with. Most requests do not survive it, including most of mine. The few that do tend to be the ones that make the core thing better rather than add a new thing beside it. Those are worth the standing cost. I have shipped a handful of features that passed this test, and they are the only ones I have never regretted.
What I actually do instead of a roadmap
I keep a "no" list.
It is a plain file of features I have declined, each with one line about why. It does two things a roadmap cannot. It lets me say no quickly and consistently, because the reasoning is already written down and I am not relitigating it every time someone asks. And it is honest in a way a roadmap is not: a roadmap is a list of debts you intend to take on, while a "no" list is a record of the ones you chose not to. When I get the same request three times, I move it from the no list to a much shorter "maybe, and here is the standing cost" list, and it has to pass the test above to graduate from there.
The result is an app that does less than almost everything it competes with, shipped by one person who is still standing after fifteen months. I think those two facts are the same fact.
A few questions I get about this
Doesn't this just mean your app stays small forever?
Probably, yes. Small is not the failure mode I am worried about. The failure mode I am worried about is an app so wide that one person can no longer hold all of it in their head, which is the moment solo maintenance quietly becomes impossible.
How do you tell users no without losing them?
Sometimes I do lose them, and I have made peace with that. But most people are fine with "that is not what this app is for" if you say it plainly and fast. What they hate is silence, or a "great idea, on the roadmap!" that never arrives. A clear no ages better than a soft maybe.
Isn't "do one thing well" just an excuse to do less work?
It can be, and I said above where it was exactly that for me. The difference is whether the thing you kept is actually done well. Refusal only earns its keep if the narrow core is genuinely good. Otherwise you have not built a focused product, you have built an unfinished one.
If you ship alone: what is the one feature you are most glad you never built, and what do you think saying no to it actually saved you, in support or in sanity? I am collecting these, because the honest ones are more useful than any roadmap.
I'm a solo developer who has spent about fifteen months building a deliberately small iOS capture app. I post here every few days about the unglamorous parts of shipping alone, this one included.
