How to Set a Ship Date and Actually Hit It

Most games miss their ship date because the date was wrong, not because the team was slow. A realistic ship date is set from the bottom up, includes buffers for things that always happen, and has a scope plan that accounts for running out of time. Setting it well is a skill, and it is learnable.

Why dates slip

Dates slip for three reasons, and all three are preventable.

Optimistic estimation. Every task is estimated at its best-case duration. Ten tasks estimated optimistically produce a plan that is several weeks shorter than reality, because not every task will go smoothly and some will go badly.

No buffer for the predictable. Sick days, bugs in tools, review rejections, feedback rounds, and platform issues are not surprises. They happen on every project. A plan that does not include time for them is a plan that assumes nothing will go wrong.

Late scope cuts. Features that should have been cut in month two are still in the plan in month four, and removing them now costs rework. The later scope is cut, the less time it saves.

All three share a root cause: the date was set before the work was understood, and the plan was not updated as understanding grew.

A ship date that does not change as you learn more about the project is not disciplined. It is uninformed.

Estimating from the bottom up

Top-down estimation picks a date and works backward. Bottom-up estimation builds the date from the tasks.

Bottom-up is slower and more accurate. Here is how to do it.

1. List every deliverable. Not tasks, deliverables. A deliverable is something that can be tested: a playable level, a working menu, a functional save system.
2. Estimate each deliverable in days. Not hours, because hours hide the overhead of context switching, communication, and integration.
3. Add dependencies. Some deliverables cannot start until others finish. Map these, and the longest chain of dependencies sets your minimum timeline.
4. Multiply by 1.3 to 1.5. This accounts for the optimism that bottom-up estimation does not remove. A 1.3 multiplier is appropriate for experienced teams. A 1.5 multiplier is appropriate for teams working with a new engine or unfamiliar genre.

The result is your raw timeline. It is longer than you want, and it is closer to reality than the number you would have picked.

Building buffers that actually protect the date

A buffer is not slack. It is a plan for the things that always happen.

Three types of buffer.

Integration buffer. Time between feature completion and the ship date for everything to be tested together. Individual features that work in isolation frequently break in combination. Two weeks is a reasonable starting point.

Feedback buffer. Time to act on feedback from testing, reviews, or soft launch. If you plan to get feedback but do not plan to act on it, the feedback is decorative.

Platform buffer. Time for store review, approval, and any required fixes. Review times vary, and a rejection costs a resubmission cycle. Build in at least one rejection and resubmission.

Place these buffers at the end of the schedule, not distributed through it. A buffer scattered through the plan gets absorbed by normal work. A buffer at the end is visible and defended.

The milestone structure that keeps you honest

Milestones create accountability checkpoints. Without them, the gap between plan and reality grows silently until the ship date arrives.

A good milestone structure has four properties.

1. Milestones are playable. Each one produces a build that somebody can play and evaluate.
2. Milestones are frequent. Every two to three weeks. Longer gaps hide problems.
3. Milestones have clear criteria. Not "level design progress" but "levels one through five playable with final art."
4. Milestones include a plan review. At each checkpoint, update the remaining timeline based on what you now know.

That fourth point is the critical one. A plan that is never updated is a guess that hardens into a commitment. A plan that updates at every milestone incorporates reality.

When a milestone reveals that the timeline is wrong, move the ship date or cut scope. Do not pretend the plan is still accurate.

Cutting scope before the deadline forces you to

Scope cuts made early are decisions. Scope cuts made at the last minute are emergencies.

Decide what you would cut before you need to cut it. This is a list made in month one, not month four.

Rank every feature into three tiers.

• Must ship. The game does not work without it. Core loop, basic progression, essential UI.
• Should ship. Improves the game significantly. Leaderboards, achievements, secondary content.
• Nice to have. Adds polish. Extra visual themes, social features, additional levels beyond the core set.

If you run out of time, cut from the bottom up. The "nice to have" tier is the first to go, and it should go the moment the timeline is at risk, not the moment the deadline arrives.

Cutting early has a compounding benefit. It frees time for the team to focus on what remains, which improves the quality of everything that ships.

Avoiding last-week panic

Last-week panic happens when the team discovers problems that should have been found weeks earlier.

Three practices prevent it.

Play the full game every week from milestone three onward. Not a section, the whole thing. You will find pacing problems, broken transitions, and missing content that individual feature tests miss.

Lock new features two weeks before ship. The final two weeks are for bug fixes, polish, and platform compliance only. No new features, no matter how small.

Run the submission checklist a week early. Store screenshots, metadata, ratings, and privacy compliance all take time. Discovering that you need a privacy policy the day before submission costs a day you do not have.

If you reach the last week and everything is calm, the plan worked. If the last week is chaos, the plan failed, regardless of whether you hit the date.

What we would do

Set the date using bottom-up estimation with a 1.4 multiplier. Add a three-week buffer at the end for integration, feedback, and platform review.

Then build the scope tiers in the first week. The "nice to have" tier is pre-approved for cutting, so nobody treats it as a difficult conversation when the time comes.

Review the plan at every milestone and adjust the date or scope honestly. A date that moves once based on real information is far better than a date that stays fixed while the plan quietly falls apart around it.

The short version

• Most dates slip because the estimate was optimistic, not because the team was slow.
• Estimate from deliverables up, not from a target date down, and multiply by 1.3 to 1.5.
• Add buffers for integration, feedback, and platform review at the end of the schedule.
• Set milestones every two to three weeks, each producing a playable build and a plan review.
• Rank features into must, should, and nice-to-have tiers in month one, not month four.
• Lock features two weeks before ship and run the submission checklist a week early.

Build your scope tiers this week. If you want help setting a ship date that holds, get in touch.