Blog

The Small Team Game Dev Workflow, Stage by Stage

By Lauren "Celeste" Rousell · October 21, 2026 · 10 min read

A game dev workflow is the full path from concept to post-launch: pre-production, asset pipeline, engine integration, vertical slice, QA, and shipping, with defined handoffs at each stage. This guide maps every stage for a tiny crew of 2-8, naming exactly what Art hands to Code, what Code hands to QA, and what comes back, so nothing lives only in someone's head at 11 PM before a milestone.

What are the core stages of a game dev workflow?

A game dev workflow for a tiny crew runs through seven stages: concept, pre-production, production, vertical slice, alpha, beta, and post-launch. Each stage has one job and one handoff: concept hands a pitch to pre-production, pre-production hands a locked scope to production, production hands a playable slice to QA, and post-launch hands live fixes back into the backlog.

The workflow at a glance

Why handoffs, not stages, break small teams

Stages rarely fail on their own. They fail at the seams, when art ships files the engine build can't read, or a "fixed stuff" commit lands with no linked task. Monday morning then becomes archaeology through changelists and chat threads. Defining each handoff explicitly, in writing, is what keeps a 2-8 person crew from rebuilding context every sprint. Tools like Codecks and HacknPlan encode these handoffs differently, and we compare how on our Inferno vs Codecks page.

How should small teams structure their pre-production workflow?

Pre-production for a tiny crew should run as two short phases: concept and prototype, each ending in a written gate decision. Keep the concept doc to a couple of pages in your shared workspace, then spend most of this stage building a playable prototype instead of polishing documentation. The goal is evidence, not a design bible.

The prototype gate

Set a date and a question for the gate: does the core loop hold up for 10 minutes of play? When the answer is yes, write down what production starts with. When it's no, cut or pivot before more disciplines pile in. On a 4-person team, a failed prototype caught at week 6 costs weeks; caught at month 4, it costs the milestone.

Scope decisions that lock the pipeline

The gate is also where you freeze pipeline choices: engine, art style, target platform, and how assets get named and handed off. Deciding these after production starts is how scope creep sneaks in. Write the decisions where tasks live, not in a doc nobody opens. If you're currently splitting this across Trello and docs, moving pre-production into one board changes the math (Inferno vs Trello).

How does the asset pipeline hand off to engine integration?

The handoff works when Art and Audio deliver assets Code can drop into the engine without asking questions. That means naming conventions, export settings, and a definition of done agreed before production starts, not negotiated per file.

What Art hands to Code

Every asset follows a fixed pattern: SM_ for static meshes, SK_ for skinned, T_ for textures, with the material and resolution appended, matching the conventions Unreal documents for its import pipeline (Unreal Engine documentation). Textures export at power-of-two resolutions with the compression setting specified in the brief. Prefabs or blueprint-ready meshes ship with pivots at the origin and scale set to 1.0, so nothing needs fixing inside the engine.

What Audio hands to Code

Audio delivers WAV files at the sample rate and channel count the engine import expects, loop points marked in the filename or a sidecar doc, and no stems unless the brief asks for them. Compressed formats are the engine's job, not the composer's.

A handoff checklist that fits on one page

The definition of done is the whole contract: correct name, correct format, correct scale, tested import, no stray files. If an asset fails any line, it goes back to the creator rather than getting patched by whoever found the problem.

This matters more on a tiny crew than a large one, because there is no asset wrangler to catch mistakes downstream. The programmer importing a broken texture at 11 PM before a milestone is time stolen from the build itself, and on a four-person team that hour is a meaningful slice of the working week gone. A failed import also cascades: the level blockout waits, the playtest slips, and the milestone review slides into a weekend nobody planned for. Write the checklist once, pin it in your shared workspace, and hold every discipline to it, including your own. Tools like HacknPlan and Codecks both support per-discipline task templates for this; we compare how they handle it in our HacknPlan comparison.

When does a build go from vertical slice to production-ready?

Treat the vertical slice as a gate, not a demo. A demo shows a fun moment; a slice proves your whole pipeline can produce that moment repeatedly. Until it does, full production will amplify broken handoffs, not fix them. Our guide to what a vertical slice is covers how to scope one.

What the slice proves about your pipeline

The slice is a stress test of the path from concept to shipped build. One art asset must travel from brief to import to on-screen without someone hand-fixing it. One code feature must land with a commit that names its task. One audio file must drop in without a manual pass. If any of those steps needed a workaround, the slice did its job: it found the crack while it was still cheap.

The milestone gate checklist

Before you call the slice done and open the production backlog, check five things:

• The build runs from a clean checkout with documented steps.
• Every asset in it passed through the normal pipeline, no exceptions.
• Every commit maps to a named task someone else can read.
• The team agrees the slice is fun, not just functional.
• Scope for production is written down, with cut lines marked.

If two or more fail, extend pre-production by a sprint. It is the cheapest extension you will ever buy. Once the gate passes, a tool like Inferno keeps the milestone board and the pipeline handoffs in one place so the discipline survives contact with production.

