Milestone-based delivery, and why we ship in phases

The problem with a single delivery date

Three months, one delivery. Kick-off in January, launch in April. Everyone crosses fingers that what shows up matches what everyone thought was being built.

That model works when requirements are crystal clear, the team is stable, and nobody changes their mind for twelve weeks. In the real world, that combination is rare.

What we see instead: kickoff is optimistic, week six reveals the login flow doesn't match the actual user journey, week eight is a rushed replan, week eleven is a frantic dash to fake feature completion for the demo. Six weeks after launch, half of what shipped has been rewritten.

We stopped working that way. Every project ships in two-week milestones. Every milestone ships something usable.

What a milestone looks like

A milestone is two weeks of scope. At the end, three things must be true:

Something demoable exists — a feature, a page, a flow.
It's deployed to a real environment (staging or production).
The client has seen it and signed off.

That's it. Not a status update. Not a slide deck. A working piece of software, deployed, reviewed, accepted.

For a marketing site: milestone one is often the home page. Milestone two, three case-study templates. Milestone three, the blog. And so on.

For a mobile app: milestone one is auth and the first screen. Milestone two, the core feature. Milestone three, notifications and deep links. And so on.

The milestones nest — the app isn't shippable to the App Store until they're all done — but each one on its own is real, complete work.

Why we chose this

Three reasons. All of them empirical, learned from projects that went sideways before we started working this way.

Compounding risk

In a single-delivery model, risk accumulates. Every week that passes without integrating what's been built is a week where drift becomes possible. The design changes slightly. The API contract shifts. The scope grows. All of these are small on any single day and lethal after three months.

Milestones force integration every two weeks. You cannot drift far in two weeks. The compounding stops.

Client sanity

A client seeing nothing for three months is a client whose confidence is being eroded by silence. It doesn't matter how good the eventual delivery is — the six weeks of not knowing what's going on is a bad experience, and it changes how the relationship works.

A client seeing something new every two weeks is a client who trusts you're building. Not because they need to, but because they can.

Course correction

Every milestone is a decision point. Is what we're building still the right thing? Has anything changed on the client side that should reshape the next milestone? Is any part of the plan turning out to be harder than expected, and should we reshuffle?

Making these decisions every two weeks means the project you finish is almost never the project you started — and that's a feature, not a bug. Requirements evolve. So does the plan.

What milestones aren't

They aren't Scrum sprints. We don't do the ceremony. No standups performed for the client. No burn-down charts. Milestones are just a scoping and demo cadence — everything else about how we work stays the same.

They aren't fixed-scope, variable-quality. If a milestone is behind on Wednesday of week two, we don't cut corners on Friday to hit the demo. We move something out of scope, ship what's ready, and pick up the missing piece in the next milestone.

They aren't waterfall. A milestone is not "phase 3 of the plan." It's the next two weeks. What comes after is agreed based on what we learned in the last two.

How we scope them

At kickoff, we sketch a rough sequence of milestones for the whole project. Not a Gantt chart — a bullet list. Ten to fifteen milestones covering the shape of the work.

Milestone one is scoped in detail. Milestone two is sketched in detail. Milestones three through fifteen are one-liners.

At the end of milestone one, we scope milestone three in detail, and add a one-liner for milestone sixteen if needed. We're always working one milestone ahead in detail, and looking three or four ahead in outline.

This means the plan is always current, always shipping, and always adjustable. If a milestone reveals something unexpected, the next milestone reflects it. No replanning ceremony required.

The demo

Every milestone ends in a demo. Not a slide deck. Not a status update. A live walkthrough of what was built, by the person who built it, with the client on the call.

The client asks questions. Sometimes big ones. Sometimes those questions change what milestone two looks like. That's fine — that's the point.

The demo also creates a record. What was shipped, when, and what was agreed as the next step. If a dispute ever comes up later — did we build what we said we would? — the record is unambiguous.

Where this fails

Milestone-based delivery works when the project is decomposable. Most software projects are — a marketing site has pages, an app has features, a dashboard has views. You can slice them.

It struggles when the value only exists at the end. A migration from one system to another can't ship in halves. A regulatory certification either passes or fails. For those, we still use milestones internally — but the client-facing sign-off is at the end. That's an honest tradeoff.

It also fails when the client can't spend an hour every two weeks to demo and sign off. That happens rarely, and when it does, we tell the client the pace has to slow. Two-week milestones need two-week attention.

The bet

The bet behind milestone-based delivery is that shipping small, shipping often, and integrating early beats the alternative. Twenty years of software engineering research says the same thing. We've just codified it into how we scope work.

If you've ever inherited a big-bang project that didn't quite land, you know the alternative isn't fun. Milestones are the fix.