You came to build something. A serious partner responds by proposing a paid discovery phase first — a few weeks of work before a single feature is built — and it lands like a stall, or an upsell, or a way to bill you for thinking. It is none of those. It is the step that decides whether the expensive part goes well, and skipping it is the most reliable way to turn a fixed budget into an open-ended one.
Jumping straight to build is how projects fail
The projects that go badly rarely fail because someone wrote bad code. They fail because everyone agreed to build the wrong thing, or the right thing on a wrong assumption, and nobody noticed until months of work sat on top of it. The client pictured one product, the partner heard another, and the gap only became visible when there was something to look at — by which point changing course means throwing away real work.
Building is the most expensive way to discover you misunderstood the problem. Every assumption you carry unexamined into a build gets encoded into architecture, into a data model, into decisions that are cheap to change on paper and painful to change in code. Discovery is where those assumptions get tested while they are still just words, when being wrong costs a conversation instead of a quarter.
There is also a version of this that looks like success right up until it is not. The team is busy, features are shipping, everyone can point to progress — and then the thing meets its first real users and it turns out the fundamental shape was wrong. Motion is not the same as direction. A discovery is how you check the direction before you spend a year moving quickly along it.
What discovery produces
Discovery is not a meeting or a vague sense of alignment — it produces artifacts you can hold and act on. First, a scoped plan: a clear statement of what is being built, for whom, and in what order, with the boundaries drawn so everyone knows what is in and what is deliberately out. Second, a direction for the architecture — the major technical choices and why, enough to build confidently without pretending every detail is settled.
Third, a register of risks: the things that could go wrong, ranked, each with a stance on how to handle it, so nobody is surprised by a problem that was visible from the start. And fourth, a costed first phase — a real number for a real, bounded slice of work, not a range with a shrug attached. Together these turn we think we want an app into a plan someone can approve, budget, and hold a team to.
What all four have in common is that they are decisions made cheaply, on paper, before they harden into code. That is the whole trade a discovery offers: it moves the moments of highest uncertainty to the point where changing your mind costs almost nothing, instead of leaving them to surface later when changing your mind means unwinding work you have already paid for.
What actually happens inside it
The work starts with interviews. Discovery talks to the people who will use the thing and the people who are paying for it, and those are rarely the same people with the same picture. It is common for a discovery to surface that two stakeholders wanted quietly different products — and finding that in week two is a good outcome, not a bad one.
Then comes current-state work: what systems exist today, what data lives where, what constraints are real, what the phrase it just needs to integrate with our existing system actually entails once someone looks. From there, prioritisation — turning a wish list into a sequence, deciding what the first version must do and what can wait, because a first version that tries to do everything ships nothing. And through it, prototyping the risky bits: the one integration nobody is sure is possible, the workflow that might not fit how people actually work. You build the smallest thing that answers the scariest question, so the answer arrives before the budget is committed, not after.
None of this is theatre, and a good discovery is visibly not padding hours. Each activity exists to remove a specific unknown, and when the unknowns worth removing are gone, the discovery ends. The point is not to produce a thick document; it is to reach the moment where the team can estimate the build against understood work rather than hope, and to get there as directly as the questions allow.
Why a fixed-fee discovery de-risks everything after it
A fixed-fee discovery is a small, bounded bet that makes the large bet safe. For a known price and a known timeframe, you convert the most dangerous phase of a project — the one where unexamined assumptions are quietly compounding — into a controlled, deliberate one. You are paying a small, certain amount to remove a large, uncertain risk, which is the definition of good insurance.
It reframes the whole engagement. Instead of committing a full build budget to a plan built on hope, you commit a fraction of it to producing a plan built on evidence, and only then decide whether and how to proceed. The build that follows a real discovery is estimated against understood work rather than guessed work, which is why the projects that start this way are the ones that tend to land on time and on budget. The discovery does not add cost to the project; it is what stops the project from adding cost to itself.
The fixed fee matters as much as the discovery. A time-and-materials investigation with no ceiling recreates in miniature the exact open-ended risk you are trying to escape. A fixed fee puts the risk of the investigation running long on the partner, where it belongs, and it signals that they are confident they can reach a useful answer inside a known effort. If a partner will not put a fixed price on understanding your problem, ask why they expect you to trust them with an unbounded one on solving it.
You should be able to walk away with the plan
Here is the test of an honest discovery, and it is the one that separates a genuine partner from a vendor protecting a pipeline: at the end, you should own the output and be free to walk away. The scoped plan, the architecture direction, the risk register, the costed phase — these are yours. If they are good, you will almost certainly want the same team to build what they just scoped, because no one understands the plan better than the people who wrote it. But you should not be trapped into it.
A partner who will only hand over the plan if you also sign the build is telling you the discovery was a sales device, not an honest assessment. A partner confident in their work is happy to be judged on it — and to let a strong plan earn the next phase on its merits. If you can leave with something valuable even if you never work with them again, the incentives were pointed the right way the whole time.
A small, fixed-fee start
None of this requires a large or open-ended commitment to begin. The right shape is a short, fixed-fee assessment: a defined price, a defined timeframe, and a defined set of outputs you get to keep. It is deliberately small — enough to interview the people who matter, understand the current state, prioritise honestly, and prototype the one or two things that genuinely worry us, and no more.
From it you get a plan you can act on and a costed first phase you can decide on with your eyes open. If the plan is right, building is the easy part. Discovery is how you make sure it is the right one before it becomes the expensive one — and a partner who is willing to be measured on the plan alone, before you have committed to anything else, is usually the one worth building with next.