Why we will not quote a fixed price before discovery
A fixed price quoted before anyone understands the problem is either padded to cover the worst case or about to be revised upwards. Both are worse for the client than two weeks of finding out.
The most common request we decline is a fixed price on a one-paragraph brief. Clients find that frustrating, reasonably, so it is worth explaining what is actually behind it.
The two ways an early fixed price goes wrong
An agency quoting a number before understanding the scope has two options, and both are bad for the buyer.
It can price the worst case. The number is large, covers everything that might be true, and the client pays for risk that mostly does not materialise. The agency is fine. The client overpaid and does not know by how much.
Or it can price the optimistic case to win the work, then recover the difference through change requests. Every ambiguity becomes a negotiation, the relationship becomes adversarial by month three, and the final figure is higher than the honest worst-case quote would have been.
Every fixed price quoted in ignorance is either padding or a plan to argue later.
The second option wins more work than the first, which is the uncomfortable part. A buyer comparing three quotes on price alone is selecting for whoever understood the problem least, and there is no way to tell from the outside.
What discovery actually buys
Two to three weeks of questions, constraints and technical assessment, producing a scope specific enough to hold someone to and a fixed price against that scope.
- Integrations named, with their documentation actually read - the difference between a modern API and a twenty-year-old SOAP endpoint is months.
- The data model sketched, because that is where unexpected complexity lives.
- Non-functional requirements stated: offline, accessibility, scale, regulatory.
- An explicit list of what is out of scope, which prevents more disputes than anything else in the document.
Reading the documentation is not a formality. An integration described in a brief as syncs with their existing system has, in our experience, ranged from an afternoon to four months, and nothing in the sentence distinguishes the two. The only way to know is to ask for credentials and make a request.
The questions that move the number most
A handful of questions account for most of the variance between a cheap project and an expensive one, and none of them are usually in the brief.
- Who is the system of record? If the app is the source of truth the work is contained. If it must stay consistent with something else, the cost is in the reconciliation rather than the feature.
- What happens offline? Answering nothing useful is a legitimate choice and a cheap one. Answering everything keeps working is a different product.
- Who are the users, and does that include anyone the organisation is obliged to accommodate? Accessibility designed in is ordinary work; retrofitted it is a project.
- Does anything here touch payments, health or identity? Each has a compliance surface that dwarfs the interface.
- What already exists, and is anybody still maintaining it? Inheriting a codebase with no author available is a different job from a new build and usually a slower one.
Every one of those can be answered in a conversation. None can be guessed, and each can move an estimate by a factor rather than a percentage.
The result nobody expects
Discovery regularly concludes that the client should build less than they planned. A smaller first version, shipped sooner, that answers the question the big version was guessing at.
That is a strange thing for an agency to recommend, since it reduces the immediate invoice. It is also the single most valuable output we produce, and it is why clients come back.
What the client owns at the end
Discovery is bought outright, and the output is theirs regardless of what happens next. Scope document, technical assessment, data model, estimate.
That matters for a reason we think is worth stating plainly: a client who takes that document to another agency gets a better price from them too, because the risk has been removed for whoever builds it. Discovery that only has value if you also win the build is not discovery. It is a sales process with a deliverable attached.
When we will quote without it
Small, well-defined work with an obvious shape - a design sprint, a defined integration, a performance audit. If we can describe the deliverable in a sentence and we have built the same thing before, a number is honest.
For anything larger, the two weeks cost a fraction of the project and remove most of the risk from both sides.
The comparison worth making is not discovery against no discovery. It is two weeks at the start against the month of rework that follows a specification nobody tested, which is the same money spent later and with less to show for it.
