How We Decide What Not to Build

The request arrives in your inbox, entirely sensible on its face. A client wants a comparison tool. Another needs a custom filter. A stakeholder suggests animated transitions. Each one sounds modest. Each one has merit. And therein lies the problem: when everything seems reasonable, how do you choose what not to build without simply guessing or defaulting to whoever asked loudest?

This is the question that defines our work more than any other. Not what we create, but what we deliberately leave out. Because every addition carries cost beyond the hours required to ship it. It demands ongoing maintenance, introduces new failure points, complicates the interface, and most critically, it trains users to expect complexity where simplicity might have served them better.

Why Saying No Matters More Than Saying Yes

The reason we obsess over what not to build is rooted in basic mathematics. A product with ten features can interact in forty-five different ways. Add one more feature and that number jumps to sixty-six. By the time you reach twenty features, you're managing 190 potential interactions, many of which you'll never test and some of which will conflict in ways you won't discover until a user does.

This exponential complexity explains why feature bloat kills products slowly. According to research from the Nielsen Norman Group, most users engage with fewer than 20% of available features in any given application, yet the presence of unused features increases cognitive load for everyone. The paradox: adding capabilities often reduces usability.

We learned this the difficult way. Three years ago, we built a dashboard for a client that included every metric they mentioned wanting. The interface became so dense that users ignored it entirely, reverting to spreadsheets. The failure wasn't in execution but in our failure to decide what not to build. We had prioritised comprehensiveness over utility.

The Three-Question Filter We Apply

Before any feature enters our roadmap, it must survive three questions, asked in sequence. The order matters because each question builds on the last, and a failure at any stage ends the conversation.

Does This Solve a Problem That Actually Exists?

Not a theoretical problem. Not a problem someone might have someday. A problem that exists right now, experienced by real users, evidenced by support requests, analytics, or direct observation. We demand specifics: who encounters this, how often, what workaround are they currently using?

Speculative features, the ones that begin with 'users might want', almost always fail here. If the problem doesn't exist yet, building the solution is premature optimisation. We'd rather wait until the need materialises and then respond quickly than build insurance against hypothetical futures.

Is This the Simplest Viable Solution?

Assuming a genuine problem exists, we ask whether the proposed feature represents the most direct path to solving it. Often, what looks like a feature request is actually a symptom of poor information architecture or unclear messaging, both of which live in our website design and build process.

For example, when users repeatedly ask for a search function, that might indicate your navigation is unclear or your content writing lacks proper hierarchy. Adding search treats the symptom. Restructuring the information solves the underlying cause. The latter is harder and usually what not to build turns out to be the quick fix, not the comprehensive feature.

Can We Maintain This Indefinitely?

Every feature becomes a permanent resident. It needs updates when browsers change, testing when adjacent code shifts, documentation when new team members arrive, and explanation when users encounter it. The ongoing cost often exceeds the initial build cost by a factor of five or more across a product's lifetime.

This question eliminates more features than the first two combined. A feature might solve a real problem in the simplest way, but if maintaining it requires specialist knowledge, fragile dependencies, or assumptions about user behaviour that could shift, it probably stays out. Our app development work particularly demands this discipline because technical debt in applications compounds faster than in static sites.

How We Communicate the Decision

Deciding what not to build achieves nothing if stakeholders feel dismissed. The process of explaining a no matters as much as reaching the conclusion. We've found that transparency about our reasoning builds trust, even when the answer disappoints.

We document every feature request in a shared space, visible to the entire team and the client. Each entry includes who requested it, the problem it aims to solve, and our assessment against the three questions. When we decide against building something, the reasoning lives alongside the request. This creates a record that prevents the same feature returning months later, and it shows we took the suggestion seriously.

Importantly, we separate 'not now' from 'not ever'. Some features fail our filter today but might pass it later, when circumstances change or when the problem they address becomes more widespread. According to government digital service standards, iterative development based on user need always outperforms comprehensive launches, and that principle extends to feature decisions.

When the Filter Might Be Wrong

No system handles every case perfectly. Occasionally, a feature that fails our filter turns out to be essential, and we adjust. The key is recognising when our process blind-spots us to legitimate needs.

This typically happens in three scenarios: when we underestimate how widespread a problem is, when we misjudge the complexity of maintaining a solution, or when market expectations shift faster than our assumptions. In those cases, we revisit the decision, explain why our initial assessment missed something, and update our thinking. Admitting error strengthens the process rather than undermining it.

For our SEO work, this happened with schema markup. We initially resisted implementing extensive structured data, viewing it as maintenance-heavy for uncertain benefit. As search engines increasingly rewarded rich results, we recognised the misjudgement and shifted our approach. The filter doesn't make us infallible, it makes our decisions auditable and correctable.

The Compounding Value of Restraint

Products built with disciplined feature restraint age differently. They remain comprehensible to new users, adaptable to changing requirements, and maintainable by small teams. The value isn't immediate because what you didn't build generates no launch announcement and no visible milestone, but it accumulates.

We see this most clearly when returning to projects after months or years. Systems where we carefully chose what not to build welcome changes easily. Systems where we said yes by default resist modification, every adjustment rippling unpredictably through accumulated features. The difference compounds: a product built with restraint becomes easier to work on over time, whilst one built without it becomes progressively more fragile.

This is why our services emphasise ongoing relationships rather than one-off builds. Deciding what not to build requires understanding the long-term context, the strategic direction, the user base evolution. Those insights develop through sustained collaboration, not single projects. When we understand where a product needs to go, we're better positioned to see which features would help and which would simply add weight.

Making Peace with Incompleteness

The hardest part of deciding what not to build isn't the analysis, it's accepting that your product will always feel incomplete to someone. There will always be a feature you didn't include that a competitor offers. There will always be a user whose specific need you chose not to address. The question isn't whether to disappoint anyone, because that's inevitable, but whether the disappointments you create are the right ones.

We've learned to view this incompleteness not as failure but as intentionality. When someone asks why we don't offer a particular feature and we can articulate exactly why, that's a product with clear purpose. When we respond with 'we just haven't got round to it yet', that's a product accumulating drift.

The features you don't build define your product as surely as the ones you do. They establish boundaries, clarify purpose, and signal what you value. Every time we filter out a reasonable-sounding request, we're making a statement about what this product is for and, equally importantly, what it isn't. That clarity is worth preserving, even when saying no feels uncomfortable.

If you're wrestling with similar decisions about scope, structure or what to prioritise in your digital project, we'd value the conversation. Drop us a note through our contact page. These choices matter, and talking through them usually clarifies more than any amount of internal debate.