8 min readDo You Need a Discovery Phase Before Building Your Software Product?
If you're commissioning custom software, an agency will probably propose a discovery phase before writing any code. It will cost you somewhere between $5,000 and $40,000, take two to six weeks, and produce a stack of documents instead of a working product. So the question founders ask is obvious: can we skip it and just start building?
The short answer is that you can skip it, but the data says you shouldn't. Projects that skip upfront scoping exceed their budgets by an average of 189%, according to published industry research. A discovery phase typically costs 5-10% of the total project budget, which means the cost of skipping it is usually an order of magnitude higher than the cost of doing it.
But that's an average, and your project might not be average. Here's what a discovery phase actually delivers, what it costs, and when you can reasonably skip it.
What You're Actually Paying For
A discovery phase is structured research and planning before development starts. The agency interviews stakeholders, maps user workflows, identifies technical constraints, writes a specification, and estimates the work with enough detail that both sides know what's being built and roughly what it will cost.
The standard deliverables are:
- Technical specification: feature list, user stories, acceptance criteria, and edge cases documented in enough detail that a developer can build from it without guessing
- Wireframes or low-fidelity prototypes: screen flows showing how users move through the product, with no visual design but enough structure to confirm the logic works
- System architecture diagram: how the pieces connect, what services or APIs you're integrating, where data lives, and what scales or breaks first
- Project timeline and cost estimate: a week-by-week breakdown with milestones, dependencies, and a fixed or ranged budget
- Risk assessment: the technical, market, or resource constraints that could delay or derail the project, and what you'd do about each one
These aren't aspirational. If an agency proposes a discovery phase and doesn't commit to producing all of these artifacts, ask why.
What It Costs and How Long It Takes
The market range for a discovery phase is wide because project complexity varies. A straightforward mobile app with a REST API and a content management system might need two weeks and $5,000 to $15,000. A multi-sided marketplace with payment processing, real-time matching, and third-party integrations could justify six weeks and $25,000 to $40,000.
Most agencies price discovery as a fixed fee, not time and materials, because the scope is predictable: a defined set of conversations, documents, and diagrams. The timeline depends on stakeholder availability more than agency capacity. If the founders can commit to structured interviews and feedback rounds, two to three weeks is realistic. If everyone's squeezing it between other commitments, plan for four to six.
One published estimate puts the cost at 5-10% of the total project budget, which is a useful cross-check. If an agency quotes $10,000 for discovery and then $200,000 for build, the ratio is right. If they quote $40,000 for discovery and then $80,000 for build, either the discovery is padded or the build is underestimated.
When Skipping It Costs You More
The case for discovery is economic, not philosophical. It prevents three expensive failure modes that are common in software projects:
Scope creep during development. Without a specification, every ambiguous requirement becomes a mid-project negotiation. The developer implements what they think you meant, you see it and realize it's not what you needed, and now you're paying to redo work that should have been clarified up front. This is the most common source of budget overruns.
Building the wrong product. If you move straight from a rough idea to code, you don't test the logic of the user experience until it's already built. Discovering that a core workflow doesn't make sense after you've invested two months of engineering time is far more expensive than discovering it during a one-week wireframing exercise.
Technical debt from poor architecture decisions. Agencies making technology choices without a full picture of your requirements will default to what's fastest to build right now, not what's easiest to scale or maintain later. A discovery phase surfaces the constraints that matter, like integration requirements, expected load, or regulatory compliance, early enough to make the right architectural trade-offs.
The McKinsey research cited in the industry suggests that a significant portion of IT projects go badly enough to threaten the business. That's not because developers are incompetent. It's because building software is a process of learning what you actually need, and doing that learning after you've already committed to an implementation is far more expensive than doing it before.
When You Can Skip It
Discovery isn't a universal requirement. You can skip it if:
-
You have a detailed specification already. If you've been through this process with another agency or an internal technical co-founder has already written user stories, wireframes, and architecture diagrams, you don't need to pay someone else to redo that work. Just make sure what you have is actually detailed enough to build from, not a high-level product vision.
-
The project is small and low-risk. A basic informational website, a simple internal tool with fewer than five screens, or a proof-of-concept prototype where you expect to throw away the first version can often move straight to development. The cost of getting it slightly wrong is low enough that iterating in code is faster than planning up front.
-
You're working with a team that already knows your domain and technical context. If you're adding features to an existing product with a team that built it, they don't need to re-learn your business model or technical stack. Discovery makes sense for new projects with new teams, not ongoing maintenance.
The common thread is certainty. If you already know exactly what needs to be built, how it should work, and what the technical constraints are, discovery is redundant. If any of those things are unclear, the cost of figuring them out during development is almost always higher than the cost of a discovery phase.
What to Ask the Agency
If an agency proposes a discovery phase, ask:
- What specific deliverables will we receive, and in what format?
- Who on your team will be involved, and how much of the founders' time do you need?
- What happens if the discovery reveals the project will cost more than our budget?
- Is the discovery fee credited toward the build if we proceed with you, or is it separate?
If an agency doesn't propose discovery for a project with any meaningful complexity or ambiguity, that's a red flag. It suggests they're either planning to figure it out as they go (which means you'll pay for the learning curve), or they've underestimated the project and will come back mid-way through with a revised budget.
How to Use the Output
The value of a discovery phase isn't the documents themselves. It's the shared understanding those documents represent. By the end of discovery, you and the agency should be able to independently describe what's being built, how long it will take, and what the biggest risks are, and your answers should match.
That alignment is what prevents the expensive surprises. It also gives you a basis for evaluating progress during the build. If the agency committed to specific features, timelines, and milestones during discovery, you can hold them to those commitments and intervene early if things drift.
If you do commission a discovery phase, make sure you're set up to act on it. That means having the budget and timeline available to proceed to build if the discovery validates the project, or the willingness to pivot or pause if it doesn't. Paying for discovery and then sitting on the results for six months while you secure funding or internal buy-in is a waste. The specification will be stale, the market will have moved, and you'll need to redo parts of it when you're ready to proceed.
Making the Call
Discovery is a hedge. You're paying a small amount up front to reduce the risk of a much larger loss later. For most custom software projects, especially if you're non-technical or this is your first time commissioning development, that hedge is worth it. The cost of building the wrong thing, or building the right thing badly, is almost always higher than the cost of planning properly.
If you're deciding whether to include a discovery phase in your next software project, Stardelite can walk you through what that looks like for your specific scope and budget. Get in touch and we'll help you figure out the right approach.
References
Share this:
5 min read