Phased software delivery: how to break up a big build
Phased software delivery splits one large need into small usable builds. How to cut by process, what to freeze between phases, and what phasing really costs.
Phased software delivery means splitting one large need into a sequence of small builds, each usable on its own. It answers the most common enquiry we get: the need is big, and the budget for all of it at once is not there. Phasing is how you start anyway.
Cut along the process, not the feature list
The instinct is to cut by feature - reports later, roles later. That leaves phase one half-working. Cut by process instead: one complete process end to end, from the moment data enters to the moment someone acts on the result.
A Standish study presented at the XP2002 conference found that 45% of delivered features were never used and only 20% were used often or always. Phasing is what stops you paying for that half up front.
Which process goes first
Not the one that demos best. Start where the manual cost is highest and the data is cleanest - that phase pays for the next one and produces the records later phases need. Small-scope software projects shows what a single phase looks like in practice.
What to freeze and what to leave open
| Freeze between phases | Leave open |
|---|---|
| The data model already live | Screens and layout |
| Who owns each process | Reporting and dashboards |
| Login, roles, backups | Integrations not yet needed |
| The export format | The order of later phases |
A frozen data model is what lets phase three exist without rewriting phase one. Everything else should change as you learn how people actually work.
What phasing costs
Honestly, more. Splitting one build into three tends to cost 10-20% more in total, because each phase carries its own testing, release, and handover. You are buying predictability with that money: a smaller first invoice, a working tool in weeks, and the right to stop.
A discovery sprint is usually phase zero - it fixes the phase boundaries and the price of the first one before you commit, and realistic timelines put weeks against each.
The failure mode nobody mentions
Phase one ships, the business moves on, and phases two and three never get funded. That is survivable if phase one is not a dead end. Demand two things at handover: your data in an open format, and an interface other systems can read. Then a stalled roadmap leaves you with a working tool rather than a stranded one.
Frequently Asked Questions
How big should one phase be? Small enough that someone uses it within weeks - typically a few weeks to two or three months.
Can we change our mind between phases? That is the point. Only what is already live is frozen; everything ahead stays open.
Is this the same as an MVP? No. An MVP is a first version of a product still looking for a market. This is an existing business automating what it already does.
Who decides the order? You do, on cost. We map the options and the dependencies between them.
What if we can only afford one phase? Then build one. Custom software for a small business has the payback test.
Related Articles
- Small-scope custom software projects
- How long does custom software development take?
- Custom software development for a small business
Have a big need and a small budget?
Describe the whole thing and we will draw the phase boundaries - including which single phase is worth doing on its own.
Reach out at [email protected] or via the form on our homepage.