A software discovery phase should end with six things you can use: interviews with the people who will use the software, a requirements document, a clickable prototype your team has tried, a technical plan, a ranked list of the work, and a build plan with a fixed price. If a discovery proposal does not promise all six, ask why before you sign.
Discovery is the paid planning work before a custom build. It decides whether the build is the right one. It should produce a plan another team could build from.
We are The Gnar Company, and we sell this work as Gnar Discovery and Design, so read our part knowing who wrote it. Our smallest tier, Foundation, comes down to this. Two weeks, $15,000, and you walk out with a build plan that has a fixed price on it.
This guide is for the COO with a discovery proposal on the desk. It gives a checklist to hold the proposal against, the red flags to ask about, and what you should own at the end.
What is a discovery phase for?#
A discovery phase is for deciding whether to build the software, what exactly to build, and what the build will cost, before anyone writes production code. Its main output is a decision, and the six deliverables in the checklist below are what that decision rests on. It also ends with a plan and a price, which you act on if the answer is yes.
The UK government's digital service manual puts it simply in its guide to the discovery phase (last updated June 2021): before you commit to building a service, you need to understand the problem that needs to be solved. That means learning about your users and what they are trying to achieve, and the constraints you would face, such as technology or legislation.
The same guide is firm on one point. You should not start building your service in discovery. What you learn should help you decide whether to move forward to the next phase.
For a mid-market company, that decision has a dollar figure attached. At Gnar, the build a discovery plans is typically $150K to $300K+. Spending a fraction of that first, to find out whether the build is the right one, is the point of the phase.
What should a discovery phase include?#
A discovery phase should include six things: interviews, a requirements document, a clickable prototype, a technical plan, a ranked list of the work, and a build plan with a fixed price. The proposal should name each one. Use this list against any firm's proposal. A missing item is a question to ask before you sign.
- Interviews with the people who will use the software. These include the people who do the work by hand today.
- A requirements document. The goals, what the software must do, who uses it, and what it will not do.
- A clickable prototype your team has tried. The main tasks end to end, tried by the people who will use it.
- A technical plan. The tools, how the software stores its information, and how it connects to the systems you already run.
- A ranked list of the work. What goes in the first version and what can wait.
- A build plan with a fixed price. Broken into stages, with the price for each.
Gnar's Discovery page and product discovery page together cover the six items: user research (stakeholder and user interviews), a product requirements document, interactive prototypes, a Technical Architecture Blueprint, the team ranking the work with you and a guaranteed-price build plan.
The sections below take the items one at a time.
Does the discovery define the problem or only the solution?#
A good discovery starts by turning the solution you asked for into the problem you need solved. Teams often arrive at discovery with an answer already chosen: "we need a customer portal" or "we need a new order screen". The first job is to ask what problem that answer is meant to fix.
The UK service manual calls this reframing. When you are handed a pre-defined solution, you interrogate it and reframe it as a problem to be solved. That includes agreeing what is not part of the problem. The guide also suggests working out how much the problem is costing today.
Here is an example. "We need a customer portal" becomes "our customer service team spends a large part of its day answering order status questions by phone." The second version can be measured. It also opens options the first one hides, such as an automatic email when an order ships.
Look for this in the proposal. If screens come before any interviews, the problem has been assumed.
Gnar's Discovery page opens with the reason this matters: "The most expensive mistake in software is building the wrong product."
Who should discovery talk to?#
Discovery should talk to the people who will use the software and the people who do the work by hand today. The people who do the work every day know the workarounds, and the workarounds are where many requirements hide.
The U.S. government's Digital Services Playbook opens with this. Its first checklist says to spend time with current and prospective users early in the project, test prototypes of solutions with real people, and document the findings about user goals, needs and behaviors. It also says to create a prioritized list of the tasks the user is trying to accomplish.
For a distributor, that means the person who keys in orders from email. For an insurer, it means the underwriter.
At Gnar, the interviews come first. The written requirements come out of what those people say.
What should the requirements document say?#
The requirements document should say what the software must do, who will use it, and what it will not do. That last part matters as much as the first. A list of what is out of scope is what stops the build from growing after the price is set.
Gnar's product discovery page describes its requirements document in plain terms: your goals, what the software must do, who will use it and what it will not do. Any team can build from it.
Requirements writing has an international standard behind it, the 2018 edition of ISO/IEC/IEEE 29148. It sets out the processes that produce requirements for software and what the resulting documents must contain. You do not need a discovery firm to follow the standard line by line. You do need a document that is specific enough for a team that was not in the room to build from.
Test the document with one question. Could another firm price the build from it without calling the authors? If the answer is no, it is notes, and the build price will rest on guesses.
Why test a prototype before the build?#
A prototype lets your team try the main tasks before the software exists, so mistakes show up while the fix is a design change. After the build, the same fix means changing working code that is connected to your data.
Gnar's product discovery page puts it this way: you and your team try the main tasks in the prototype before the software is built. Mistakes show up while they are cheap to fix.
Two things make a prototype useful:
- It covers the main workflow end to end. Entering an order, approving it, and finding it again later. A set of pretty screens that do not connect does not test the work.
- Real users try it. The people who will use the software every day, with their own examples. Where they get stuck is what you record and fix.
Ask the firm who will try the prototype and how the results get written down. If nobody outside the firm's team tries it, it has not been tested.
What should the technical plan cover?#
The technical plan should cover the tools the software will be built with, how it will store its information, and how it will connect to the systems you already run. It should be written by engineers who build software of this kind, because they know what the build will take.
At Gnar, the engineers who would build it plan how. They pick the languages and tools, plan how the software stores its information and map how it connects to the systems you already use. Our discovery team includes both designers and engineers, so the prototype is designed with what can be built in mind.
For a mid-market company, the connections are usually the hard part. Ask the firm to name each system the software touches (the ERP, the CRM, the shipping carrier, the payment provider), what data moves each way, and who owns each connection. A technical plan that says "integrates with your ERP" in one line has not looked.
Should discovery end with a fixed price or an estimate?#
Discovery should end with a fixed price for the build. An estimate leaves the risk of being wrong with you. When the same firm does the build, a fixed price puts the risk of an overrun on the firm.
The difference shows up during the build. An estimate that grows is paid by you.
Our Discovery FAQ states it this way: every Discovery engagement ends with a Milestone Project Plan that breaks your build into clear phases, each with a fixed price. The price is guaranteed: if the build costs more than quoted, the overage is on us.
Two details make a fixed price real:
- What a small change costs. If you and Gnar agree a small change fits the plan, it is included. New work beyond the plan gets its own price.
- What happens when the price is over budget. We rank the work with you, so work that costs a lot and adds little can wait for a later version, and the first version gets closer to your budget. If it still does not fit, the requirements, prototype and plan are yours, and you have only paid the discovery's fixed price.
That price sits inside a larger set of commitments. Three commitments on every build engagement: a fixed milestone price with any overage on us, a guaranteed outcome meaning the software works as specified or we fix it, and a twelve-month bug-free warranty. It covers Discovery, Build, Forge and Maintain. It does not cover Embed. On Compass, Immerse and Integrate, ask us.
What does a discovery phase cost?#
Gnar Discovery and Design costs $15,000 for two weeks, $20,000 for four weeks and $30,000 for six weeks, and the prices are published. Other firms set their own prices, so ask any firm for its discovery price in writing before you compare. Compare on what each price includes: how many interviews, how many prototypes, and whether it ends in a fixed build price.
| Gnar Discovery and Design tier | Price | Length | User interviews | Prototypes |
|---|---|---|---|---|
| Foundation | $15,000 | 2 weeks | Up to 2 | 1 |
| Core (recommended) | $20,000 | 4 weeks | Up to 4 | Up to 2 |
| Accelerator | $30,000 | 6 weeks | Up to 6 | Up to 4 |
Each prototype has up to 4 screens.
Most clients choose Core. Each tier ends with the same thing: a build plan with a fixed price. The build it plans is typically $150K to $300K+.
If you already wrote down what you need, discovery may be smaller. When Gnar's engineers find an existing plan complete, Gnar can price the build from it directly. If it needs work, the team checks it, fixes what is unclear and fills the gaps, then prices it.
What are the red flags in a discovery proposal?#
The red flags in a discovery proposal are no user interviews, no prototype or one nobody tries, an estimate instead of a fixed price, no list of what is out of scope, a one-paragraph technical plan, outputs you do not own, and junior people running it. Each one below is a question to ask the firm before you sign. A good firm answers each in a sentence.
| Red flag | Why it matters | What to ask |
|---|---|---|
| No user interviews | The plan rests on what managers think happens | Who will you talk to, and how many people? |
| No prototype, or one nobody tries | Mistakes surface during the build, when they cost more | Who on our team tries it, and how are results recorded? |
| Ends with an estimate or a range | The build price can still move | Does discovery end with a fixed price for the build? |
| No list of what is out of scope | The build grows after the price is set | Where does the plan say what the software will not do? |
| The technical plan is one paragraph | Connections to your systems are unplanned | Which systems does it touch, and what data moves each way? |
| You do not own the outputs | You are tied to the firm for the build | Can we take the plan to another firm? |
| Junior people run it | The plan and the price depend on the experience of whoever writes them | Who runs discovery, and how senior are they? |
At Gnar, the same senior team that runs your discovery builds your product in our Build phase, with 100% US-based senior engineers and designers.
Do you own what discovery produces?#
You should own everything a discovery produces, and the contract should say so. The requirements, the prototype and the build plan are what you paid for. At Gnar, everything product discovery makes is yours: the requirements, the prototype and the build plan. You can take them to your own engineers or to another firm. Our short answer to "do I have to do the build with you" is: No. Start with a discovery sprint that ends in a guaranteed price, whether or not you build with us.
There is one more outcome to plan for. Sometimes discovery shows the software should not be built. A good firm tells you. At Gnar, discovery has its own fixed price, so that answer costs no more than the discovery itself, and you have not paid for a build you do not need.
Hold every discovery proposal to the six items above. Ask the seven red-flag questions. Then compare the answers side by side, and keep them with the contract.
