Our base software discovery phase is an investment of only $1,995, and takes two to three weeks, with kickoff 7-10 business days after signing. For that you get a requirements document, API recommendations, development considerations, pricing for the build, and a timeline, all of which are yours to keep whether you build with us or with anyone else. Across the industry, a discovery phase is priced as a small fraction of the build it defines, and ours is deliberately at the low end of that: against the $25k-$100k a focused first version of a custom product typically costs, $1,995 is under five percent of the smallest build it would scope. The rest of this guide covers what that money actually buys, why the price is fixed, how it compares to a free quote, and the handful of situations where you don't need a discovery phase at all.
What a discovery phase is paying for
Discovery is the work of deciding what to build, in what order, on what foundation, and for how much, before anyone writes production code or begins a design. The price covers people's time, and the time goes to a specific list of activities:
- Stakeholder interviews. Conversations with the people who own the problem, run the workflow today, and will use or buy the product, so the scope reflects what the business needs instead of what one person remembered to mention.
- Product and workflow analysis. Mapping how the work happens now (spreadsheets, emails, the tool everybody hates) and where software changes it.
- Feature prioritization. Sorting every requested feature into what version one needs, what comes next, and what waits. This is where most of the savings in a build come from.
- User mapping. Who the users are, what each type needs to accomplish, and which single workflow proves the product works.
- Technical recommendations. Architecture, frameworks, hosting, and the third party services the product will depend on, chosen for your scale and timeline rather than the team's habits.
- Code review, when there's existing code. If you already have a prototype, an AI built MVP, or a product from a previous vendor, discovery includes reading it and deciding what survives.
- Integration and system planning. The APIs, data sources, and existing systems the product has to talk to, and what each connection will take.
- A delivery roadmap with cost and timeline. The whole plan priced line by line and sequenced into phases.
Two to three weeks is enough for all of that on most products because the work is focused. We're defining one product with one set of stakeholders, and we've done it enough times to know which questions matter.
What you get for it
The deliverables are the point, so here's what lands in your inbox at the end:
- A requirements document. Every feature of version one described in enough detail that any competent team could build from it.
- API recommendations. Which third party services and integrations the product needs, which we'd choose, and why.
- Development considerations. The technical decisions, risks, and trade offs the build will have to handle, written down before they become surprises.
- Itemized feature pricing. A fixed price for the build, broken out by feature, with options from a core MVP up to the full product.
- Timelines. How long each phase takes and when the product can be in front of users.
We've answered what you get at the end of a discovery engagement in more detail, and the short version of the ownership question is that the documents are yours. You can take them to another firm, hand them to an in house team, or put them in a drawer. Most clients continue with us because we already understand the product, and you're never required to.
Why the price is fixed
A fixed price for discovery does two jobs. It tells you exactly what the scoping phase costs before you commit, and it proves the firm can scope its own work, which is the skill you're about to pay it to apply to yours. A vendor that can't put a number on a two week planning engagement is going to struggle to put a number on a six or twelve month build.
It also keeps the incentives clean. When discovery is billed hourly, the phase stretches. When it's folded into the build, the build price has to absorb it somewhere. A separate, fixed, modest fee means the firm has to be efficient about discovery and you can judge the firm on the deliverables before you spend a larger sum. The same logic applies to the build itself, and discovery is the step that makes a fixed build price possible in the first place.
How a paid discovery compares to a free quote
Plenty of firms will quote your project for free after a call or two. Understand what you're getting. A number produced without discovery is an estimate built on assumptions the firm hasn't tested, and it gets corrected later, at your expense, through change orders, a longer timeline, or a product that quietly shrinks to fit the price. Free quotes aren't free, long term they will cost you way more.
A paid discovery moves that correction to the front, where it's cheap. The firm has read your workflow, talked to your users, understood your problem, looked at your existing code, and priced each feature individually. The number that comes out is one you can hold someone to. It also makes bids comparable: hand the same requirements document to three firms and you're finally comparing prices for the same product. Our custom software cost guide explains why quotes for the "same" project vary so much, and most of the variance comes from vendors pricing different, unstated assumptions.
What skipping discovery costs
The expensive version of this story is familiar to anyone who has run a software project. Development starts on a verbal understanding. Three weeks in, a stakeholder nobody interviewed explains that the real workflow has an approval step. The data model changes. Features built on the old model get rebuilt. The integration everyone assumed was simple turns out to need a vendor contract. The launch date moves twice. By the end, the team has built some features twice and some that nobody uses, and the budget went where the plan should have been.
Most of what we see in rescue work traces back to a skipped or shallow scoping phase, and we wrote up the signs that software needs a rescue partly so founders could recognize the pattern earlier. Discovery doesn't make a project risk free. It moves the discoveries to the two weeks when they cost a conversation instead of a sprint and your entire budget.
When you don't need a discovery phase
Honest answer: sometimes you don't, and we'll say so on the strategy call. A few situations where paying for discovery is the wrong move:
- A small, well defined change to an existing product. Adding an export button doesn't need a requirements document. It needs a ticket and an estimate.
- A true throwaway experiment. If you want a landing page or a clickable prototype to test demand before you decide whether to build anything, discovery is overkill. Build the cheap test first.
- You've just finished a thorough discovery elsewhere. If another firm handed you a complete requirements document, pricing, and a timeline last month, we'll review it rather than redo it. We will be honest if we see holes in their document and be upfront if we dont have enough information.
What doesn't exempt you is being sure of what you want. Founders with a clear vision benefit from discovery as much as anyone, because the phase isn't there to second guess the vision. It's there to find the hidden complexity in it while that's still cheap, and nearly every clear idea has some. We have worked with hundreds of clients that come to us with a simple one or two sentence problem, we work with them to build the vision.
How to get the most out of the two to three weeks
Discovery is a collaboration, and the quality of the output tracks the quality of the input. The clients who get the most from it do a few things:
- Put the right people in the interviews: whoever runs the workflow today, whoever owns the budget, and whoever will say no to features.
- Bring the existing material: process documents, spreadsheets, screenshots of the tool you're replacing, and any existing code or prototype, including AI built ones.
- Share the two to three year view. What you want the product to do eventually changes what we recommend for version one, especially in the data model and architecture.
- Decide on the hard questions when they come up. Discovery surfaces decisions. Making them during the phase is what keeps it to a few weeks.
If you're building a first version, our guide to what an MVP really is is useful preparation, because the hardest work in discovery is usually agreeing on what to leave out.
What happens after discovery
You get the documents and the fixed price, and you decide. Some clients start the build the following month. Some phase it to match their budget, which the itemized feature pricing makes straightforward, since every feature already has a number next to it. Some take the plan to their board or their founders first. And occasionally the honest result of discovery is "don't build this yet," which is a good outcome for $1,995 when the alternative was learning the same thing for $60,000 after you attempted an initial build.
If the software you're deciding about already exists, the same engagement works as an audit: we read the code, report what's solid and what isn't, and price the path forward. Our guide to the software investment audit covers when that version is the right call.
Want to know exactly what your product will cost before you commit to building it? Our Discovery package is $1,995, fixed, and ends with a requirements document, line-item pricing, and a timeline you own outright. Book a strategy call and we'll tell you honestly whether discovery is the right next step for what you're planning.
Written by the team at Iron Forge Development, a U.S. based software commercialization firm that has helped launch 100+ products from idea to market.