How do QA and playtesting fit into the workflow loop?

QA in a tiny crew is not a separate stage; it is a loop that runs against every build from the vertical slice onward. Playtest, log bugs, triage, fix, rebuild, playtest again. Academic work on game production describes this as iterative build-and-evaluate cycles layered on top of the linear stage model (IGDA), which is a useful way to think about it: the stages define handoffs, but the loop never stops until you ship.

Bug triage when everyone is also building

With 2-8 people, nobody is dedicated QA, so triage has to be fast and ruthless. Every bug gets one of three calls within a day: fix now (blocks the milestone), fix this sprint, or backlog. The person who found it tags the discipline that owns it, and the fixer links the commit to the bug so Friday-you can reconstruct what Monday-you did.

The Friday-night broken build problem

The 11 PM broken build happens when commits land without a linked task, leaving "fixed stuff" messages nobody can trace. The rule: no commit ships without a build verification step, and every commit references the bug or task it closes. We hold ourselves to the same standard in Inferno, though it can't stop someone from writing a lazy commit message.

What changes in the workflow after launch?

Launch flips the shape of your backlog. Before ship, most items are features; after, the mix becomes roughly maintenance-heavy: crash reports, balance tweaks, small quality-of-life fixes, and occasional content drops. Your milestone thinking shifts too. Instead of a vertical slice or ship date, you plan around patch versions, each with a small, closable scope.

Live bug intake becomes a standing pipeline. Funnel reports from Discord, Steam reviews, and your crash logs into one backlog, then triage weekly by severity: broken builds first, progression blockers next, polish last.

Patch workflow in three steps

1. Reproduce and scope. Confirm each bug on the current build and attach it to the patch version it belongs in.
2. Fix and verify. One person fixes, a different person verifies on the patched build, so nothing ships untested.
3. Cut, note, and watch. Ship the build, publish patch notes, and monitor crash logs for 48 hours before closing the patch.

The discipline that carried your pre-production carries here: small scope, clear handoffs, one shared board.

How do you map your workflow onto a task board?

Columns should mirror handoffs, not disciplines

A column per discipline (Art, Code, Audio) just recreates your org chart. Columns should match the handoff points from the workflow map: Backlog, In Design, In Build, In Review, Done. A card moves when the work crosses a handoff, so anyone glancing at the board sees where the milestone actually stands. Add two fields per card: the stage it belongs to (pre-production, vertical slice, QA) and the acceptance criteria for "done." That's enough to catch scope creep without turning the board into paperwork. For a fuller board layout, see our game project management setup.

Comparing boards for tiny crews

Trello is the cheapest starting point and fine for a pure kanban, but it has no game-specific structure. HacknPlan and Codecks both build milestones, decks, and asset tracking around game production, with Codecks paid tiers starting from about €6 per user per month. Projects.ink targets small studios with lightweight production planning. Inferno maps stages and handoffs directly, but it's honest about the gap: no native asset review tools yet, so art sign-off still happens outside the board.

What does a one-page workflow map look like for a 4-person team?

Picture a 4-person crew: one designer, one artist, one coder, one doing audio and production. Their map fits on a single page with six columns: Concept, Pre-production, Asset pipeline, Engine integration, Vertical slice, QA. Each column has one named owner and one handoff rule. The artist's handoff says "asset enters the board only when it imports clean into the engine," so nothing half-finished clogs the pipeline.

The weekly cadence is two beats: Monday, 30-minute milestone check where each discipline states what ships this week; Friday, build review where the coder runs the latest build and everyone plays it. Scope creep gets handled by one rule: anything new goes to the backlog, never the current sprint. That's the whole map, and it fits on one page.

FAQ

How many stages are in a game development pipeline?

Seven for a small crew: concept, pre-production, production, vertical slice, alpha, beta, and post-launch. Each stage has one job and one handoff to the next. Concept passes a pitch forward, pre-production passes a locked scope, production passes a playable slice, and post-launch feeds live fixes back into the backlog so the loop keeps running.

What is a vertical slice in game development?

A vertical slice is one polished, representative level built through your entire pipeline, used as a gate rather than a demo. It proves the whole path works: an asset travels from brief to import to on-screen without hand-fixing, and every commit maps to a named task. If steps needed workarounds, extend pre-production before opening full production.

How do indie teams handle asset handoff between artists and programmers?

With a one-page definition of done agreed before production: naming conventions like SM_ and T_, fixed export settings, correct scale and pivots, and a tested import. Assets failing any line go back to the creator instead of being patched by whoever finds the problem. On a tiny crew there is no asset wrangler downstream, so the contract has to hold.

What project management tool is best for a small indie game team?

It depends on how much game structure you want. Trello is the cheapest pure kanban but has no game-specific features. HacknPlan and Codecks build milestones and asset tracking around game production, with Codecks paid tiers starting from about €6 per user monthly. Inferno maps stages and handoffs directly, though art sign-off still happens outside the board.