Before we wrote any code for EverybodysPet, our own animal-welfare platform, we wrote 44 planning documents. They covered every role, how the roles connect, the case engine, money and countries. Then came a design package of 196 screens across 26 boards. That was a big product and a long plan, and it's more than most first releases need. But it taught us what a discovery phase is for: when the building starts, nobody should be guessing what the product is.
You won't get 44 documents from a two-week sprint, and you shouldn't want them. You should get a pack you could hand to any competent team, and they could price the build from it without phoning you. Below is the contents page of that pack as we'd write it, with a note on what each section must contain and what a weak one looks like. If a discovery you're paying for is missing a section, ask why. Sometimes there's a good reason. More often it was skipped.
Goals and constraints, on one page
Who the product is for, the one journey that must work on launch day, the date you're aiming for and the hard limits: a regulator, a payment provider you're already committed to, a budget ceiling.
The test is the journey sentence. "A customer can book a slot and pay for it." "A site engineer can log today's progress from a phone." If nobody can write that sentence yet, the first job of discovery is to get it written. Everything after this page is shaped by it.
The scope, in releases
Not a feature list. A list where every item says whether it ships first or waits, and why. You should be able to read release one and picture a working product that does one important job end to end, rather than a pile of half-features.
Assumptions belong here too, in plain words: "one payment gateway", "English only at launch". And the integrations should be named, because each one is a risk.
A weak scope has nothing deferred. If every feature is in release one, nobody prioritised anything. They just typed out the wish list.
The roles
Each kind of person who uses the system, with what they can see and what they can do. This section looks dull and is often where the expensive surprises live.
On Firetrix, a fire-protection contractor's system, the plan has ten roles. Procurement, finance and stores must never see margins or offer rates. That rule only became obvious once each role was drawn separately. Missed in discovery, a rule like that turns up after launch, in a conversation nobody enjoys.
The flows, including the unhappy ones
A user flow is the path one person takes to get something done, step by step. "Customer books a slot" is a flow. "Customer's card is declined halfway through" is part of the same flow, and a weak discovery leaves it out.
Real products spend a surprising share of their screens on errors, empty states and permission walls. If every flow in the pack ends in success, the pack is showing you the demo, not the product.
For marketplaces and delivery apps, this section has to settle the rules nobody draws on a screen: what commission is taken and when, when providers get their payout, what happens to money on a cancellation or a no-show, who decides a dispute and on what evidence, and which side you recruit first when the other is empty. A smooth booking prototype without those answers is a nice video.
The prototype
Clickable screens behind release one's main flows, linked together, with realistic content. Enough to walk through, not enough to ship. Founders and early users react to a clickable prototype far better than to any document, which is why this is usually the section that changes the scope most.
Longer discovery can go much further. For Firetrix we produced 12 design boards and nine clickable prototypes, one per internal role and one with every role together, so the client could walk the whole loop from enquiry to final bill before any application code existed.
A prototype also becomes the reference the build is checked against. QKE's full quotation-to-stores workflow ran first as a prototype, and the real application is built slice by slice against it. When QKE walked through it, they asked for four additions. Adding them to a prototype took hours. The same four after go-live would have been a project.
One habit we picked up on EverybodysPet: where a screen exists only as a design, the product says so ("Designed on 7 October · not built yet") instead of showing a fake. Do the same in your pack. Label what's in release one and what's a picture of later, so nobody mistakes one for the other in a demo.
The rules
Money, permissions, notifications, timeouts and edge cases, written as plain sentences. "A booking not accepted within 20 minutes is cancelled." "Stores can see quantities but not rates."
This is the section we'd fight hardest to keep, because every sentence here becomes a test case later. A prototype with no written rules behind it is decoration.
The architecture, and what we won't build
For you as the buyer, this should answer plain questions. What are the main parts of the system? Where does the data live? Which outside services does it depend on? Which stack, and why?
Just as useful is the list of things deliberately not being built. For a customs broker replacing a legacy ERP of more than 400 screens, the proposed phase one exports vouchers to Tally instead of rebuilding a ledger, and sends GST e-invoices through a provider adapter instead of custom tax code. Those two "don't build" lines save more than any clever design in the document.
Risks and open questions, each with an owner
Integrations nobody has tried yet. Data that has to move out of an old system. Privacy and compliance obligations. And decisions only you can make.
That last group is often the most valuable page in the pack. The customs broker discovery ended with ten questions the client had to answer before anyone could give a firm price, starting with which legal entity and branches do the real work today. Writing those down is honest. Quoting around them would have been a guess with a number on it.
The quote, in milestones
A fixed price for the build, split into milestones that each end in something you can install or use. Four things to check:
- You can point at any line in the scope and see which milestone pays for it.
- Each milestone has written acceptance criteria, so "done" isn't an argument.
- There's a rule for changes: a change after sign-off is priced before work starts, which keeps scope creep visible.
- Exclusions are written down. Third-party fees, store accounts, content writing and data entry are the usual gaps.
If three agencies have quoted you for "the same app" and the numbers differ several times over, they aren't disagreeing about price. They're imagining three different products. This page is what stops that.
How long it takes, and what it costs
For most new apps and SaaS products, two weeks of senior work is enough to produce all nine sections. Ours runs like this:
| When | What happens |
|---|---|
| Days 1 to 2 | Kick-off call: your goals and users, the competitors you watch, the hard constraints |
| Days 3 to 6 | Scope and user flows, reviewed with you mid-week |
| Days 7 to 10 | Clickable prototype of the core screens; architecture and risk list |
| Days 11 to 14 | Walkthrough, changes, and the fixed-price quote with milestones |
From your side that's about three short calls: the kick-off, the mid-sprint review and the walkthrough. The sprint is run by the core team of 2 to 5 who would lead the build, because the person who writes the architecture ought to be the person who lives with it.
Our Discovery Sprint is a fixed ₹1,50,000, or $1,600, the same price wherever you are. If the build starts within 60 days of the walkthrough, the full fee is credited to it. The pricing page shows how it sits next to the build ranges we quote.
Business software that replaces spreadsheets or an old system takes longer. You can't scope work you haven't walked through, and the truth is usually spread across people and files. That's why the customs broker mapping went menu by menu through the old system, and why Firetrix's plan ran to 32 documents. Our custom business software page describes that longer mapping.
The test at the end
When the pack is done, imagine posting it to a team you've never met. Could they price the build from it? Could they start without a single call to you?
If yes, the discovery is finished, and the pack is yours whether or not we build. If the documents only make sense to the people who wrote them, you've paid to be locked in, and that's worth saying out loud before you pay for anything else. The process page shows what happens after the walkthrough if you do go ahead with us, and the UI/UX design page covers the flow and prototype work in more depth.