Every week I talk to a founder or operations manager who wants to start development immediately.
They have a brief. Sometimes a wireframe. Occasionally a detailed spec. They want to start sprints next Monday. They want code by the end of the month. They want to launch in twelve weeks.
My first question is always the same: have you done a discovery phase?
The answer is almost always no.
My second question is: do you know what a discovery phase is?
The answer is usually vague — something about requirements gathering, something about planning. Rarely a clear picture of what it actually involves, what it produces, or why it exists.
This guide is the complete answer to both questions — written from the perspective of someone who has run discovery phases, skipped discovery phases when clients insisted, and spent years cleaning up the consequences of projects that launched without one.
What is a software project discovery phase?
The discovery phase is the structured period of work that happens before development begins. Its purpose is to answer the questions that determine whether the project will succeed — before committing the time and budget required to actually build the thing.
Those questions are:
- What problem are we actually solving?
- Who has the problem and how do they experience it?
- What does the solution need to do, exactly?
- What does it need to integrate with?
- What are the technical constraints and risks?
- What will it actually cost and how long will it actually take?
- What does success look like in six months?
None of these questions have obvious answers. They feel obvious at the start of a project — until you try to answer them precisely and discover that what seemed clear was actually ambiguous, what seemed simple was actually complex, and what seemed agreed was actually contested between stakeholders.
The discovery phase is the process of finding that out before it costs you a sprint.
What the discovery phase is not
Before going further, it's worth being clear about what discovery is not.
It is not just a requirements document. A requirements document is one output of discovery. Discovery is the process that produces it — which involves interviews, research, analysis, and decision-making, not just documentation.
It is not design. Discovery sometimes produces wireframes or UX concepts, but its primary output is understanding and documentation, not visual design. Full UX design typically comes after discovery.
It is not development. Nothing is built during discovery. No code is written. The output is documents, not software.
It is not a formality. Discovery is sometimes treated as a box-ticking exercise required by an agency before they start "real work." When it's done well, it is the most valuable work in the entire project. When it's done badly — rushed, superficial, check-the-box — it produces the false confidence of having documentation without the actual understanding that documentation should represent.
What happens during a discovery phase
Discovery phases vary in scope and formality depending on project size. For a focused SaaS MVP, discovery typically runs 2–4 weeks. For a complex enterprise platform, 4–8 weeks. For a large system replacement, 6–12 weeks.
Within that timeframe, here is what actually happens:
Stakeholder interviews and business analysis
The development team meets with the people who understand the problem — typically the product owner, key users, and anyone whose operations will be affected by the system. The goal is to understand the business context before touching the technical requirements: why does this need to exist, who uses it, what do they do now, what specifically isn't working about the current approach?
This sounds simple. It produces surprises more often than not.
The most valuable discoveries in this phase are usually the things nobody thought to put in the brief. The workflow that runs in a different system that needs to integrate. The user type that isn't mentioned in the specification but whose requirements fundamentally affect the architecture. The constraint — a deadline, a compliance requirement, a legacy system — that changes what's possible.
User journey and workflow mapping
Before defining features, we map what users actually do — not what we think they do, but the step-by-step reality of how they complete the tasks the system needs to support.
User journeys expose gaps and conflicts that feature lists miss. A feature list might say "users can approve purchase orders." A user journey reveals that there are three different approval workflows depending on amount, department, and supplier type — and that the current manual process has eight exceptions that need to be systematically handled rather than individually worked around.
The journey map becomes the test: does the system we're designing actually support every step of what the user needs to do?
Technical architecture assessment
Once requirements are understood, the technical architecture needs to be defined. This is not the same as choosing a programming language. Architecture decisions at this stage include:
Data model design. How is the data structured? What are the relationships between entities? What data needs to be stored and in what format?
Integration requirements. What external systems does the new software need to connect to? What APIs are available? What are the integration constraints?
Infrastructure decisions. Where does this run? Cloud hosting, containerisation, database choices, CDN requirements.
Scalability considerations. What load does the system need to handle now? In 12 months? In 3 years? Architecture decisions that accommodate future scale are dramatically cheaper than retrofits.
Security and compliance. What data is being handled? What regulatory requirements apply — GDPR, HIPAA, the Australian Privacy Act? What authentication architecture is required?
These decisions can't be made well without the understanding that stakeholder interviews and workflow mapping produce. Architecture follows requirements. Requirements follow understanding. Understanding requires discovery.
Risk identification
Every software project has risks. Discovery is the point at which they should be identified explicitly, rather than discovered mid-sprint when they're expensive to address.
Common risks identified in discovery:
- Third-party APIs that are poorly documented or unreliable
- Legacy systems with no API access that require custom integration approaches
- Regulatory requirements that constrain architecture options
- Stakeholder disagreements about scope or priorities that need to be resolved before development
- Timeline constraints that make the proposed scope undeliverable
- Data migration requirements that are significantly more complex than anticipated
Identifying a risk in discovery costs hours. Discovering the same risk in sprint seven costs weeks.
Scope definition and estimation
With requirements understood and architecture designed, it becomes possible to define scope with precision and estimate effort with reliability.
Discovery-backed estimates are consistently more accurate than pre-discovery estimates. They have to be — pre-discovery estimates are based on incomplete information. The scope isn't fully defined. The integrations aren't fully understood. The edge cases haven't been identified.
This is why agencies that skip discovery tend to have larger scope disputes mid-project. The original estimate was based on incomplete information. Discovery would have revealed the gap.
What does a discovery phase produce?
At the end of a well-executed discovery phase, the client should have:
A functional specification. A document describing every feature the system will include, how each feature works, what it looks like from the user's perspective, and what the acceptance criteria are for each feature. Specific enough that both parties can be held accountable to it.
A technical architecture document. The design of the system — database schema, API structure, integration approach, deployment architecture, security model. The blueprint the development team builds from.
A user journey map. All primary user types and the journeys they take through the system — from onboarding to every core workflow.
A risk register. Every identified risk, its likelihood and impact, and the proposed mitigation approach.
A project estimate. Timeline and budget for the development phase, based on defined scope and understood complexity. Not a ballpark. An actual estimate with the basis of that estimate documented.
A sprint plan. How the development work is broken into sprints, what's in each sprint, and what the deliverable at the end of each sprint is.
The quality test for a discovery deliverable: could the development team build the system from this documentation without asking you a hundred clarifying questions? If the answer is yes, the discovery was thorough. If the answer is no, it wasn't.
Why projects that skip discovery fail in predictable ways
Over eight years I have watched projects fail for many different stated reasons. The stated reason is almost never the real reason.
Projects that skip discovery fail because:
The requirements were ambiguous. Nobody noticed until development was half done and the developer built a different interpretation of the requirement than the client had. Fixing the difference requires re-work. The re-work costs more than discovery would have.
An integration was more complex than anticipated. The third-party API the project depended on had incomplete documentation, had been deprecated, or required a different approach than planned. Two weeks into development, the project has a fundamental problem that needs to be redesigned. Discovery would have surfaced this.
Stakeholders disagreed about scope. The product manager and the operations director had different ideas about what the system should do. Neither articulated the difference clearly during briefing. Both assumed their interpretation was shared. In sprint four, the conflict becomes visible and irreconcilable without pausing development.
The estimate was wrong. The original brief described the system at a level of generality that made it impossible to estimate accurately. The agency estimated what they understood, which was less than what was actually needed. The project runs 50% over budget. Everybody blames each other.
Post-discovery, we built i-mve — a full SaaS platform for the UK removals industry — on a clean, agreed specification. It is now live and used by hundreds of UK companies. The discovery phase took three weeks. The development was predictable, the estimate was accurate, and the client got exactly what they expected. I don't think that's a coincidence.
How long does a discovery phase take?
It depends on project complexity:
| Project type | Discovery duration | Why |
|---|---|---|
| Simple SaaS MVP (2–3 features, 1–2 integrations) | 2–3 weeks | Focused scope, limited technical risk |
| Full SaaS platform (6–10 features, 4–6 integrations) | 3–5 weeks | More workflows to map, more architecture to design |
| Enterprise system (multiple modules, legacy integration) | 4–8 weeks | Complex stakeholder environment, significant technical investigation |
| System replacement (replacing existing live software) | 6–10 weeks | Data migration, downtime planning, user transition |
These are working weeks of active engagement — not elapsed calendar time. The clock stops when waiting for client inputs.
What does a discovery phase cost?
Discovery is priced as a separate engagement from development. It is not included in the development estimate because the development estimate cannot exist until discovery is complete.
Typical discovery pricing:
| Scope | Typical cost range |
|---|---|
| Simple MVP discovery | $3,000–$6,000 |
| Standard SaaS platform discovery | $5,000–$12,000 |
| Enterprise system discovery | $10,000–$25,000 |
This is the most reliably cost-effective investment in any software project. A $6,000 discovery that prevents one sprint of rework pays for itself. A $10,000 discovery that correctly scopes a project that would otherwise have run 30% over budget saves $30,000–$80,000 on a mid-size project.
The founders and operations managers who push back on discovery cost are consistently the ones who experience the largest budget overruns. Not because they're making a bad decision — but because they haven't yet experienced what mid-project scope disputes, architectural redesigns, and requirement misalignment actually cost when they occur in sprint six rather than in week two of discovery.
Can you skip discovery?
Sometimes.
Discovery can be shortened or skipped when:
The scope is genuinely small and well-understood. A focused project with 2–3 features, no integrations, and a client who has thought through requirements thoroughly can move to development faster.
The client has done their own thorough discovery. Some clients arrive with detailed functional specifications, user journey maps, and a clear risk register. When this is the case, we review what they've produced rather than producing it ourselves.
You're extending an existing system. Adding a new module to a system we built and understand doesn't require the same level of architectural investigation as a greenfield project.
It's a time-and-materials engagement with high change tolerance. If the client expects requirements to evolve and is comfortable with scope being defined as development progresses, a formal discovery phase is less critical.
What you can't skip: understanding the problem before building the solution. Whether that understanding comes from a formal discovery phase, from the client's own prior work, or from a hybrid approach, the understanding needs to exist before decisions are made in code.
The discovery phase in our process
At Teamseven, we recommend a discovery phase for every project over $15,000. Below that threshold, projects are typically small and focused enough that a thorough requirements conversation before sprint one serves the same purpose.
We run discovery as a fixed-fee engagement separate from development. At the end of discovery, the client has a specification, an architecture document, and a development estimate. They can take that to us for development, or take it to another agency. We've had clients do both.
We prefer it this way because it aligns incentives correctly. If we rush discovery to get to development faster, we get a harder development phase. If we do discovery well, development is predictable and the client's experience is good. The incentive to do discovery thoroughly is built into the structure.
Muhammad Nabeel is the co-founder of Teamseven, a software development agency based in Lahore, Pakistan. We've run discovery phases for startups and enterprises across the US, UK, and Australia since 2017. If you're at the start of a software project, get in touch — a 30-minute conversation before you commit to anything is always worth doing.