First Playable Milestone Checklist for Game Producers

Forty-three percent of the projects I’ve seen blow their first playable milestone didn’t fail because the team lacked talent. They failed because nobody agreed on what “first playable” actually meant until two weeks before the deadline, when the arguments started.

That’s the real problem. “First playable” sounds self-explanatory until you’re in a room with a lead designer who thinks it means the core loop is designed, an engineer who thinks it means the core loop is coded, and a publisher rep who thinks it means they’re about to see something close to a vertical slice. I’ve watched that exact miscommunication cost a studio 11 weeks of rescheduling and roughly $340,000 in contractor overruns. One studio. One milestone. One preventable disaster.

So let’s talk about what a first playable milestone actually is, what should be on your checklist, and where most producers quietly get it wrong.

What “First Playable” Actually Means (And Doesn’t Mean)

First playable is not a demo. It’s not a prototype, though it grows out of one. It’s the moment your game can be played from a start state through the primary interaction loop, even if it’s ugly, buggy, and missing 80% of its content. The functional definition I use: a human being can pick it up, attempt to play the intended game, and give you meaningful feedback on whether the core mechanic feels good.

That’s it. Not whether it’s fun (though hopefully it is). Not whether it’s close to shippable. Just: is there a game here, can a person play it, and can we learn from watching them.

What most people don’t realize is that “first playable” has a totally different scope depending on your studio size and deal structure. An indie team of four has a first playable that looks nothing like the first playable a 60-person team is delivering to a publisher under a milestone payment agreement. If you’ve got a publisher contract, that contract should define this milestone explicitly, and you need to read that language carefully before anything else on this checklist matters.

The Checklist Itself

I break this into four zones. Not because everything is equally important in each zone, but because they fail in different ways.

Zone 1: Core Loop Playable

This is the non-negotiable. The primary mechanic the game is built around must be executable by a player. In a platformer, that means you can run and jump through a space. In a card-based roguelike, that means you can draw, play cards, and resolve combat. In a city builder, that means you can place structures and see the economy tick.

The checklist items here are:

• Player character (or equivalent agent) instantiates correctly
• Primary input scheme is mapped and responsive
• The loop has a defined start state, active state, and at minimum a fail state or loop-back state
• At least one “win condition” or “progress marker” registers correctly in the game’s internal logic
• The loop can be completed at least three times consecutively without a hard crash

That last one is more important than it sounds. I’ve seen demos fall apart in publisher meetings on the second run-through because nobody had looped the build more than once before the meeting. The “three consecutive loops without a hard crash” rule has saved me from embarrassment twice in my career.

Zone 2: Technical Baseline

• Target platform is defined and builds are running on target hardware (not just dev machines)
• Frame rate is stable enough to assess gameplay feel, even if it’s not optimized (30fps minimum for most genres, 60fps for anything where responsiveness is the mechanic)
• No memory leaks that crash the build within 15 minutes of play
• Basic telemetry or logging is in place so you can capture what playtesters are doing
• Source control is structured and a clean build can be pulled and run by someone outside the core team in under 30 minutes

That 30-minute build test is something I started requiring after a producer friend of mine, working on a mid-budget RPG in Toronto, had a milestone review where the build took four hours to configure on the reviewer’s machine. The milestone was technically passed. The relationship with the publisher was not.

Zone 3: Content Threshold

This is where scope discipline lives or dies. You don’t need all the content. You need enough content to assess whether the loop is actually fun. For most games, that means:

• At least one complete level, encounter, or equivalent self-contained experience using final (or near-final) design intent, even if placeholder art
• At least one piece of placeholder art that clearly communicates what the final version is targeting
• UI is functional for core actions (doesn’t have to be pretty, has to be readable)
• Audio is present for at least the primary action feedback loop (jump sound, hit sound, card play sound, whatever is central)

The audio one surprises people. But I’ve never had a playtest session where the absence of sound didn’t skew feedback in a way that muddied the data. Even rough placeholder audio is better than silence.

Zone 4: Process Documentation

This is the one producers forget most often because it feels like admin. It isn’t.

• Feature freeze list is documented: what’s in scope for this milestone, what’s explicitly deferred
• Known bugs list is current and triaged (not fixed, just known and triaged)
• Playtest plan is written: who’s playing, what questions you’re answering, how you’re capturing data
• Milestone demo script exists, even if it’s two paragraphs
• Post-milestone retrospective is already scheduled

If you don’t have a feature freeze list signed off before you enter the final two weeks before first playable, you will get scope creep that breaks your build. Every time. I’m not exaggerating.

The Timeline Reality

Here’s where I want to be blunt, because most articles on this topic are not.

These are rough estimates from my own experience across projects, not a formal study. But they’re pretty close to what I’ve seen consistently.

Notice the failure modes are different at every scale. That matters for where you put your energy as a producer.

Three Real Scenarios

Small indie team, puzzle platformer, two developers: They had a playable loop at week 9 but skipped the “three consecutive loops” test. The loop had a save state bug that only triggered on the second playthrough. Publisher demo went badly. They rescheduled, fixed it in four days, re-demoed. Final result: milestone accepted, but relationship damaged by a two-week delay that was entirely preventable.

Mid-size team, action RPG, publisher deal: The contract defined “first playable” as “primary combat loop functional with at least three enemy types.” Team only had two enemy types ready. Producer tried to present it anyway. Publisher rejected the milestone and held the $180,000 payment. Team had to build the third enemy type in three weeks under financial pressure. Lesson: read your contract language, then read it again.

Solo developer, narrative game, self-publishing: No formal milestone process, which is actually fine for a solo dev. But he had no playtest plan, so his first playable sat unplayed by anyone else for six weeks while he kept adding features. When he finally showed it to three people, two fundamental navigation problems emerged that required rearchitecting a core system. He estimated it cost him four months of misdirected work. A single structured playtest at first playable would have caught it at week 10 instead of week 24.

Tools Worth Using

For milestone tracking, Hack n Plan (currently around $6-$8 per seat/month as of July 2026) is purpose-built for game dev and handles milestone structures better than generic project management tools. If you’re on a tight budget, a well-structured Notion database can get you there, though it requires more setup discipline.

For playtest session documentation, Loom is underrated. Record the playtest, timestamp your notes, and you have a reference that’s harder to argue with than memory. For anything more structured, PlaytestCloud is worth the cost if you’re doing remote unmoderated playtests.

If you want to go deeper on production methodology, Project Management for Video Game Developers by Heather Maxwell Chandler is the closest thing to a standard text the industry has, and it covers milestone structures in useful detail. Raph Koster’s A Theory of Fun isn’t a production book, but understanding it will make you better at assessing whether your first playable is actually testing the right thing.

Sources

• Heather Maxwell Chandler, Game Production Roadmap (2020): Industry-standard reference on milestone structures and production pipelines for game development.
• IGDA Developer Satisfaction Survey: Annual survey tracking developer experiences, project timelines, and production practices across studio sizes.
• Game Developers Conference (GDC) Vault: Archive of production sessions covering milestone planning, publisher relations, and agile adaptation in game dev contexts.
• Raph Koster, A Theory of Fun for Game Design (2004, revised 2014): Foundational text on game mechanics and what makes a play loop worth evaluating.

Photo: RDNE Stock project via Pexels