Production
When a Prototype Is Ready for a Vertical Slice
A gate for deciding whether a promising experiment deserves production-quality systems, art, audio, and content.

A prototype asks whether an idea works. A vertical slice asks whether the team can produce the intended experience at representative quality. Moving between them too early turns unresolved design into expensive content; moving too late can hide production risks until the project has already accumulated throwaway work.
Confirm the core loop is observable
The slice should not be the first time outsiders can understand the main activity. Before committing, testers should be able to describe what they are trying to achieve, make at least one meaningful decision, recognize success and failure, and recover without the designer narrating every step. This does not mean the loop is final. It means the team can identify which parts are stable enough to represent.
Write down what is deliberately excluded. A combat slice may not validate long-term progression. A narrative slice may not prove content-production speed. Naming these gaps protects the slice from becoming a false forecast for the entire game.
Choose a representative path, not the easiest room
Select a short sequence that exercises the real pipeline: environment construction, gameplay scripting, interface, audio, saving, loading, localization-ready text, settings, and a transition between states. A beautiful isolated arena can impress while avoiding the integration work that makes production difficult.
The slice should include one difficult but common case. If the game depends on crowds, include a representative crowd. If it depends on systemic interactions, include enough overlapping rules to expose debugging cost. Do not choose the project’s largest set piece; choose a segment that reveals normal production.
A worked readiness review
Consider a team planning a ten-minute stealth slice. The movement and detection prototype is readable, but save/load is absent, input rebinding is postponed, and environment art requires manual setup for every light. The design evidence may be strong, yet the production system is not ready. The review should convert those gaps into explicit slice goals rather than hiding them behind polished footage.
The team may decide to build one reusable lighting preset, one complete settings screen, a checkpoint, and two enemy variations. After the slice, it measures the time to build, test, and revise the space. If one ten-minute area consumes a quarter of the planned schedule, the result is not a failure; it is a production forecast that arrived early enough to change scope.
Measure throughput and rework
Record hours by pipeline stage, the number of revisions, defect classes, performance captures, memory use on target hardware, and dependencies that required specialist intervention. Avoid converting one slice directly into a full schedule with a simple multiplier. Later content may become faster through reuse, while narrative, certification, localization, and platform work can add costs the slice did not include.
Review asset ownership and naming at the same time. Temporary licensed material, generated references, and third-party packages need clear provenance and replacement decisions. A slice intended for public use must not inherit prototype assets whose rights or disclosure status are uncertain.
Make the gate decision explicit
There are four honest outcomes: proceed with the current direction; proceed after a named risk is reduced; repeat the slice with a narrower target; or stop. “Proceed, but we will optimize later” is not a decision when representative hardware already misses the frame target. “Proceed, but accessibility later” is equally risky when UI scale or input architecture would require structural rework.
Our editorial judgment is that a vertical slice succeeds when it improves the forecast, not when it looks like a trailer. A visually modest slice that exposes content cost, integration risk, and player comprehension is more valuable than a polished corridor that the team cannot reproduce.
Sources and verification
Primary documentation checked on 25 September 2026. Product and platform requirements can change; recheck the linked source before release work.
