What We Are Not Building: Cutting Scope Is Harder Than Adding Features

The hardest decision in a software project is not adding something to the list but removing something from it. Adding pleases everyone: the client gets what they asked for, the team builds something new, sales finds another bullet point. Removing disappoints someone, and nobody gets to be the hero in that moment. Yet what decides a product's fate is usually the list of things not built — because everything built becomes a burden to maintain, update and test forever.

Scope creep is insidious because every item looks reasonable on its own. 'What if there were a report for this', 'shall we add a filter there', 'could this be configurable from the admin panel' — none of these is absurd. Put together, they produce a product where nothing is fully mature. A product that does twenty things adequately gets used less than one that does five things perfectly, because a user remembers not the average but the five things they use most.

This article is not a guide but a position. We will describe how we cut scope in our own products, which features we deliberately keep switched off even though the code side is ready, and what saying 'soon' has cost us. You may disagree; but every one of these decisions is applied in products that are live, not in theory.

Every product has a core flow without which the product does not exist. In business software it is the chain from taking an order to closing the bill; in a work tracker it is a request becoming a record, being owned and being closed. The practical test for identifying the core flow is this: without this step, is the product still useful? If the answer is yes, that step is not core.

Once you make that distinction, the scope argument simplifies itself: the core ships with every installation, and the rest can be switched on or off. That is exactly what we did in our own hospitality product — menu, orders, tabs and roles come with every setup, while the remaining modules turn on according to the type of business. A small café starts with three modules; a multi-branch chain grows on the same core. Nobody wanders among forty screens they will never use.

The most important architectural consequence of this approach is that the on/off decision lives in one place. Whether a module is enabled is decided by a single gate, not by small checks scattered across screens. Otherwise, by the sixth month nobody knows which screen appears under which condition, and a module everyone believes is off keeps leaking through somewhere.

Postponing a feature is a deliberate decision: it will be built, just not now. Skipping is indecision: it was discussed, never concluded, and nobody is tracking it. From the outside they look identical — the feature is absent — but one is part of the plan and the other is debt. Keeping that distinction written down inside the team also preserves the answer to 'why didn't we build this' six months later.

A concrete example: our work tracking product still has no file attachments. The storage layer is installed and running, so the obstacle is not technical. The reason for postponing is design: the decisions about how an attachment binds to a record, what the size limit is, and who can see which attachment were unfinished. A half-built attachment system is more harmful than none at all — because people trust it and upload files.

A second example in the opposite direction: for one product we decided not to open a third admin panel. There was demand, it made sense, it was feasible. But a separate panel meant a separate sign-in, a separate deployment, a separate theme and separate permission maintenance — and its user was the same person anyway. So we put it in the 'never going to build' box and distributed the content and requests across two existing surfaces. That is not postponed work; it is a closed topic.

The most practical form of a scope conversation is three boxes: in this release, not in this release but on the roadmap, and never going to be built. Teams working with two boxes always skip the third, and that is where most misunderstandings come from. Saying 'never' takes nerve but is the greatest kindness to a client, because it frees them from waiting for something that is not coming and lets them solve it another way if they must.

The third box has an internal benefit too: it protects the team's energy. Every unclosed topic returns at every meeting, and the same argument is had again each time. Once decided and written down, the argument ends. We also write down the reasoning behind closed topics — because in six months conditions may change and the topic may reopen, and then the old reasoning becomes an input to the new decision.

On our product pages we mark unbuilt features plainly as 'soon'. This has a short-term cost: on someone else's list that feature sits unmarked while ours carries a caveat, and a person comparing the two side by side may think we are behind. We pay that cost knowingly, because the alternative's bill is far higher — when a feature assumed to exist turns out to be missing after delivery, what gets debated is not one feature but the whole project.

The second benefit of the 'soon' marker is internal: the list becomes the roadmap itself. If a module sits in the catalogue as forthcoming, building it does not depend on someone remembering it one day; it is visible debt. In our hospitality product's catalogue fifty modules are live and six are marked as coming — and those six items set the agenda of the roadmap meeting on their own.

Let us set a limit: 'soon' is not a promise of a date and must not be presented as one. A promise with a date that is not kept is worse than no promise at all. When we say 'soon' we are saying it is on the roadmap; and when it is ready, announcing it is part of the job. Rather than hiding uncertainty, stating the uncertainty honestly is the most defensible position.

The decision to cut scope belongs to the business owner, but the options must be produced by the developer. The developer says 'this is three weeks of work'; the owner says 'I cannot wait three weeks — which half can I have in two days?'. Without that dialogue, one of two bad outcomes follows: either everything gets built and the project stretches, or the developer cuts on their own judgement and the most critical part disappears.

The practical way to produce options is to present every request in three sizes: the full version, the version that does the job, and the workaround. For a reporting request, the full version is a flexible report engine, the job-doing version is three fixed reports, and the workaround is exporting the data and looking at it in a spreadsheet. Once the three costs sit side by side, the decision stops being an argument and becomes a choice.

