Project Discovery Phase Cost: Sprint 0 Pricing Explained
A software project discovery phase costs $5,000 to $15,000 USD as a fixed fee and usually takes 2 to 4 weeks. That is the range for Leanware’s own Sprint 0 model, not a claim about the average market price. The final fee depends on the complexity of the discovery work.
What a Discovery Phase Actually Is
A discovery phase in software development is the structured work done before development to define the product, technical approach, and build plan. Vendors also call it a discovery sprint or product discovery. It is not a sales call or a free estimation session; the difference is the deliverable. A software development discovery phase also helps answer key product and technical questions before the build begins.
How Much a Discovery Phase Actually Costs
A software development discovery phase costs $5,000 to $15,000 USD as a fixed fee, depending on complexity. This differs from hourly discovery, where the final cost depends on how many hours the vendor spends.
Leanware calls this work Sprint 0. It is a fixed-scope, fixed-fee product discovery sprint that runs for two to four weeks, with the fee agreed before the sprint starts. You can see the scope and current pricing for Leanware’s Sprint 0 service before deciding whether this type of discovery fits your project.
Sprint 0 turns an early product idea into a plan an engineering team can actually build.
The Fixed-Fee Range in Practice
For a mid-complexity software build, Sprint 0 typically lands between $5K and $15K and runs for two to four weeks. The fee is set at signing, based on the complexity of the discovery work, rather than reconciled from hours after the sprint.
If you agree to a $10,000 Sprint 0, the discovery fee is $10,000. The client does not have to guess whether the final invoice will be $12,000, $15,000, or more because the team spent additional hours. The fixed fee also creates a clear stopping point: Sprint 0 ends with defined deliverables and a decision about whether to continue into development.
Why Two to Four Weeks
Two to four weeks gives the team enough time to resolve meaningful product and technical questions without turning discovery into another long project. The team can examine the scope, integrations, design direction, and technical risks while keeping discovery short enough to remain a decision point before development begins.
The goal is not to discover everything that could ever happen to the product. It is to remove the unknowns that could materially change the first build.
What Moves the Price Inside That Range
Three factors drive the cost inside the $5,000 to $15,000 range: scope surface, integration depth, and the amount of technical uncertainty the sprint must resolve. A larger product surface needs more definition, more integrations require more investigation, and greater technical uncertainty requires more engineering work before the build can be planned.
Scope Surface
Scope surface refers to the amount of the product that needs to be understood during discovery. A product with three simple workflows is very different from one with twenty workflows, multiple user roles, and interconnected screens.
For example, a basic internal dashboard used by one type of employee may require only a small number of user journeys. A marketplace with buyers, sellers, administrators, support staff, and finance users, each with their own permissions and workflows, is a much larger surface, and that surface is what drives the discovery work.
Scope surface is about the product experience, not lines of code or development hours. The discovery team needs to understand what users can do, which roles can do it, and how the major parts of the product connect. That work helps prevent a common problem: starting development with a product that sounds clear in a meeting but is not clear enough to build.
Integration Depth
Existing systems can significantly change the amount of discovery required. A new application may need to connect to a payment provider, CRM, ERP, identity provider, analytics platform, or internal database. Each connection can introduce questions that cannot be answered by looking only at the new product.
Consider a customer portal that needs to connect to an existing CRM. The portal may need customer records from the CRM, send updates back, use another system for authentication, and pull data from an older database. The discovery team therefore needs to understand what systems exist, how they communicate, what data is available, and where their constraints could affect the new product.
Integration depth is more than a minor technical detail. It can account for a large part of the discovery work, especially when the new product must sit on top of several existing systems rather than running mostly on new infrastructure.
Technical Unknowns the Sprint Must Settle
Technical uncertainty is another major reason discovery is priced separately from development. The client is paying to remove risk before committing to the larger build.
There may be questions about whether a feature is possible. For example, can a third-party service support it? Is the required data ready? Will the technical approach work at the expected scale?
The team may also need to define the architecture. This includes how the main components will work together, how data will be stored, and what infrastructure and authentication are needed.
Data readiness can create another unknown when existing information is incomplete, inconsistent, or stored in a format that does not match the proposed product experience.
These questions are cheaper to resolve before development starts than after several weeks of engineering work. Technical discovery is therefore engineering work that reduces the chance of making an expensive decision too late.
What You Should Get for That Price
The four Sprint 0 deliverables are non-negotiable regardless of where the project lands within the $5,000 to $15,000 range. The client keeps all four deliverables whether or not they decide to continue with Leanware for the development phase.
Discovery should produce an engineering asset, not only a proposal deck.
UI/UX Design and Design System
The design output is an overarching UI/UX direction and design system for the product, rather than simply a collection of wireframes for one user flow.
The design system gives the future build a foundation to extend. It defines the visual and interaction direction that the product can use across its major screens and workflows, making the design useful beyond the discovery presentation and giving the engineering team material it can use during development.
Epics and User Stories with Acceptance Criteria
Sprint 0 translates the product scope into epics and user stories with acceptance criteria. These stories are sized and structured so they can be handed to an engineering team rather than written only for Leanware's internal process.
Acceptance criteria explain when a piece of work is complete. They also make the work easy to use elsewhere. If the client chooses an internal team or another development company, the stories can still guide the planning and development.
The discovery phase should give the client a clearer view of the product than they had at the start.
Billable Milestone Plan
The milestone plan breaks the build into clear stages. Each milestone has its own price. The client can see what the team will deliver at each stage and how much it will cost.
This connects discovery directly to the later billing model. Leanware describes its engagement model around milestone-based billing, where payments map to delivered and accepted milestones rather than hours logged.
The milestone plan doubles as the financial plan: the client sees each stage and its price before the build begins.
Technical Architecture and Repository Scaffolding
The technical architecture is delivered as a working starting point, not only as a diagram. Repository structure and infrastructure groundwork give the build a technical foundation that the engineering team can extend.
Some discovery phases stop at documentation. A diagram can explain an architecture, but it does not create the structure you need to start building. Leanware's Sprint 0 model includes technical architecture with repository scaffolding and infrastructure groundwork.
Why Portability Is the Real Test of a Good Discovery Phase
A client should be able to take every discovery deliverable to another vendor or an in-house engineering team. That is the intended design of the fixed-fee model, not an exception to it.
If the discovery output only makes sense inside the vendor's own process, its value is limited. Could another competent engineering team take the epics, user stories, acceptance criteria, design system, milestone plan, and technical architecture and understand what needs to happen next?
If the answer is yes, the discovery has produced an independent engineering asset. If not, the client may have paid for a sales document rather than a reusable product plan.
Leanware's engagement model explicitly states that clients can stop at a milestone and keep the work delivered, including code, infrastructure configuration, and documentation. For more context on how this works after discovery, see Leanware’s engagement models guide.
The Two Traps to Watch For
The cheapest discovery option is not always the lowest-risk option. Two pricing structures are worth examining closely: free discovery and open-ended hourly discovery. Neither is automatically wrong; the issue is what the pricing structure is designed to produce.
Free Discovery as Sales Qualification
A free discovery phase is often a sales qualification exercise presented in engineering terms. Its main output is usually information that helps the vendor decide whether and how to pursue the project.
That can be useful before an engagement, but it is not the same as paid product discovery that produces reusable engineering deliverables for the client. A free call can help a vendor qualify an opportunity, while a paid discovery sprint should help the client make a build decision.
Open-Ended Hourly Discovery
Hourly discovery without a fixed scope has no structural reason to end. If the questions keep growing, the bill can keep growing with them, leaving the client to carry that uncertainty.
There may be no clear point where the discovery work is complete. A team can continue investigating requirements, architecture, integrations, and edge cases without reaching a defined deliverable boundary.
A fixed-fee discovery sprint provides the direct alternative: the scope is defined first, the fee is agreed first, and the work ends within the agreed window. That does not mean every unknown is eliminated. It means the team has a defined period and scope in which to resolve the unknowns that matter to the build.
How This Compares Across the Market
The $5,000 to $15,000 range is Leanware's own published Sprint 0 price, fixed by complexity over two to four weeks, not an industry average.
Discovery pricing varies because vendors define discovery differently. One company may offer a short requirements workshop, another may include UX research, while another may include technical architecture and repository setup. These are not identical products.
It is also useful to compare the pricing model, not only the price. A $7,000 discovery sprint with clear deliverables is not necessarily comparable to a $7,000 hourly engagement with an open-ended scope. The amount may be the same while the client's financial exposure is very different.
The same applies to the build phase. Leanware's pricing model guide describes milestone-based development as a structure where the project is divided into milestones with written acceptance criteria and individual prices.
If you want a broader explanation of software development estimation and billing structures, see Leanware’s software development pricing models guide.
Final Thoughts
A project discovery phase costs $5,000 to $15,000 as a fixed fee in Leanware's Sprint 0 model, with the work completed over two to four weeks. The price is based on the scope, integrations, and technical uncertainty the sprint needs to resolve.
The better test is not whether discovery is cheap. It is whether the client leaves with useful, portable engineering work. A fair discovery phase should give the client enough information to make a build decision and enough deliverables to move forward with the team of their choice.
For readers with a real product to scope, the next step is to contact Leanware and ask the team to scope the appropriate Sprint 0 for the project.
Frequently Asked Questions
How much does a project discovery phase cost?
A project discovery phase costs $5,000 to $15,000 as a fixed fee and takes 2 to 4 weeks in Leanware's Sprint 0 model. The only variable within that published range is project complexity. More product surface, deeper integrations, or greater technical uncertainty can require more discovery work.
What determines the final discovery phase price?
The final price is determined by three factors: how much of the product must be mapped, how deeply the new system must connect with existing technology, and how many important technical questions need to be resolved. These factors determine the amount of senior product and engineering work required during Sprint 0.
What deliverables should I receive at the end of a discovery sprint?
You should receive four core outputs: an overarching UI/UX design and design system, epics and user stories with acceptance criteria, a priced milestone plan for the build, and technical architecture with repository scaffolding. These outputs should remain useful even if you decide not to continue with the same development vendor.
Can I take the discovery output to another software vendor?
Yes. Portability is the intended design of the Sprint 0 model. The client keeps the discovery deliverables and can give them to another development company or an internal engineering team. The scope, stories, design work, milestone plan, and technical architecture are created as reusable project assets rather than documents that only work inside one vendor's process.
What is the difference between free discovery and a paid discovery sprint?
Free discovery is generally optimized for vendor qualification and sales decisions, while a paid discovery sprint is optimized for the client's product and build decision. Paid discovery has defined scope, dedicated engineering work, and concrete deliverables. Free conversations can be useful, but they should not be treated as equivalent to a full product discovery engagement.