Write the phases of a software project down and they line up neatly: business case, requirements, plan, spec, build. The reason the order exists is not to collect those documents, though. It is to put every chance of being wrong in the place where being wrong is still cheap.
So the most useful column in a phase table is not what each phase produces. It is whether you are allowed to stop there. A phase you cannot stop at is not a phase, it is a date on a calendar. What follows assumes a contract and a client; building something alone with an AI runs in a different order, and I wrote that one up in building a web game with AI.
Why does the order exist at all?
Because the cost of undoing a decision climbs fast. Changing a sentence in a proposal costs nothing. Changing the data model of a system that already holds a year of records costs a different order of magnitude.
The GOV.UK Service Manual says this out loud, which is rare for a government document. In alpha you are told to identify “your riskiest assumptions” and test them, and to “expect to throw away any code” written along the way. The sentence that matters more comes next: if you finish alpha and you are not confident, “you could stop altogether or decide to repeat discovery or alpha.” Permission to stop, in writing. That is what turns a phase into a gate.
What actually comes after a POC?
Not development. A decision comes first, then locked requirements, and only then the build. People collapse those three into one step and that is where projects go sideways.
The same manual splits the work into discovery, alpha, beta and live, with an assessment on each boundary. In discovery you “should not start building your service” at all. Beta starts private: “you’ll start in private beta by inviting a limited number of people to use your service.” That private beta is the pilot, and it sits after the build rather than instead of it. A POC answers whether the thing can work; a pilot answers whether it holds up with real people. They are not interchangeable.
Why does the licence check come first?
Because if it fails, nothing below it matters. Copyright and licensing, personal data, and a rough size for what you are producing. None of those need the business case to be finished, so they run from day one in parallel.
This is also where you learn that the licence in the documentation and the licence in the file can differ. While testing tools that generate fonts I downloaded an OTF from Metaflop and read the strings inside it. The site said OFL 1.1. The file said GPL v3 and OFL 1.1 together, with a reserved font name clause attached (checked July 2026). That was one font. On a project that ingests thousands of other people’s files, this is not a check you schedule for later.
What usually gets left out of the POC plan?
Most plans list what to test, the success criteria, the timebox and the budget. The missing box is what you do when the criteria are not met.
Write only the target and the target moves once the results land. You aimed for 90%, you got 74%, and someone says “that’s not bad for a first pass.” They are not even wrong, which is exactly the problem. Decide in advance what a miss means: narrow the scope, change the angle, or stop. Name the person who makes that call. Written before the numbers exist, it costs nothing; written after, it is a negotiation.
Why measure it yourself?
Because the number in the documentation and the number on your disk keep disagreeing. While comparing five GIF sites I downloaded the same clip from Gifer in both formats. The GIF was 18,368,428 bytes. The MP4 that the page itself was playing was 244,984 bytes (downloaded and checked in July 2026). Seventy-five times. No product page mentioned it, and it only showed up because I clicked the button.
The numbers from this phase become the basis for your schedule and your price. If the write-up ends at “yes, it worked,” you ran a demo, not a POC.
When do you lock the schedule and budget?
After the POC has produced numbers. Anything committed before that is a hope with a date on it.
Locking scope creates the next obligation: a named route for changing it. Not a rule that forbids changes, a route that prices them. Every change request should arrive at the same table where the original scope was agreed, and leave with a cost and a new date attached. Teams that skip this do not get fewer changes, they get changes that nobody paid for.
What happens after launch?
Handover. If your phase list ends at build, test and internal pilot, everything after that belongs to nobody.
Three things need an owner: a runbook saying who does what when it breaks, monitoring that somebody actually reads, and a re-run of the quality bar you wrote into the spec. That last one quietly disappears. The Scrum Guide puts it plainly for a single increment: “If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review.” A bar that only applies on release day is not a bar. Inputs drift, and quality drops without anyone filing a ticket. Even the live phase keeps an exit in it: “you need to retire your service if you find out users do not need it anymore.”
Ours is a blog, not an enterprise system, and the same thing happened anyway. When I finally measured the site’s speed the home page was shipping 2.8MB, nearly all of it unoptimised PNG. Nobody noticed while building it. It surfaced months later, from a measurement.
The order at a glance
| Phase | What it produces | Question before moving on |
|---|---|---|
| 1. Viability check | Licensing and legal review, rough size | If this fails, does the rest matter? |
| 2. Business case | What, and why | What breaks if we do nothing? |
| 3. Draft requirements | List of unknowns | What is the riskiest assumption? |
| 4. POC plan | Tests, criteria, timebox, budget, miss-action | Are the criteria numbers? |
| 5. POC | Measured results | Did we measure what we set out to? |
| 6. Decision | Go, narrow, or stop | Who signs it? |
| 7. Locked requirements, architecture | Data model, non-functionals | What can we not change later? |
| 8. Delivery plan | Schedule and budget | Is it based on measurements? |
| 9. Spec | Functional spec, quality bar | Is there a pass mark? |
| 10. Build, test, pilot | Something that runs | Have real users touched it? |
| 11. Launch and handover | Runbook, monitoring, regression checks | Who looks at it tomorrow? |
Which two boxes I fill first
Row 4’s miss-action and row 11. The rest of the table tends to fill itself once people are assigned to it. Those two stay blank unless somebody asks, and they are reliably blank on the projects that go badly.
To be straight about it: this order comes from reading public standards and manuals, not from running large integration projects. Every piece of first-hand evidence above is blog-sized. If the vocabulary is the part tripping you up rather than the sequence, start with the dev meeting terms instead.