First Playable Milestone Checklist for Game Producers

When a team blows its first playable milestone, it is rarely for lack of talent. More often, nobody agreed on what “first playable” 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. That miscommunication can cost weeks of rescheduling and real money in contractor overruns, all for one milestone and all preventable.

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 exists to stop exactly that.

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 silence skews playtest feedback in ways that muddy 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.

|—|—| | 1 to 3 person indie | Scope creep, no feature freeze | | 4 to 8 person indie | Tech debt from moving too fast | | 10 to 20 person mid-size | Communication gaps between disciplines | | 20 to 50 person team | Milestone definition drifting from what the publisher expects | | 50+ person team | Organizational misalignment on milestone criteria |

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

Three ways first playable goes wrong

Skipping the repeat-loop test. A team has a playable loop but never plays it through more than once before the demo. A bug that only appears on the second run surfaces in front of the publisher. The fix takes days; the damage to confidence lasts longer. Loop the build several times before anyone else sees it.

Missing the contract definition. If a publishing contract defines first playable as “primary combat loop functional with at least three enemy types,” two enemy types is a failed milestone, however good they are, and a milestone payment may be held until it passes. Read your contract language, then read it again.

Never showing it to anyone. A solo developer without a formal milestone process is fine, but a first playable nobody else plays is wasted. The longer it sits unplayed while features pile on, the more expensive the fundamental problems become when someone finally finds them. One structured playtest at first playable catches them while they are cheap.

Tools Worth Using

For milestone tracking, HacknPlan 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, The Game Production Handbook 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.
• 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