Every feature I add, I maintain alone forever. So I stopped.

dev.to

28 Aug 2026 · Business

7 min read → 2 min

A solo iOS developer argues that new features should be judged by their lifetime maintenance burden, not their build time. The piece proposes defaulting to no, using a standing-cost test, and keeping a written list of refused features.

For a solo developer, a feature's real cost is its standing cost, not its build cost

Every feature ships with recurring maintenance, support, re-testing, and review risk that one person owns alone forever

The day a feature ships is the cheapest day that feature will ever have

Every day after adds recurring maintenance that one person owns alone forever

Feature-first advice was minted inside teams, where ownership cost is quiet and distributed across support, QA, on-call, and backlog roles

A solo developer is every seat in that room at once

The cost split is build versus standing cost:

INDEX

Some features took two days to build and then quietly taxed a full year

Refusing a two-day feature can save that same year without any visible signal

Solo developers should make no the default, and a feature should earn a yes against its standing cost rather than its build cost

Skipping folders and tags avoided teaching users a filing system, kept the settings screen to one page with six toggles, and prevented emails about notes lost in folders

Skipping cross-device account sync avoided accounts, a server, conflict resolution, a privacy surface, and 2am support problems that one person cannot staff

Turning down rich text, themes, and a home-screen widget with live counts kept the app's failure modes bounded by how few things it does

A written no list works better than a roadmap for a solo app

It records declined debts, speeds consistent refusals, and only repeated requests move to a shorter maybe list

Some refusals were avoidance rather than discipline, including a feature delayed for two releases because it touched an intimidating part of iOS

Refusing too much can make a product stop being alive

Subtraction is a tool, not a personality. A codebase can die from too many features or from an owner who loves saying no

A clear no loses some users, but it ages better than silence or great idea, on the roadmap that never arrives

Do one thing well only works if the narrow core is genuinely good

Otherwise the product is unfinished rather than focused

An app that does less than most competitors can remain maintainable by one person after fifteen months, and those two facts are linked