Most software that fails does not fail during construction. It fails earlier and more quietly, at the point where nobody stated the problem precisely enough to notice that two people in the room were solving different ones.
By the time that surfaces — usually somewhere around the first demo nobody is excited by — the budget is committed and the project has too much momentum for anyone to say so comfortably.
Here is the sequence that avoids it.
Start with the cost of the current process, not the solution
The first artefact is not a feature list. It is a sentence of this shape:
Today, [these people] do [this thing] [this often], and it costs us [this much] in time, errors or lost revenue.
If you cannot complete that sentence, you are not ready to build software. That is not a criticism — it is the single most useful thing discovery produces, and it takes days rather than months.
The number matters more than its precision. “Four people spend roughly a day a week rekeying job sheets, and we invoice late about a fifth of the time” is enough. It tells you what the solution is worth, which tells you what it is sensible to spend, which is the conversation everyone skips.
Map what actually happens, not what is supposed to happen
Ask three people who do the work to describe the process. You will get three different answers. The differences are the most valuable output of the entire exercise.
The official process lives in a document. The real one lives in a spreadsheet someone maintains privately, a WhatsApp group, and a person who “just knows” which orders need checking. Software built against the official process gets rejected by the people who have to use it, and everyone concludes the users are resistant to change. They are not. They are working around a system that does not know what their job is.
Name the users, and be specific about which one matters most
“Users” is not a group. A field engineer submitting a job sheet on a phone in poor signal, an office administrator reconciling forty of them, and a director who wants one number on a Monday are three different products wearing a trenchcoat.
Pick the one whose problem justifies the investment. Serve them properly. The others get a lesser version in release one, and that is a decision rather than an oversight.
The instinct to serve everyone equally in version one is the most reliable way to serve nobody adequately.
Define the MVP by what it excludes
An MVP is not a small version of the whole thing. It is the smallest system that lets a real person do real work end to end, so that you learn something true.
The practical test: could one person, on one day, complete one full cycle of the job using only this? If yes, it is an MVP. If they would still need the spreadsheet halfway through, it is a demo — and demos teach you nothing, because nobody depends on them.
Write the exclusion list explicitly and get it agreed. Not “phase two”, which everyone reads as “soon”, but a written list of what release one deliberately does not do. This document prevents more budget overruns than any estimation technique.
Decide what would make this a failure
Before building, agree the measures:
- The number that should move, and by how much
- When you will check
- What result would mean you should stop
Teams find the last one uncomfortable and skip it. Skipping it is how organisations end up maintaining software for six years that nobody ever demonstrated was working. Deciding the failure condition while everyone is still optimistic is far easier than deciding it later, when saying so costs someone their credibility.
Only now, talk about technology
By this point the technical questions mostly answer themselves. You know the users, the devices, the data, the integrations and the volume. Architecture becomes a consequence rather than a preference.
Two things are worth deciding deliberately, because they are expensive to reverse:
Where the data lives and who owns it. Integration is where estimates go to die. The system you described as “we just pull the customer list from the ERP” is often the largest single risk in the project.
How simple you can afford to be. Start with the simplest architecture that safely supports the business you expect to have — not the one you might have if everything goes extraordinarily well. You can add complexity when the evidence demands it. You can rarely remove it.
Three places this goes wrong
Discovery gets treated as free. A partner who does discovery unpaid is doing it quickly, because they are absorbing the cost while competing for the work. Paid discovery is short, fixed-fee, and produces something you own regardless of who builds it. It is the cheapest insurance in software.
The MVP grows during the process. Someone senior sees the scope and asks for one more thing, which is reasonable, and it happens eight times. Nothing prevents this except a written exclusion list and someone willing to point at it.
Nobody owns the decisions. A project needs a person who can say yes on Tuesday without convening a committee. Their absence does not stop a project; it just makes it cost forty per cent more, spread invisibly across every week.
What you should have at the end
- A problem statement with a number attached
- A map of how the work happens today
- A named primary user
- An MVP scope, and an explicit list of exclusions
- Success measures and a failure condition
- Architecture direction and the decisions behind it
- A release plan and an investment range with stated assumptions
That is two to three weeks of work. It costs a fraction of one per cent of a typical build, and it is the difference between a project that is defensible in a board meeting and one that is a matter of faith.
The point is not that this makes the project certain. It is that it makes the uncertainty legible while it is still cheap to act on.
Written by WeInDev. If this is a decision you are facing now, it is also a conversation we are happy to have — thirty minutes, no pitch deck.