Decide what to build before you build it

Most failed software projects were not built badly. They were built well, on time and to specification. They just built the wrong thing.

The specification described a solution somebody had already chosen, rather than the problem the organisation actually had. By the time real users arrived, it was expensive to change course.

The difference between a brief and a problem

“We need a mobile app” is a brief. “Our field staff can’t record visits until they are back at the office, so our data is always a day late” is a problem. The first tells you what to build. The second tells you what needs to change, and leaves room to find the best way to change it. That might be an app, a simpler form, or a change to an existing system.

Four questions to answer first

1. Who is this for, and what are they trying to do? Name the people and the moment they will use it.
2. What happens today? Map the current way it gets done, including the workarounds.
3. What should be different, and how will we know? Agree what success looks like before building.
4. What is the smallest version worth launching? The version that solves the core problem for real users, not the version with every feature someone has asked for.

Why the smallest version matters

A focused first version reaches real users sooner, and real users are the only reliable source of truth about what a product needs. Every feature added before launch is a guess. Every feature added after launch can be based on evidence.

Starting small is not the same as thinking small. A well-defined first version is built on foundations that can grow, so nothing you learn later requires starting again.

What this saves

A definition phase feels like a delay. In practice it is the cheapest insurance a project can buy: it replaces expensive changes during the build with inexpensive decisions before it. It also produces something valuable on its own, a written scope that everyone understands and a fixed price that reflects it.

That is why every engagement we take on starts with a scoping conversation, and why the Build path begins with pressure-testing the idea before any code is written.

What a good scope document contains

The output of a definition phase is not a slide deck. It is a short, plain document that both sides can hold each other to. A good one includes:

• The problem, in the words of the people who have it.
• Who it is for and the main things they need to do.
• What is in the first version, and, just as important, what is explicitly not.
• How it connects to the systems and data already in place.
• What success looks like, in terms someone can observe.
• A fixed price and milestones, agreed before any work begins.

When scope changes later, and it sometimes should, this document makes the change visible. The difference can be priced and agreed in writing, instead of quietly absorbed or quietly inflated.

Signs you are about to build the wrong thing

• The brief describes screens and features, but nobody can say what will be different for the business.
• The people who will use it have not been asked how they work today.
• Every stakeholder’s wish list has been merged into version one.
• There is no agreement on how anyone will know it worked.
• The deadline was set before the scope was understood.

Any one of these is a reason to pause for a few days of definition. It is almost always cheaper than discovering the same thing halfway through the build.

How long should definition take?

Long enough to answer the four questions with confidence, and no longer. For a focused product or internal tool, that is usually a handful of conversations and working sessions, not months of documentation. The aim is shared understanding, not paperwork. If the definition phase starts producing documents nobody reads, it has gone on too long.

Who should be in the room

• The person who owns the outcome, and can make decisions about scope.
• People who will use the product, or who represent those who will.
• Someone who understands the existing systems the product must connect to.
• The team who will design and build it, so constraints and ideas surface early.

Leaving any of these out tends to produce a scope that is either technically unrealistic or disconnected from how people actually work.

Prioritising features without arguments

Every stakeholder has a list. A simple way to decide what goes into the first version is to ask, for each feature: if this were missing at launch, could people still get the core job done?

• If no, it belongs in version one.
• If yes, but with real pain, it goes in the first improvement after launch.
• If yes, with minor inconvenience, it waits until real users ask for it.

This keeps the first version focused, and it gives everyone a clear, fair answer about when their feature will arrive.

After launch

A good definition phase includes a plan for what happens next: how feedback will be collected, how often improvements will be released and how success will be reviewed. Launch is the start of learning, and the product should be built to change.

Pricing follows definition

A clear definition does something else that matters to every buyer: it makes a fixed price possible. When the scope is written down, with what is included and what is not, the team building it can estimate honestly and commit to a figure. Without it, prices are either padded to cover unknowns or open-ended, and both leave the buyer carrying the risk.

This is why we price after scoping, not before. The conversation costs little, and it replaces a guess with a commitment. If the scope changes later, the difference is visible and can be agreed in writing, rather than appearing as a surprise on an invoice.

A short checklist before you commission any build

1. Can you describe the problem in one sentence, without naming a technology?
2. Do you know who will use it, and have you asked them how they work today?
3. Have you agreed what “working” means, in terms you can observe?
4. Is the first version small enough to launch and learn from?
5. Do you have a written scope, a fixed price and clear milestones?

If you can tick all five, you are ready to build. If not, a few days of definition will almost certainly save you more than they cost.

Quick answers

Is a definition phase just a paid sales process? It should not be. A good one produces something you own and can use with any team: a clear problem statement, a scope and success measures.

What if we already have a detailed specification? Great. Definition then becomes a short check that the specification still matches the problem and the people who will use it.

What if requirements change during the build? Some change is healthy; it means you are learning. The written scope makes each change visible, so it can be priced and agreed in writing before the work happens, instead of quietly stretching the timeline and budget.