Milestones for a Buyer Who Cannot Read the Code: Make Each One Independently Checkable

Mostafa Dhouib·7 min read

Milestones for a Buyer Who Cannot Read the Code: Make Each One Independently Checkable

The short answer. When the person paying cannot evaluate the work by looking at it, milestones organised around internal stages give them nothing. Schema complete, service layer done and integration finished are all real progress and none is checkable by someone outside the build, so the client is trusting rather than knowing, and trust degrades on a schedule nobody controls. Three rules fix most of it. Every milestone ends in something the client can verify without you. The milestone that could end the project comes first, before anything is built on its assumption. And the milestone you control least gets the smallest envelope, so the risk you cannot manage is bounded by the amount at stake.

A solo founder is buying a product they cannot build and cannot assess. They have one shot at the budget and no way to tell a project going well from one going badly until it is late.

The default plan makes this worse. It is drawn from the build's internal structure, because that is the structure the builder sees, and those boundaries are invisible from outside.

Checkable by the client, not by you

A milestone is complete when the client can confirm it themselves. That is a higher bar than working, and it changes how stages are drawn.

"Data layer complete" is not checkable. "You can search this one route and see real prices" is.

"Integration finished" is not checkable. "You can add a new city yourself by adding a row, and here it is working" is.

"Testing complete" is not checkable. "Here are twenty real cases and what the system returned for each" is.

The reframing costs nothing in engineering and changes the relationship entirely. The client stops being asked to believe a status and starts being able to confirm one. It also exposes a failure mode early: if a stage genuinely cannot produce anything a client can check, that is usually a sign it is too long rather than too technical.

Risk first, not value first

Standard advice is to sequence by value, delivering the most useful thing first. For a product with an external dependency, sequence by risk instead.

If the project can be ended by one fact you do not yet know, finding out is the first milestone, before anything is built on the assumption. Whether the data can be obtained on terms that permit your use. Whether the device can be read at all. Whether the platform permits this category.

The reasoning is simple. Every day spent building on an unverified assumption increases what gets discarded if it turns out false, and the client's exposure grows with it.

This is a harder sell than starting with something visible, because milestone one produces no product. The argument that works is about their money rather than your process: this is the thing that could make everything else worthless, it costs a small fraction of the budget, and it is better to know in week one than in month three.

The smallest envelope on the thing you control least

Every project has a stage whose outcome depends on something outside the build. Acceptance on hardware you never physically touch. A review queue with its own timetable. A third party who has to respond.

Put that stage in the smallest milestone.

The logic is about exposure rather than effort. If the external dependency goes badly, the amount of value sitting unresolved is bounded by the size of that stage. Bundled into a large final milestone, a delay at a step you cannot influence holds the whole remaining payment and the whole remaining relationship hostage.

On one firmware engagement the stages were weighted so that the largest work sat in the middle and the final stage, acceptance on a remote bench the engineer would never touch, was the smallest. The external risk was real, unavoidable, and quarantined.

Say what each milestone does not include

Scope disputes in this kind of work almost never come from disagreement about what was delivered. They come from a client who assumed something was included because nobody said it was not.

So each milestone carries two lists. What it delivers, and what it explicitly does not, including the things a reasonable person might assume came with it.

This feels defensive and it does the opposite. A client reading what is excluded understands the shape of the work far better than one reading only what is included, and the exclusions are where the real conversation happens. It also surfaces disagreement at the point where it costs a conversation rather than at the point where it costs a milestone.

Keep stages short enough to stop

A long stage is a long period in which the client cannot act on new information. If something changes in their business, or they lose confidence, or priorities move, a six-week milestone means six weeks before a natural stopping point.

Short stages give both sides an exit that is not a dispute. For the client, the ability to stop with everything delivered so far working. For the builder, the ability to raise a problem at a boundary rather than mid-stage.

Roughly a week to two weeks each tends to work. Short enough that the client is never far from a decision point, long enough to produce something checkable.

One product ran this way to delivery in seven weeks, covering 88 locations with no rewrites needed to expand. The structure was not incidental to that. Short checkable stages with the catalogue modelled as data from the start is what made expansion a row rather than a release.

The honest limit

This structure reduces the client's risk and it does not reduce the work. Checkable stage boundaries sometimes mean building a small amount of scaffolding so a stage can be demonstrated, which is real cost paid for transparency.

It also does not protect against a client who changes what they want. Clear exclusions make that visible as a change rather than a dispute, which is better, and it is still a change that costs money. No milestone structure substitutes for a client who knows what they are buying, and the best versions of this spend real effort early making sure they do.

FAQ

How should I structure milestones for a non-technical client? So that each one ends in something they can verify without you. Schema complete and integration finished are invisible from outside. Searching one real route and seeing real prices is not. The reframing costs nothing in engineering and replaces trusting a status with confirming one.

Should I sequence milestones by value or by risk? By risk, when the project has an external dependency that could end it. Finding out whether the data can be obtained, the device can be read, or the platform permits the category comes before anything is built on that assumption, because every day of building increases what gets discarded if the answer is no.

Where should the milestone I control least go in the plan? In the smallest envelope. Acceptance on remote hardware, a review queue or a third party's response are all outcomes you cannot manage, so the amount of value held hostage by a delay there should be bounded. Bundled into a large final milestone, it holds the whole remaining payment.

Why state what a milestone does not include? Because scope disputes come from assumed inclusions rather than disagreement about what was built. Listing the exclusions, including the ones a reasonable person might assume, surfaces disagreement when it costs a conversation instead of when it costs a milestone.

How long should a milestone be? Roughly one to two weeks. Short enough that the client is never far from a decision point and can stop with everything delivered so far working, long enough to produce something they can actually check. A six-week stage is six weeks in which neither side can act on new information.

Does this structure protect against scope change? No. It makes change visible as change rather than as a dispute, which is better and still costs money. No milestone structure substitutes for a client who understands what they are buying, which is why the best versions spend real effort early making sure they do.