A business that wants custom software usually starts with a sentence: "we need a system for orders" or "invoices take too long". A reliable development plan cannot be built from that sentence alone. Someone has to find out how the work runs today, what the software should change, and what it will cost. That step is the project discovery phase.
What the discovery phase is#
Discovery is the work done before development to turn an idea into a written plan. It ends with a specification: what to build, what it will cost and in what order. The goal is a document detailed enough for another development team to estimate the same scope and see what is still uncertain.
In custom software for operating businesses, discovery is mostly about the process, not the screens. The screens follow once everyone knows how an order, an invoice or a request moves through the company and where it gets stuck.
What happens during discovery#
The steps below are the ones we follow. Other teams name them differently, but a useful discovery covers the same ground.
- Understand the work as it runs. We sit with the client's employees and follow how an order, an invoice or a request actually moves.
- Audit what already runs. We go through the systems and the process the client already has before proposing anything. Often part of it does not need rewriting, and that is cheaper to find out at the start than halfway through.
- Map it. The key steps, tools, hand-offs and known exceptions go on one map. It often shows gaps and dependencies nobody saw before. How to map a business process has a post of its own.
- Simplify. Some steps exist only because two tools could not pass data to each other. Those are removed on paper before anyone builds them in software.
- Decide what does what. Work that follows clear rules becomes ordinary software, and where a rule will do, no AI is added. For the small, routine decisions where something has to be understood, weighed and chosen, such as reading an inconsistent PDF or email, discovery checks whether AI can do them reliably. Complex decisions stay with a person, who gets the AI's comments.
- Write it down and price it. The result is a specification with an estimate, the assumptions behind it and an order of work.
A real example: rules written before the software#
At MedoraOne, a medical-tourism marketplace, an AI agent now researches doctors in public sources and writes their profiles. Profiles used to be written by hand, and the same hospital appeared under three spellings. Before the agent ran, we wrote down the sixteen editorial rules every profile must follow. Titles and names are written in Latin letters. A doctor's main specialty comes only from the current hospital's page. Hospitals are always named in English. A year is never guessed.
The client could read each rule and dispute it. The agent was then built to follow them, and the software that lays out each profile checks eight of the sixteen automatically. That is what discovery is for: the rules exist in writing, and both sides agree on them, before anyone builds the thing that has to follow them.
What you get at the end: a sample specification#
A discovery phase is worth paying for only if it leaves something you can use without the team that wrote it. The main deliverable is a written specification. Below is a sample outline of one. It is generic, not taken from a client's project. The parts grow or shrink with the project, but a useful specification covers all of them.
| Part | What it holds |
|---|---|
| 1. Goal | What the business wants to change, and how you will tell after launch that it did |
| 2. Process map | How the work runs today and after the change: the steps, who does each, the tools, hand-offs and exceptions |
| 3. Rules and exceptions | Each rule in one sentence the business can check, such as "an order over the customer's credit limit waits for the owner", and who handles each exception |
| 4. Scope and first release | What is in the first version, what goes live first, what waits and what is left out |
| 5. Integrations and constraints | Which systems the software must work with, what each one allows, and what was checked |
| 6. Estimate with assumptions | The cost of each part, and the assumptions each number depends on |
| 7. Order of work | The stages, and the written acceptance criteria that say when each one is done |
| 8. Open questions and risks | What is still unknown, how it could move the estimate, and how it will be settled |
The sixteen MedoraOne rules above are an example of what part 3 holds.
The document is yours whether or not we build it. You can take it to another team, ask several teams to bid on it, or decide not to build at all.
How long discovery takes and what it costs#
Published discovery prices vary widely. One development agency, based in Colombia, lists $5,000 to $15,000 as a fixed fee for its own two-to-four-week discovery.1 Another, with its head office in India, quotes $1,500 to $4,000 and one to two weeks for a small internal tool, and up to $30,000 and four to six weeks for an enterprise system. It puts discovery at 5 to 10% of the development budget.2 These are individual agencies' own prices, not industry averages, and rates differ from country to country.
The price matters less than what is included. A short requirements workshop and a full specification with an estimate are different services. We agree on the price of discovery before it starts, and it depends on how complex the request is. For any one team, the price and the time depend mainly on three things:
- how much of the business the software touches;
- how many existing systems it has to work with, and how well documented they are;
- how much is still unknown, such as whether a supplier's system can send data at all.
A small project, especially one close to work we have already done, may not need a separate discovery at all.
Why pay for discovery instead of taking a free estimate#
A free estimate, from a call or an online quote, gives a useful budget range. But it rests on assumptions nobody has yet tested against real orders, real documents and the systems the software has to work with. A team that prices development from those assumptions usually either adds a margin for what it does not know, or quotes low and sends change requests later.
A specification reduces that uncertainty and makes the remaining assumptions visible. It is what makes an honest fixed price possible, and it shows which parts are too uncertain to fix in advance. More on that in time and materials vs fixed price.
What comes after the discovery phase#
With the specification in hand, there are three ways forward:
- Build it with the same team. Work starts with the first release, the smallest part that can go live on its own. The stages the specification defines can be priced as fixed stages, with written acceptance criteria for each milestone. Integration work and parts where the scope will move are billed hourly, with a monthly invoice.
- Build it with another team. The specification is detailed enough to quote from, so quotes can be compared on the same scope.
- Do not build it. Sometimes discovery shows that the existing tools can do the job once a few steps are removed, or that off-the-shelf software covers the rules.
How to prepare for discovery#
Discovery goes faster when the client brings:
- real examples: a dozen orders, invoices or emails as they actually arrive, including the messy ones;
- access to the tools in use, or screenshots of them;
- an hour or two with the people who do the work, not only with the managers;
- a list of what goes wrong: the exceptions, the corrections, the cases that always need the owner;
- what you would measure after launch, such as time per order or errors per week.
If the examples hold personal, financial or medical data, agree on a secure way to share them, or on anonymized copies, before sending anything.
Where to start#
If you are planning custom software, start with a free 30-minute call about one process in your business. We will say where automation fits and where it does not, and what a discovery for it would cover. The order we work in is on its own page.
Sources
-
Leanware, "Project Discovery Phase Cost: Sprint 0 Pricing Explained", updated September 15, 2026. https://leanware.co/insights/discovery-phase-cost ↩
-
Acquaint Softtech, "What Is a Software Discovery Phase, What Does It Cost, and Why Skipping It Fails", April 27, 2026. https://acquaintsoft.com/blog/software-discovery-phase-cost-why-skipping-fails ↩
