Prototyping Workflow
From rough prototype to a vertical slice
Build the bench first, then ship. A prototype is a question; a vertical slice is an answer you would bet a year of production on. This workflow is written for UK indie teams of one to ten people making PC games.
> write one line before the first commit
> include only what the line needs
> delete the build the day the line is answered
A prototype with no written question is a small game nobody asked for. The sentence decides what goes in and, more usefully, what stays out.
Before the first commit
Write the question before you build the prototype
Before the first line of code, write the question the prototype exists to answer — on one line, in plain language. That sentence decides what the prototype includes and, more usefully, what it excludes.
Exclusion is the point. No menus, no save system, no settings, no audio pass, placeholder art everywhere. The prototype gets thrown away the day the question is answered, and anything expensive inside it is money spent on a build you will delete.
Questions that carry a prototype
- Does the grapple feel good at speed?
- Is a three-card combo enough to carry a run?
- Is the fog readable on a 1080p laptop screen?
Time-box the prototype hard
Give the prototype a deadline measured in days or a couple of weeks, not months. When the deadline arrives, the answer is either there or it is not — and both are useful. A prototype that became a project is itself a finding: the team has a scope problem, and it is cheaper now than at any later stage.
Answer is good
Move on. Take the finding straight into the vertical slice plan.
Answer is bad
The direction changes now, not after a year of production.
No answer arrived
That is the finding. The scope crept, and the log will show where.
Alongside the build, keep a one-page log of what was built, what was learned and what was deliberately left out. That log becomes the opening document of the vertical slice and it settles arguments later.
The slice is a promise
The vertical slice is a promise, not a demo
A vertical slice is one level or one run, at close-to-final quality, with real art, real audio, a working menu, and a save system a stranger can use without help. It is not a demo for players — it is a demo for the team. If the slice is not fun, the full game will not be fun, and no amount of content fixes that. If the slice is fun, the production plan can be written against it instead of against a pitch.
The scope of the slice is deliberately tiny: one environment, one enemy set, one progression step, one ending state. Ninety percent of the systems stay out so the remaining ten percent can be proved at polish quality.
In the slice
- Core loop, primary camera, primary input method
- Primary art style for at least one scene
- UI at final quality for the screens the player actually sees
- A real save and load
Out of the slice
- Content volume and side quests
- Alternate modes and difficulty options
- Localisation and achievements
- Store integration
The exception is anything that changes the shape of the core loop. If difficulty settings change what "fun" means, they go in. If they are a multiplier on damage, they stay out. The loop is the filter.
Estimating honestly
Budget the slice in weeks, then double it
Vertical slices take longer than teams expect, and the usual reason is content discipline. The slice feels small in a planning document and it is genuinely small in playtime, but the art, UI and audio work on the one included level is the same work as the corresponding part of the shipped game. Estimate in weeks, then double the estimate before you commit a schedule. If the doubled number does not fit, the slice is still too big.
Do not use the slice to prove that the team can produce volume — that is what production is for. The slice proves that the smallest complete expression of the game is worth making.
First guess
Weeks, not months
The slice is priced in weeks of one focused level, not in the months the finished game implies.
Double before committing
Two-person reality
If one polished level took six weeks on two people, that figure — not the pitch — is what prices twelve levels.
If it does not fit
Narrow the game
The honest answer when the doubled number does not fit the runway is a smaller game, decided now rather than in month fourteen.
Strangers, not colleagues
Test the slice with people who have never seen it
Playtest the slice with at least three people who have not been in the room during development — ideally people who already play the genre you are building. Watch them, do not guide them, and take notes on the first five minutes and the first failure state.
If they get lost, the problem is the build, not the player. If they get bored, the core loop is not carrying its weight — better to find that out now than during production. Keep the sessions short and repeatable, and write the findings down the same day; those notes go straight into the production plan's risk list.
Pricing the plan
Turning the slice into a production plan
Write the production plan against what the slice actually took, not against the original pitch. Use the slice to price content, systems, art and audio, then compare that total against the runway. If it does not fit, the plan is to narrow the game — and that decision belongs now.
Three things the plan states before anything else is written
-
01
A stated release window
Priced against what the slice produced, not against what the team hoped the slice would produce.
-
02
A store launch date
Enough time to build the page, the demo build and the wishlist runway the launch needs.
-
03
A list of what is not being built
The most valuable part of the plan. Every feature that stayed out is a feature whose risk has already been retired.
If the plan is written against the pitch, the schedule fails on the first system that behaves differently from the way the pitch assumed. The slice is the honest number.
Where slices drift
Common ways the slice fails
Each of these is avoidable with a written question, a hard deadline and an honest playtest. The corrective action is usually to cut scope, not to add time.
Content ambition
The slice becomes a demo with content ambitions and eats the schedule that was meant for the production plan.
Late polish
The team delays the slice to add polish that production will redo anyway, at a quality the slice never needed.
Late test
The slice is tested late or not at all, so a core loop problem is discovered during production instead of before it.
The whole workflow
A short first-slice checklist
Eight lines, printed and pinned above the desk. If the team can answer all eight before the first sprint, the slice has a fighting chance of landing honestly.
First-slice checklist
eight lines- 01 Write the question on one line.
- 02 Set the deadline in days, not months.
- 03 Decide the one level or one run.
- 04 Define the final-quality bar for art, UI and audio on that one level.
- 05 Include a working save.
- 06 Book three playtesters early.
- 07 Write the findings down the same day.
- 08 Write the production plan against the numbers the slice produced, not the numbers the pitch wanted.
Next
Not chosen an engine yet?
The prototyping workflow assumes the engine decision is already made. If it is not, start with the engine guide.
Also useful
Building for Steam and Deck
Once the slice is fun, the storefront and handheld pass become the next honest test of the same core loop.
If it helps
Send us your slice plan
If the plan needs a second pair of eyes, we read one-page slice plans and answer with notes, not with a sales call.