Cutting Scope: What Unshipped Features Taught Me

When we talk about what an app costs, we always talk about the code that gets written. But the real cost is usually somewhere else: in the features that were built and never shipped, or that shipped and nobody ever touched.

I have lived through concrete examples of this in my own projects. A flow I spent weeks on and was technically proud of never made it into the first release because the rest of the product was not ready. Or a feature that did ship, that no user ever noticed, and that kept generating maintenance cost in every single release.

For a long time I saw narrowing the scope as a loss — like a list of “things I could not do.” Now I think the opposite: narrowing is the most valuable decision you make in a product.

Why scope grows on its own

Scope creep does not come from bad intentions or a lack of discipline. It is usually made up of steps that look perfectly reasonable:

• “While I am already in there.” When you are building one screen, building a similar one looks cheap. But the second screen also has to be tested, maintained, translated, and debugged.
• “Users will ask for it.” Trying to satisfy a hypothetical request before you have any users at all. Most of those predictions do not hold.
• “The competitor has it.” A competitor's feature may make sense in the context of their audience and their history. It may not in yours.
• “It is technically interesting.” This is the one that gets me most often. A problem that is fun to solve is not the same as a problem that needs solving.

The three questions I use

When deciding whether a feature goes into the first release, I ask three questions in order:

1. Does the product become useless without this? If the answer is “no, it just gets weaker,” the feature is not in the first release. In Vakti Geçmeden, the core of the product is “seeing and buying a nearby business's end-of-day items.” Without that flow there is no app. Everything else — favorites, history, filters, notification preferences — can wait.

2. Can I do this manually? A process being automated is a different thing from the process existing at all. In the early stage, approving business applications by hand is far cheaper than building a full admin panel — and without seeing real applications, you cannot know what the panel should look like anyway.

3. Will this get harder to reverse if I postpone it? This is the question that puts a limit on cutting. Things like the data model, the authentication structure, and the multi-language infrastructure are decisions that are expensive to add later. I do not postpone those — I set the infrastructure up correctly from the start and cut the features that sit on top of it, not the foundation.

The difference between cutting and postponing

I learned this distinction late. There are two different ways to leave a feature out of scope, and when they get mixed up the product suffers.

The most damaging thing is leaving a trace of a postponed feature in the interface: a tab that does nothing, a screen that says “coming soon,” a button that does nothing when tapped. Users do not read that as a missing feature, they read it as a broken app. Anything that is not live should not be in the interface either.

How I avoid cutting the wrong thing

The risk of narrowing is cutting so much that the product stops making sense. The method I use to prevent that is thinking about features not one by one, but as a flow.

There is a journey the user has to complete in the app: they open it, search, find, take an action, and see the result. Every step of that journey is a link in a chain. Cut one link and the chain breaks — none of the remaining links have any value left.

So I make the cutting decision like this: anything outside the chain can be cut, nothing on the chain can be. But the steps on the chain can be simplified. The search step has to stay; but search still exists without advanced filters, sorting options, and saved searches.

I keep a record of what I cut

I keep everything I leave out of scope in one place — the name of the feature, why it was postponed, and under what condition it should come back. It has had three benefits:

• I do not have the same argument again from scratch two months later; the decision and its reasoning are written down.
• When a request comes in from a user, I can check whether it is already on that list. The same request coming in again is a real signal that changes priority.
• I do not have to think about what to do after launch; the list is already sitting there.

The side effect of this list is psychological: cutting something does not feel like losing it. You are only changing its position in the order.

What happened after launch

Across the projects where I narrowed the scope, I saw the same thing repeat: after launching, I never built some of the features on the list. Not because I forgot them — because after seeing real users, I understood those features were unnecessary.

The real gain here is this: if I had put those features in the first release, I would never have learned they were unnecessary. Admitting that a feature which has been written, shipped, and maintained is unnecessary is far harder than never having written it.

Narrowing the scope is not doing less work. It is learning which work is worth doing by looking at reality instead of guessing.

• Product
• Career
• Mobile Development
• Planning