Scope Is the Real Product
17 March 2026
There's a specific kind of productivity that feels good and does damage. You're in a flow state, shipping features, closing tickets. The app is growing. The backlog is shrinking. Everything looks like progress.
Then you show the product to a new user and watch them get confused by an option they didn't ask for, a setting they don't understand, a workflow that only makes sense if you already know why it exists. The features are individually defensible. Together, they've made the product harder to use than it needs to be.
That's scope. Not a planning problem — a compounding problem.
The pull of "yes"
When you're the only developer, every feature request is technically possible. There's nobody to push back, no roadmap meeting to survive, no PM to say "not this quarter." The only person who can say no is you — and you're also the person who thought of it, or the person who heard a user ask for it, or the person who's been thinking about it for two weeks and is pretty sure it would be great.
This is the unique vulnerability of solo and indie work. Teams have friction that filters bad ideas before they reach the codebase. Solo developers have to manufacture that friction themselves, deliberately, as a practice.
The discipline isn't natural. It runs against the instinct to build, to help, to improve. Most of the ideas in the backlog are genuinely good ideas. That's exactly what makes them dangerous.
What scope actually costs
The build cost is the part you see. A new feature takes a week, you ship it, done. What you don't see is what you've added permanently to the system.
Every feature is a new surface to maintain. Edge cases you didn't anticipate. Interactions with the features that come after it. Bugs that trace back to two features that work correctly in isolation and incorrectly in combination. Support questions from users who found the option and don't know what it does.
The clearest version of this I've experienced: a messaging feature in a product I was building that needed a "priority" flag on messages. A reasonable ask — some messages are more important than others. I built it. It worked. It also meant that every surface showing messages had to decide how to render priority: the inbox, the notification, the search results, the export. A minor flag became a cross-cutting concern that touched more of the system than any single feature had a right to.
The users who requested it used it occasionally. The complexity was invisible to them but present everywhere in the code — not as a burden you could point to, just as a reason every message-related change took slightly longer than it should have.
The test before you build
Before adding anything to a product now, I run through two questions.
The first: can I describe this feature to a user in one sentence, and will they immediately understand why they'd want it? If the explanation requires context, or a caveat, or "it's like X but for the case when Y" — that's a signal the feature is solving a problem that hasn't been properly defined yet.
The second: what does the user do today without this? If the answer is "they work around it in a way that takes thirty seconds," the feature is probably not worth building. If the answer is "they can't do the thing at all," it might be.
These aren't perfect filters. But they slow down the decision, which is usually enough. Most features don't survive a week of thinking about them carefully.
The backlog isn't a to-do list
The most useful reframe I've found: the backlog is a signal, not a queue.
A growing backlog doesn't mean you're behind. It means users care enough to tell you what they want, which is valuable information about who they are and what they're trying to do. The goal isn't to empty it. The goal is to understand it well enough to make deliberate decisions about what stays out.
The features you don't build are as much a part of the product as the ones you do. A product that does one thing well and stops there is easier to learn, easier to support, and easier to extend later when you understand the problem better. A product that does everything eventually does nothing particularly well.
The product you shipped is the one you kept small enough to ship. The version that had everything in it is still in the backlog.