- pricing
- discovery
- project scoping
- engagement model
Why fixed-price software needs paid discovery
Every founder wants a fixed price for their software project. Every honest studio knows they can't give one without a paid discovery phase first. Here's what that phase actually contains, and why it's the shortest path to a real number.

The most common question in a first email from a founder is: "how much would this cost?
The most honest answer is: "I don't know yet — and if someone tells you they do, be suspicious."
That sounds evasive. It isn't. It's the setup for how every serious software engagement actually works.
Why cold estimates are always wrong
A cold estimate is a number handed over before anyone has looked closely at what you're building. It comes from pattern-matching against previous work — "that's a marketplace, we've built three of those, about six months."
The problem isn't that the estimate is high or low. The problem is that it's meaningless until someone has spent real time understanding:
- What the users need to do (not just what the buttons should say)
- Which external systems it has to talk to, and what those systems are actually willing to do
- What "done" means for the first release
- Which decisions will need to be revisited in three months, and which are one-way doors
Every one of those has a factor-of-three range. Multiply them and a cold estimate has a factor-of-eighty range. Any number inside is technically defensible and practically useless.
What we do instead: paid discovery
Paid discovery is a short, fixed-price engagement whose only deliverable is a scope and a number for the build.
For a typical mid-sized project it runs one to three weeks. During it we:
- Interview the people who'll actually use the software. Not the person paying, unless they're the same person. What founders think users need and what users actually need diverges more often than not.
- Sketch the flows end to end. Low-fidelity, on paper or in Figma. Real enough to show a real user and get honest feedback.
- Investigate the integrations. APIs are famously optimistic about what they support. We call the endpoints ourselves.
- Identify the load-bearing decisions. What's the data model? Where are the auth boundaries? Which choices lock you into a stack and which are easily reversed?
- Write the scope. Every screen, every state, every failure mode we can foresee.
- Quote the build. A single fixed price with a fixed timeline, based on the scope.
At the end you have a document you can show to any other studio for a competitive quote — the artefact is yours, not ours. If you decide the build isn't worth it, you've paid for a scope that will pay for itself in
avoided mistakes wherever you hire next.
Why we won't skip it
We used to. Early in the studio's life we quoted cold. The projects that went well were the ones where the founder already had a written scope. The projects that went badly were the ones where we filled in the gaps
ourselves, quietly, based on assumptions the client would have corrected in ten minutes if we'd asked.
Fixed-price only works when the scope is real. If the scope is guesswork, "fixed-price" becomes a game of who absorbs the surprises — us if we're honourable, you if we're not. Neither is a good deal.
What discovery costs
Typically 5–10% of the build cost. If you don't proceed to the build, that's the total. If you do, discovery is folded into the invoice — you're not paying twice.
The bit founders miss
Discovery isn't just insurance. It's the fastest route to a real number. A cold quote takes weeks of email back-and-forth to refine into something we'd bet on. Paid discovery gets you there in the same time, with a
written document at the end and a much smaller confidence interval on the price.
If you'd rather have a wrong number in an hour than a right number in a fortnight, we're the wrong studio. If you'd rather know exactly what you're buying before you spend six figures on it, we can start Monday.



