Vertical Slice Exit Criteria for Indie Game Production

For a small indie team, a vertical slice is done when it proves more than one polished scene: the core experience works for players, the team can reproduce the target quality, the technical path is credible, and the remaining unknowns are small enough to scale. Treat the end of the slice as a production gate, not a date. If one of those conditions is still uncertain, stay in pre-production and test the uncertainty directly.

Use the vertical slice to answer four production questions

A vertical slice should represent the game closely enough to test whether full production is a responsible next step. GDC’s Vertical Slice Challenge frames it as a gate between pre-production and production: the team should understand both what it is making and how to make it.

For a small team, that gate can be reduced to four questions:

1. Experience: Can a player understand and complete the representative loop without a developer coaching them?
2. Quality: Does the slice establish a believable target for art, audio, UX and game feel?
3. Production: Can the team make another comparable piece using the same workflow, rather than relying on one-off hero work?
4. Technology: Are performance, platform constraints and critical systems understood well enough to scale?

Nineva Studios’ vertical slice planning guide makes a similar distinction: a slice should validate gameplay, art direction, technology, UI, audio and the production pipeline at a limited scope. GameDevFoundry’s development-stage guide also lists repeatable pipeline viability and schedule estimates based on tested workflows among the evidence needed before production.

The important word is evidence. “It feels almost ready” is not an exit criterion.

Write exit criteria before the final polish pass

If you define success after seeing the build, it is easy to move the goalposts. Write the gate before the last round of polish.

A practical vertical slice exit checklist:

• Player proof: a representative player can complete the slice and understands the core objective without developer explanation.
• Core-loop proof: the main interaction is stable enough that the team is tuning it, not redesigning it every few days.
• Quality-bar proof: the team has concrete references for what “production quality” means in the disciplines that matter most.
• Pipeline proof: at least one representative asset, encounter, level segment or content unit has gone through the intended production workflow.
• Technical proof: critical systems run on the intended target configuration with known limits.
• Scope proof: the team can describe what full production includes and, equally important, what it excludes.
• Planning proof: the next production milestone can be estimated from work the team has actually performed, not from assumptions alone.
• Risk proof: remaining unknowns are named, owned and small enough that they do not threaten the basic production model.

This complements a playable milestone: the milestone defines the build you want next, while the exit criteria decide whether that build gives you enough evidence to scale.

Do not require perfection. A vertical slice can still contain known bugs, temporary tooling or technical debt. The question is whether those problems are bounded and understood.

Use PASS, HOLD or PIVOT instead of “done”

A binary “done/not done” decision hides useful nuance. Use three outcomes.

PASS means the slice supports the production model. Remaining issues are normal production work rather than unresolved foundations.

HOLD means the direction still looks viable, but one or more exit criteria lack evidence. The next step is a targeted test, not more general polish.

PIVOT means the slice exposed a problem that changes the production plan: perhaps the target visual quality is too expensive, the core loop still fails playtests, or performance requires a different technical approach.

This is where many teams lose time. They treat a HOLD as permission to keep polishing everything. Instead, turn the failed criterion into the smallest possible experiment.

For player-facing uncertainty, use a focused test rather than informal team opinion. The PlayablePlan guide on running an early indie playtest shows how to define one decision, one route and observable success criteria.

Example: a three-person action game team

Consider a hypothetical three-person team building a top-down action game.

Their vertical slice contains one arena, one enemy type, one upgrade choice and a near-final combat presentation. The build looks convincing, but the review finds three different results:

• Players understand the combat loop without help: PASS.
• The artist can produce one additional enemy to the target quality using the established pipeline: PASS.
• The programmer cannot yet maintain the target frame rate when several enemies and effects are active: HOLD.

The team should not add another arena or polish the menus. The failed gate is technical scalability.

The next task is narrower: reproduce the worst representative combat load, profile it on the target hardware, identify the dominant cost, and set an acceptable performance condition. If that test passes, the team can reopen the production gate. If it reveals that the visual target is unsustainable, the result may become a PIVOT.

That decision is more useful than another week of making the slice look finished.

Leave pre-production with a decision, not a showcase

A vertical slice earns its cost when it reduces the risk of scaling. GDC’s production framing and recent vertical-slice guides agree on the central point: the slice is not just a polished demo; it should prove that the intended game can be produced repeatedly at the required quality.

At your next slice review, mark each exit criterion PASS, HOLD or PIVOT and create work only for the failed evidence. If PlayablePlan is part of your workflow, keep that gate visible beside the next production milestone so the team scales from proof rather than optimism.