"Should we pay for a discovery phase, or is that just a way for the vendor to bill us before doing any real work?" is a fair question, and the honest answer is: it depends entirely on what you get back for the money, not on whether "discovery" appears as a line item.
Some discovery engagements save a company from an expensive wrong build. Others produce a beautifully designed deck, a round of applause in a workshop, and nothing anyone can actually act on. The word "discovery" covers both, which is exactly why buyers are right to be skeptical by default.
Discovery is worth it when it produces
- A prioritized MVP slice — a specific, buildable first version, not a wish list reorganized into three columns.
- A technical risk list. Which integrations are uncertain? Which data sources are messy? Where might AI or compliance requirements complicate things? Naming these early is the entire point of paying for discovery instead of finding out mid-build.
- Architecture options with real trade-offs, not a single unquestioned choice presented as the only path. "We could build this as a monolith for speed now, or split it early if you expect rapid team growth — here is what each costs you" is useful. A single technology recommendation with no reasoning is not.
- A sprint plan and a budget band you can actually fund, tied to the risk list above — not a number that appeared out of nowhere at the end of a slide deck.
If a discovery phase produces all four of these, it earned its fee even if nothing was coded yet. You bought clarity, and clarity is what prevents the expensive mistake of building the wrong thing carefully.
Discovery is not worth it when it only produces
- Generic personas and sticky-note workshops that could describe almost any business, with no connection back to your actual product decisions.
- Beautiful decks with no path to a repository or a working prototype. If discovery ends and nobody can show you anything that runs, ask what, specifically, you paid for.
- A sales exercise dressed up as analysis, used mainly to justify a large fixed quote that was probably decided on before discovery even started.
A useful gut check: if you removed the word "discovery" from the invoice, would this output still feel worth the price on its own merits? If the honest answer is no, the label was doing the selling, not the work.
Timeboxes that stay honest
Discovery does not need to be long to be good, and long discovery is not automatically more thorough — sometimes it is just less decisive. Many focused discoveries fit into a matter of days to a couple of weeks, not months, when the stakeholders involved are willing to make real decisions instead of scheduling another round of review.
Pay for decisions and risk reduction — not for theater.
Contrast two versions of the same exercise: a two-week discovery for an internal operations tool, where three stakeholders commit to daily half-hour check-ins and leave with a clear first slice and risk list — versus a three-month "discovery" for a similar-sized problem, stretched out by monthly steering committee meetings, indecisive stakeholders, and a vendor happy to bill by the week regardless of how little converges. The calendar time difference is not about the complexity of the problem. It is about how decisively people showed up.
When to skip discovery entirely
If your scope is already genuinely narrow and the technical risk is low — a well-understood internal tool with no unusual integrations, for instance — a separate discovery phase can be more process than you need. In that case, skip the standalone phase and start with a short paid sprint that delivers working software directly. You learn just as much from a real first slice as from a discovery document, and you get software out of it instead of a report.
The signal to watch for is complexity, not company size. A five-person company building something with three complicated integrations and a compliance requirement probably benefits from real discovery. A hundred-person company automating something simple and well-understood internally probably does not need much of one.
Who should actually be in the room
Discovery quality tracks the seniority of the people running it more than almost any other factor. A junior analyst running a discovery workshop will produce a well-organized document. A senior engineer or architect running the same workshop will produce a document that also flags the integration nobody thought to mention, because they have seen that specific failure mode before on other projects.
This is worth asking about directly: who, specifically, will run our discovery, and have they personally built something like what we are describing? "Our team has experience in this space" is a company-level claim. "I built something similar for a client with the same billing integration you're describing" is a personal one, and it is the one that predicts whether discovery will actually surface your real risks instead of generic ones.
Questions to ask before agreeing to pay for discovery
- What are the four concrete outputs we will have at the end — in writing, before we start?
- Who from your side needs to be in the room, and how often?
- What happens if discovery reveals the project is smaller (or larger) than we assumed?
- Does the discovery fee apply as credit toward the build, or is it fully separate?
ConaiSoft keeps discovery tied to a buildable first slice, not a standalone deliverable disconnected from actual building. If you only need a rough ballpark, start with a free exploratory call. If real technical risk is involved, we will scope a short, paid discovery with clear, named outputs before anyone writes a line of production code.