How We Decide What Not to Build

Subtraction is the skill

Anyone can add features to a scope. The value an experienced supplier adds is knowing which ones to remove — and being willing to say so when the client is enthusiastic about them.

Typically a third of an initial scope does not survive discovery. That third is the timeline and the budget, and cutting it is the highest-leverage work in the project.

The question we ask about every feature

What happens if this is not there? Three kinds of answer:

1. “The core job cannot be done.” It stays.
2. “Someone has to do a manual step.” Count how often. Under a few times a week, the manual step is usually cheaper than the feature.
3. “It would be nice to have.” It goes to phase two, where about half of them are never mentioned again.

The features nobody ever mentions again after launch are, by a distance, the largest saving available on any project.

The ones that rarely survive

• Elaborate settings. Built because someone might want it configured differently. Almost always used at the default.
• Dashboards designed before launch. Nobody knows which numbers matter until the system runs. Ship an export first.
• Bulk operations. Frequently requested, rarely used, and expensive because of the error handling.
• Full audit trails on everything. Audit what matters legally or commercially; auditing everything is storage with a report nobody reads.
• Multi-language before a second market exists. Real cost now for a hypothetical later.
• Role permissions for roles that do not exist yet.

What we defend even when clients want to cut it

• Error handling on the paths that touch money or customers
• The ability to correct a mistake — every system needs an undo somewhere
• Logging sufficient to diagnose a problem after the fact
• Testing on the business logic
• Accessibility basics

These are the things that look like savings in a quote and cost multiples of the saving within a year. We will argue for them and, if a client insists, note the decision in writing rather than quietly complying.

Deferring properly

Deferred is not deleted. Every cut feature goes on a written list with the reason and the trigger that would bring it back — “build this when more than twenty users need it”, “revisit after three months of real data”.

That list is reviewed at the ninety-day mark. Typically a third get built, a third are no longer wanted, and a third turn out to have been solved differently by the system as it shipped.

Cutting without losing trust

The way to propose a cut is with the reason and the trade, not as a refusal. “We can build this, and it is about two weeks. Based on the volume you described it would be used roughly twice a month. Would you rather have the supplier portal in that fortnight?”

Framed as a choice between two things the client wants, the decision is easy and it belongs to them. Framed as a refusal, it is an argument.

Frequently asked questions