Ryan Cole
Most articles about alpha and beta milestones describe them like they’re obvious. Feature-complete at alpha, bug-fix mode at beta, ship it. Done. That framing is so stripped down it’s basically useless, and I’ve watched more than a few teams sail into alpha thinking they understood it, then spend three months drowning in scope decisions that should have been made six months earlier.
Let’s fix that.
What Alpha Actually Means (And What People Get Wrong)
Alpha is not “most of the features are in.” That’s the version that gets written on milestone checklists and then silently negotiated down until it means almost nothing.
Real alpha is a content-complete, playable game where every major system exists and is functional enough to evaluate. Not polished. Not bug-free. But complete in structure. Every level exists in some form. Every mechanic is implemented. Every major content type has at least a representative example you can actually play through. The experience might be rough, pacing might be off, and your HUD art probably still looks like a developer temp-built it in 2019, but you can play from beginning to end. That’s the test.
Here’s where I got it wrong for a long time: I used to treat alpha as a quality gate. Is this feature good? Does this level feel fun? Those are the wrong questions. Alpha is an existence gate. Does this feature exist in a form we can evaluate? Can we see the whole shape of the game? If yes, you’re at alpha. If you’re still asking “do we have a crafting system or not,” you’re not.
The distinction matters because it changes what you do with alpha. If you think of it as a quality gate, you’ll keep polishing individual systems while other systems go unbuilt. The result: one excellent combat system, zero economy, and a production timeline that’s four months off.
At one mid-size studio I worked with, their alpha build technically had every feature checked off on a spreadsheet. But half those features were stub implementations: placeholder logic, no content, no tuning. When the publisher reviewed the build, they rightly said this isn’t alpha. The team had to go back and spend two more months putting actual flesh on the bones. That milestone slip cost them their holiday window.
The Gap Between Alpha and Beta Is Where Games Die
Beta means something more specific than “we’re fixing bugs now.”
Beta is when the game is content-locked. No new features. No new levels. No scope additions. What you have is what you’re shipping. Beta is bug-fixing, optimization, platform compliance (cert prep if you’re on console), and the final pass of quality work across every system that already exists. The design door is closed.
That content-lock is the thing people treat as negotiable, and it’s not. The moment you let a “small” new feature into beta, you restart a cascade: new bugs, new QA cycles, new risk. I’ve seen teams push a “quick” dialogue rewrite into beta week two and spend the next three weeks chasing memory issues that traced back to that change. The instinct to keep improving is good instinct applied at the wrong time.
The gap between alpha and beta is where most production failures happen. Teams hit alpha, exhale, and then spend the next two months doing two contradictory things: trying to polish content AND trying to add the features that weren’t actually in at alpha. That’s not a beta phase. That’s a second alpha. And it almost always means you’re burning your beta buffer on work that should’ve happened earlier.
A useful way to think about it: alpha is the last chance to change what is in the game. Beta is the last chance to make what’s there shippable. Conflate them and you get neither.
How Long Should Each Phase Actually Be?
What I *actually* do as a Product Manager (in 2023) · Chloe Shih on YouTube
| Project Type | Alpha→Beta Duration | Beta→Ship Duration | Total Late-Stage | Notes |
|---|---|---|---|---|
| Mid-scope indie (12-24mo total) | 6-10 weeks | 6-10 weeks | 12-20 weeks | Baseline for smaller teams |
| Console title with cert | 12+ weeks | 12+ weeks | 24+ weeks | Sony/Microsoft cert adds 4-6 weeks minimum |
| Narrative puzzle (3-person studio example) | 6 weeks | 8 weeks | 14 weeks | Real alpha at week 44 of 52-week plan |
This varies by project scope, team size, and platform requirements. I don’t have a clean universal number to give you. But I can give you a rough shape that holds up across most projects I’ve worked on.
For a mid-scope indie title (12-24 months total dev): alpha to beta is often 6-10 weeks. Beta to ship is 6-10 weeks. So about 12-20 weeks total in the late-stage phases.
For a larger console title with cert requirements: plan for beta to be at minimum 12 weeks. Sony and Microsoft certification processes alone can absorb 4-6 weeks, and that’s assuming your first submission passes. It often doesn’t.
Where teams consistently underestimate: QA coverage at beta. The number of bugs that surface when you finally have a content-complete, integrated build is always higher than your estimate. Always. Build in buffer. A team that estimates 8 weeks of beta and ships in 8 weeks is a team that got lucky or had already done extraordinary QA discipline in alpha.
Worked example: A three-person studio building a narrative puzzle game set an alpha milestone for week 38 of their 52-week plan. They hit alpha with 4 of 9 chapters genuinely complete, 5 chapters in stub form. Rather than declare false alpha, they added 6 weeks, hit real alpha at week 44, and compressed beta to 8 weeks. They shipped with 23% fewer post-launch critical bugs than their previous title, which had a “clean” alpha that was actually a stub. Longer development, cleaner ship.
Using These Milestones in Contracts and Publisher Agreements
If you’re working with a publisher or have a funded development agreement, alpha and beta aren’t just internal production milestones. They trigger payments, reviews, and sometimes contractual approval rights. This is where sloppy definitions get expensive.
Read your contract’s definition of alpha carefully. Some publisher contracts define alpha as “publisher review build” with approval required before you can proceed. Others define it as “feature-complete at the developer’s discretion.” The difference is enormous. One gives your publisher a blocking vote on your timeline. The other doesn’t.
As of July 2026, most indie-friendly publishers use tiered milestone definitions with explicit criteria attached, specifically because the old “feature-complete” language caused so many disputes. If you’re signing a deal today, push for a criteria-based definition in writing: which systems must exist, what content percentage must be playable, what platforms must the build run on. Vague language is a negotiation to have before signing, not a fight to have when the milestone hits.
Worked example: A studio with a seven-figure console publishing deal had “alpha” defined only as “substantially feature-complete” in their agreement. When they submitted their alpha build, the publisher rejected it as insufficient. The dispute took 11 weeks to resolve through arbitration, delayed the game by a quarter, and cost the studio approximately $280,000 in bridging costs while funding was held. A one-paragraph annex with explicit criteria would have prevented it.
Tools That Actually Help You Track This
For milestone tracking at the alpha/beta level, I’ve found Linear is the most efficient tool for smaller teams (under 20 people). It’s fast, the milestone tagging is clean, and you can filter your entire backlog by milestone state without five clicks. If you’re a larger team or have a publisher requiring specific reporting formats, Jira is still the standard and the integrations matter at scale.
For QA tracking specific to late-stage milestones, Testrail integrates well with both and gives you the test coverage visibility you actually need in beta: what’s been tested, what’s passed, what’s regressed.
On the PM knowledge side, “Blood, Sweat, and Pixels” by Jason Schreier (2017) is the book I recommend to every producer who hasn’t read it. Not a how-to manual, but the most accurate account of what late-stage production actually feels like and what goes wrong. Worth it just to name the patterns before you’re inside one.
Clinton Keith’s “Agile Game Development” is the practical counterpart. His chapter on milestone planning maps well to exactly what I’ve described here, and his treatment of what “done” means in game dev is the clearest I’ve read.
Sources
- Clinton Keith, Agile Game Development with Scrum (2010, updated 2020): Industry-standard reference on applying agile practices to game production milestones.
- Jason Schreier, Blood, Sweat, and Pixels (2017): Detailed case studies of shipped game productions, including late-stage milestone failures and recoveries.
- IGDA (International Game Developers Association) Game Production Standards Whitepaper: Covers milestone definitions, publisher acceptance criteria, and QA benchmarks across project types.
- Game Developers Conference (GDC) Vault, “When Milestones Go Wrong” (2022 session): Practitioner retrospectives on alpha/beta slippage and recovery strategies.
Photo: Ann H via Pexels
