Your First Milestone Is Wrong: Structuring Payments That Protect Both Sides

A good milestone is tied to something you can open and judge, not to a date or a percentage of work. Payments released against testable artefacts keep both sides honest: the studio is paid for demonstrable progress, and you never carry more risk than one milestone at a time.

Why this matters

Payment structure is the part of a contract founders negotiate least and regret most. It quietly decides how much leverage you keep, how early you find out about problems, and what happens if you need to stop.

It also shapes behaviour. A studio paid on dates optimises for dates. A studio paid on demonstrable artefacts optimises for demonstrable artefacts.

Getting this right costs one conversation before signing.

Why 50 percent upfront and 50 percent on delivery fails everyone

The structure sounds balanced and is not.

For you, it means half the budget is committed before you have seen anything, and the only checkpoint arrives at the end when it is too late to change course.

For the studio, it means carrying months of cost against a single final payment, and a dispute at the end puts the entire second half at risk.

The shared problem is that neither side learns anything in the middle.

Any structure with one checkpoint gives you one chance to discover a problem, and it arrives after the money is spent.

What a good milestone looks like

Four properties, and all four matter.

1. It produces something you can open. A build, a document, a playable link. Not "engine work complete".
2. It has a written acceptance test. What has to be true for this to pass, agreed in advance.
3. It is short. Two to four weeks. Longer than that and you are back to one checkpoint.
4. It is roughly evenly sized. Milestones that grow toward the end concentrate risk exactly where you want least of it.

The acceptance test is the part people skip and the part that prevents disputes. "The prototype is done" invites argument. "A player can complete three levels on an Android device without a crash" does not.

Tying payment to a testable artefact

Write each milestone as a sentence in this shape: on delivery of X, verified by Y, payment Z is due within N days.

The right column can be checked by someone who is not an engineer, which is the whole point.

Add a review window as well. A few working days for you to test and respond, after which the milestone is deemed accepted. Without it, milestones stall on your side and studios stop being able to plan.

Change requests and how to price them

Change is normal. Pretending otherwise is what makes it expensive.

Agree the mechanism before you need it.

• Define what counts as a change. Anything outside the written scope, including additions to the "not building" list.
• Price changes as their own small milestone, with their own artefact and their own acceptance test.
• Agree a response time for quoting a change, so the project does not stall waiting on an estimate.
• Keep a running log of accepted changes and their cost, visible to both sides.

That log is worth more than it sounds. Most budget overruns are a series of small reasonable changes nobody totalled up, which is covered in Changing Scope Mid-Project.

Kill clauses and what happens to the code

The uncomfortable clause is the one you most want in place.

Agree in writing what happens if either side stops the project.

• Notice period. Usually tied to the current milestone rather than a fixed number of weeks.
• Payment on termination. Work completed to date, assessed against the current milestone's acceptance test.
• Handover obligations. Source, assets, documentation, and credentials, delivered in a stated form within a stated time.
• Ownership at each stage. Whether rights transfer on payment of each milestone or only at the end.

That last point matters more than the rest. If ownership transfers only at final payment, stopping early can leave you with nothing usable. Milestone-by-milestone transfer is more common and much safer, and the wider question is covered in Who Owns Your Game IP.

A sample five-milestone structure

For a typical first mobile build, this shape works well.

1. Discovery and plan. A written technical plan, a risk list, and the agreed scope document. Small payment, real deliverable.
2. Playable core loop. A device build with the loop working, grey box art, no progression.
3. Content and progression. The loop plus levels or progression, first art pass integrated.
4. Feature complete. Everything in scope present, analytics firing, running on the device floor.
5. Release candidate. Store-ready build, assets delivered, handover documentation complete.

Weight them close to evenly, with the first slightly smaller and the last carrying enough value that finishing matters.

An initial deposit is reasonable and normal. Keep it modest, and treat it as securing the schedule rather than as a first milestone.

What we would do

Ask for the acceptance tests in writing before signing. A studio that can write them quickly has done this before, which is useful information beyond the contract.

Keep milestones under a month, even if it means more of them. The administrative cost is small and the risk reduction is large.

Test every milestone properly and on time. A founder who lets three milestones pass unreviewed has recreated the structure they were trying to avoid, and the problems surface at the end anyway.

Finally, agree the termination terms while everyone is optimistic. It is a five-minute conversation at the start and a painful one later.

The short version

• Tie every payment to something you can open and test, never to a date.
• Write the acceptance test for each milestone before work begins.
• Keep milestones to two to four weeks and roughly even in size.
• Give yourself a review window, and use it.
• Price changes as small milestones and keep a running total.
• Agree termination, handover, and stage-by-stage ownership up front.

Rewrite your milestone list as acceptance tests this week. If you want a second opinion on a proposed schedule, send it to us.

Related reading: Milestones and Payments With a Game Studio, Work For Hire, License, or Rev Share, and Red Flags in a Game Development Proposal.