Recommending scope cuts to clients while never applying them to yourself is an easy trap. While building our own corporate site we applied the same discipline, and after launch we removed two pages entirely. The reason was not that they were bad; their content already sat better on other pages, and keeping them as separate pages only crowded the menu.

Deleting a page is psychologically easier than deleting a product feature, but it carries the same logic: every page is a burden to update, translate and keep consistent. On a site publishing in four languages that burden multiplies by four. A page kept 'in case someone searches for it' sits there for years in its stale form and makes the company look messier than it is.

If date and scope are both fixed in a project, the only thing left to flex is quality — and when quality flexes, the first to notice is not the client but the team maintaining it six months later. So at the start of every project we discuss plainly which one is fixed: does the date matter, or does the scope? When the answer to both is 'both', in truth neither has been fixed.

If the date is fixed the method is clear: the scope gets ordered and whatever fits by the date is delivered. For that to work the list must be prioritised and dropping the bottom items must be acceptable. If the scope is fixed, the date stops being an estimate and becomes a range; saying 'between these two weeks' instead of naming a single day is both more honest and more manageable.

The worst scenario is a project where the date is assumed fixed but nobody ordered the scope. When the last two weeks arrive, the team decides what to drop in a moment of exhaustion — and decisions made then usually pick whatever is easiest to remove, not what matters least. Ordering the list up front takes that decision away from the delivery week and hands it to a plan made in advance.

'I want all of it' is usually not a request but an expression of distrust: the client believes adding things later will be impossible or expensive. The right response is not to argue the list shorter but to show that adding later genuinely works. A modular structure is the technical counterpart of that conversation: 'let's not build this now' only becomes credible alongside 'we can switch it on whenever you want'.

The second method is to discuss cost per use rather than per feature. Saying 'this report is three days' stays abstract; saying 'this report is three days and will be used once a month by one person' makes the decision itself. Putting the numbers side by side turns the conversation from persuasion into arithmetic done together.

The third is to present the first release as an experiment rather than a promise. Once it is live you can see which screens are actually used, and it often turns out that a feature everyone insisted on is opened by nobody. A scope conversation held after that data exists goes far more smoothly than the one at the start of the project.

The first question we ask when deciding whether to keep an item in scope: does the product work without it? If yes, the item is not in the first release. The second: how many users will use this, and how often? A screen used once a month by a single person is usually not a screen at all but an export, or a line in a request queue.

The third question concerns reversibility: is adding this later expensive? Decisions touching the data model are the ones that are expensive to add later; adding screens and reports is cheap. So in the first release we try to get the data model as right as possible while keeping the number of screens as low as possible. A wrong screen gets deleted; a wrong data model demands a migration.

The fourth and most often skipped question: who will maintain it? Every feature keeps living after it is written — it gets updated, tested and repaired when it breaks. A feature with no maintenance owner turns, within a few years, into a region nobody dares touch. Looking only at the cost of building when deciding scope is looking at the visible part of the iceberg.

Scope must be written down, but it does not have to be long. A thirty-page specification usually becomes a text neither side has fully read, then gets scanned like a lawyer when a disagreement arises. A one-page scope document can be read together at every meeting: three boxes (in this release / on the roadmap / never), items in each, and a one-sentence acceptance criterion beside each item.

The most important property of that document is being alive. Scope changes during a project — and changing is normal; what is abnormal is the change not reaching the document. Showing, in the same document, which item left when a new one entered is the mechanism that naturally balances the 'we want everything' conversation. An addition is always a swap.

Add a date too: when the document was last updated. The most dangerous state for a scope document is everyone looking at a different version. One page that lives at a single address, carries a date and is discussed together always beats five copies circulating by email.

After the first release the scope inevitably grows; the question is not whether but according to what. The healthiest input is usage: which screens get opened, which lists stay empty, which operations are abandoned halfway. The second input is support records — the same question asked three times is a stronger signal than a feature request.

The most dangerous form of growth is features added at one user's insistence. A screen written for one person sits in everyone's menu and becomes everyone's maintenance burden. The question to ask instead is: can we solve this need inside something that already exists? The answer is usually yes — a filter, an export or a setting solves it better than a new screen.

Finally, plan for shrinking as much as for growth. Removing screens nobody uses, once a year, is the only way to keep a product light; otherwise the menu lengthens every year and the learning curve rises for new users. Deleting is harder than adding, but it is the only operation that keeps a product from ageing.

Cutting scope does not shrink a product; it focuses it. Defining the core flow and making the rest modular, distinguishing postponed from skipped, bringing the third box — 'never going to be built' — into the conversation, and marking plainly what is missing: none of this makes the product smaller, it makes it more trustworthy. Promising less and delivering more always beats promising more and delivering less.

We pay the price of this position too: there are items marked 'soon' on our product pages, and someone comparing lists may read that as a shortfall. We still have no intention of changing it. We believe the thing most worth discussing at the start of a project is not what will be built but what will not — and we are ready to have that conversation with you.