When a developer receives funding from a publisher, the total amount is rarely paid upfront. Instead, most video game publishing agreements contain milestones – specific stages in development that have to be completed by the developer to unlock parts of the promised funding.
Understanding how Milestone Schedules work, and how to negotiate them, is crucial. A well-drafted schedule helps both sides manage expectations, timelines, and cash flow. A poorly drafted one can stop a project in its tracks.
What is the Milestone Schedule?
The Milestone Schedule is a list of deliverables that a developer must achieve during the development of the video game to receive instalments of the publisher’s promised funding. Each milestone usually corresponds to a concrete development phase, such as concept approval, vertical slice, alpha, beta and gold master.
In practice, this means that the developer completes a milestone, delivers a playable build or report to the publisher, and waits for formal approval before the next payment is released.
Why the Milestone Schedule matters
For publishers, a Milestone Schedule is a way to mitigate financial risk. Instead of paying all funding upfront, payments are tied to progress and quality of the video game in development, ensuring that the project is on track before more money is released.
For developers, however, this structure can create financial pressure and become a risk. If a milestone is delayed, rejected, or poorly defined, the next payment can be withheld – sometimes leaving the developer without the funds needed to continue development.
Because of this, Milestone Schedules are among the most negotiated parts of any publishing contract. The right structure keeps both parties aligned; the wrong one can lead to stalled projects, payment disputes, and even contract termination.
Example of a Milestone Schedule
Below is an example of a milestones schedule in a video game publishing agreement:
| Milestone | Description | Due Date |
| Prototype | A build encompassing basic functionality for the major planned features as a proof of concept and very early look at the feasibility of the tech/features/visuals being built. | 7/30/2022 |
| First Playable / Gameplay Validation | Builds can be created which are able to prove out a first look at the basic core gameplay loop. | 8/30/2022 |
| Interim Milestone | Iterative build update, with feedback from previous milestone addressed. | 10/30/2022 |
| Vertical Slice | Features and content in one level of the game are generally functioning together with representative art. | 1/30/2023 |
| Vertical Chunk / Final Spec (mid-project review) | Features are largely functional and no longer require debug to use, save for a few exceptions. All major features are proven out and can be reviewed in concert with one another | 4/30/2023 |
| Feature Complete/Feature Lock (Alpha) | All features are proven and fully functional (bugs notwithstanding). The build is ready for full feature testing through QA. | 7/30/2023 |
| Content Lock (Beta) | The game’s content is now in the build and the game can be played from beginning to end without major blockers or crashes. | 10/30/2023 |
| Beta | The Game has all content integrated at shippable quality and all features are fully playable. | 1/30/2024 |
| Release Candidate 1 | The game has reached a finalized state where no further submission blockers remain and a release candidate has been designated by QA. | 3/30/2024 |
| First Party Certification / Approval & RTM | The game has passed first party submission and no further blockers remain for public release. | 6/30/2024 |
| Game Release | Day0/Day1 patches are certified and the game is publicly released. | 9/30/2024 |
| Final Build Archive / Post-launch Support | The released build and any applicable Day 0/Day 1 patches are archived and sent through the copyright process. | 12/30/2024 |
While this looks straightforward, the details of how milestones are assessed and approved make all the difference.
How to review and negotiate the Milestone Schedule
The key is to ensure milestones are structured in a way that protects the publisher’s interests while giving the developer enough clarity and stability to keep development moving forward.
Define clear and objective criteria for milestone acceptance
Many publishing agreements lack clear criteria for assessing whether a milestone is “accepted.” This can leave developers vulnerable to subjective decisions—publishers rejecting builds because of qualiy concerns that were never specified.
To avoid this, milestones should include measurable, objective criteria: feature completion, stability, performance, or specific gameplay goals. These give both parties a shared standard for evaluation.
At the same time, it remains important for a publisher to be able to raise concerns. The goal is balance: milestones should be detailed enough to guide development, but flexible enough to allow the publisher to provide constructive feedback without blocking payment arbitrarily.
Provide remedies for rejected milestones
In most agreements, if a milestone is rejected, the developer may deliver an updated milestone candidate that addressed the publisher’s feedback. This has to be done within the term that has been included in the contract or within a term that is mutually agreed upon between the developer and publisher on a case-by-case basis.
After resubmission, the publisher re-assesses the build. This process repeats until the milestone is accepted by the publisher. In some agreements, the publisher has the right to terminate the contract in case the developer has failed to deliver an acceptable milestone candidate a certain number of times.
While this is standard, developers should make sure the contract specifices how many retries are allowed and what counts as a “rejection.” A missing texture should not be treated the same as a missed gameplay mechanic. The clearer these procedures are, the smoother collaboration will be.
Stuck on legal fine print?
Let us decode it for you.
Ensure protections if the publisher does not respond on time
In most contracts, the publisher must respond to a milestone submission within a certain number of business days. However, not all contracts include consequences if the publisher fails to do so.
We have even seen situations where silence from the publisher automatically counted as rejection—a disastrous outcome for developers relying on that payment to continue production.
From the publisher’s side, sufficient time is needed to to assess the milestone properly. But from the developer’s side, non-response means no payment and no progress. This could lead to a scenario where the developer does not have sufficient funding to continue developing the game, which leads to a downward spiral in the collaboration, because the next milestones cannot be delivered on time.
The best solution is a balanced clause stating if the publisher fails to respond within the agreed period, the milestone is deemed accepted for the payment of the funding only. The publisher still has the opportunity to provide feedback to the milestone candidate later, but the developer receives the funds needed to keep development moving.
This creates a fair balance between a developer’s financial stability and and a publisher’s quality control.
Before you sign: summary and next steps
Milestone schedules are essential for managing funding, but they can also be a major point of friction if not drafted carefully. For developers, the key is to insist on clear acceptance criteria, remedies for rejections, and safeguards against publisher delays.
When properly balanced, milestones create transparancy, predictability, and trust. When poorly drafted, they can halt development entirely. Because these clauses directly determine when and how you get paid, it’s crucial to have an experienced legal professional review them before signing. Even minor wording changes can make a major difference in your financial security.
Next up, we’ll look at royalties, net revenue and recoupment—the financial backbone of every publishing deal, and the clauses that decide how much you ultimately earn from your game.