Phase 1 of a funded software build should contain the one or two core workflows that proves the product works and provides value to the users, everything else can wait. Phase 2 contains what the first real users prove you need next. Everything else waits, and most of it you will eventually realize you never needed. The mechanism that makes this work is a written scope with line-item pricing, produced before the build starts, so that each phase has a defined contents list, a fixed price, and a clear milestone trigger for the next one. Founders funding a build in stages, from their own budget, from Co-Founders, friends and family, or from any other source, use that document to approve work and track progress one tranche at a time without losing sight of the whole product. This guide covers how to draw the lines, how to decide what goes into Phase 2, how to keep scope from drifting between phases, and what to have ready when someone reviews progress.
One scope note of our own. This is a planning guide for sequencing software work against a budget that arrives in stages. It isn't advice on raising money, structuring an investment, or what to promise anyone funding you; your advisors cover that. We cover the software.
Three reasons, and budget is only the first. Money that arrives in stages has to be spent in stages, which forces a sequence whether you plan one or not. Second, learning: the first version in front of real users teaches you things no planning session can, and a phased build lets that learning shape Phase 2 instead of arriving after everything's built. Third, risk: a product that proves its core workflow in Phase 1 has earned the next spend. One that doesn't has saved you the rest of the budget.
The failure mode is phasing by accident. A build starts with a loose scope, money runs short, and "Phase 2" becomes the name for whatever didn't get finished. Planned phasing looks different: the whole product is scoped up front, the lines between phases are drawn on purpose, and each phase is complete on its own terms.
Phase 1 is the smallest product a real user can solve the core problem or benefit from the solution. That sounds like an MVP, and it is; our guide to what an MVP really is covers the scoping in depth. The phasing view adds one constraint: Phase 1 also has to be a stable foundation for Phase 2 to be built upon, so a few things belong in it even though no user will ever see them.
What stays out: every additional user type, reporting, most settings and permissions, most notifications, multiple platforms when you only need one to start, and anything justified by the phrase "users will expect." Our FAQ on what an MVP should include and leave out is the short version of that list.
Phase 2 is defined after Phase 1 ships and has real user feedback. You scoped phase two during discovery, so it has a price and a place in the plan, and you confirm its features and workflows against what the first users did. Typical Phase 2 contents:
Expect the Phase 2 list to change between discovery and the initial phase 1 users feedback. It should. If the first users' behavior didn't change anything in the plan, either the plan was unusually good or nobody looked and actually used the product. Re-pricing the adjusted scope before Phase 2 starts is normal, and a line item feature scope makes it quick.
Phase 3 and beyond is where the long list lives: additional platforms, advanced reporting, role based permissions beyond the basics, white labeling, the enterprise features a single large prospect asked about. Founders worry that deferring these loses customers. In practice, it loses the customers who were never going to buy version one, and it keeps the budget on the ones who are actually willing to pay.
Three things make feature deferral safe. The data model from Phase 1 already accommodates the core deferred features. The scope document already describes and prices them, so they aren't forgotten or re-estimated from scratch. And the decision to build them is made against evidence from a live product and initial user testing, which is a better basis than a planning meeting. Deferred doesn't mean dropped. It means scheduled behind proof.
A phase gate is a decision, so it needs criteria written before the phase starts, when nobody is attached to the answer. Four conditions usually decide it:
A go decision made on those four is fast and defensible. One made on momentum ("the team's available, let's keep going") is how a phased build turns back into an open-ended one.
None of the above works without a document that prices the product feature by feature. That document is what a discovery process produces: a requirements document, API recommendations, development considerations, line-item feature level pricing, and timelines. With it, drawing a phase line is quite simple and make it easy to visualise. You see what every feature costs, you sort features into phases, and the phase price is the sum of those feature. You can move a feature across the line and watch the number change. You can show anyone funding the next phase exactly what they're funding to the dollar.
Without it, phases are negotiated from a lump sum, and lump sums hide where the money goes. We wrote up what a discovery phase costs and what you get for it separately; for a phased build it's the one document the whole structure depends on, and at cost of <$2,000.00 it's a small fraction of the first phase it organizes.
Scope drift is the main threat to a phased build, because every phase boundary is an invitation to "just add" something. The defense is a change-order habit that starts in Phase 1:
A fixed price per phase makes this discipline much easier to keep, because any addition has a visible cost. On hourly billing the same additions disappear into the invoice until the budget runs out in the middle of building with no product to show for it.
Whoever is deciding whether to fund the next phase, founders, a board, a lender, your own finance lead, will want the same things, and all of them come out of the process above if you've kept it:
If outside investors are involved, expect a deeper look at the codebase at some point, and prepare for it the way our guide to technical due diligence describes. A phased build with a clean scope history is a good position to be reviewed from, because every decision has a document behind it.
Phasing changes when you spend, not how much the whole product costs. A focused first version of a custom product typically runs $25k to $75k for one platform, per our custom software cost guide, and Phase 1 of a multiple phase build usually lands in that range because Phase 1 is a focused first version by definition. Later phases are priced from the same itemized feature scope and confirmed at each gate.
Two costs usually catch founders. Ownership starts at the end of Phase 1, not the end of the product: a live product needs maintenance, hosting, and the services it depends on from the day it has users, and the usual rule of thumb is 15-20% of build cost per year. And a pause between phases costs something too, because a team that moves on has to be re-engaged. Plan the pause, keep the documents current, and the restart is a conversation instead of a rediscovery.
Funding a build in stages and want each stage priced before you commit? Our Discovery package produces the line-item scope that makes phase gates work: every feature priced, sequenced into phases, with a fixed price and a timeline for Phase 1. Book a strategy call and we'll help you draw the first line.
Written by Jeremy Millian - COO at Iron Forge Development, a U.S. based software commercialization firm that has helped launch 100+ products from idea to market.
Our base software discovery phase is $1,995, fixed, and takes roughly two to three weeks. What that money buys, the five deliverables you own at the end, why a paid discovery beats a free quote, and the few situations where you can skip it.
A planning guide for funding a software build in stages: what features belong in Phase 1, what Phase 2 is for, what can wait, what decides the go between phases, and how an itemized scope from discovery keeps the whole thing from drifting.
Six healthcare software development partners compared for healthtech startups on HIPAA-first architecture, startup fit, product strategy, pricing transparency, full-stack capability, and post-launch support, with reviews, a side-by-side comparison, and the questions to ask before you sign.
