The Indie Game Development Process: Stages and Exit Criteria
The indie game development process runs through seven phases: concept, prototype, vertical slice, production, alpha/beta, launch, and post-launch, each with a concrete exit checklist. This walkthrough gives you those checklists, then maps the spots where tiny crews most often stall: unproven core loops, scope creep after the vertical slice, and milestone crunch with no shared plan.
What are the actual stages of the indie game development process?
The indie game development process runs through seven phases: concept, prototype, vertical slice, production, alpha/beta, launch, and post-launch. Each phase has a different job, and mixing them is where tiny crews lose months.
The seven phases at a glance
| Phase | Job | Rough time for a 2-8 person crew |
|---|---|---|
| Concept | Pick the game, define scope | 2-4 weeks |
| Prototype | Prove the core loop is fun | 4-8 weeks |
| Vertical slice | One polished slice of the final game | 2-3 months |
| Production | Build the full backlog | 6-18 months |
| Alpha/Beta | Feature-complete, then content-complete | 2-4 months |
| Launch | Ship the build, store page, marketing | 4-8 weeks |
| Post-launch | Patches, updates, community | Ongoing |
How timelines differ for solo devs vs 2-8 person teams
Solo devs typically double production time but skip coordination overhead, so concept and prototype move faster. A tiny crew parallelizes disciplines (art while code while audio) but pays for it in communication, which is why scattered Trello boards and Discord threads hurt most during production. Post-launch is its own discipline: Steam's documentation on release pages and post-launch updates (Steamworks docs) treats it as a distinct phase with its own assets and cadence, not an afterthought.
If you're mapping your backlog against these phases, Inferno is free for a tiny crew; see the pricing page.
How do you know when your prototype is done and production should start?
A prototype is done when the core loop is fun, not when the code is good. If your three-minute play session still generates a "one more try" reaction from strangers, the loop is proven. Everything else is decoration.
Exit criteria checklist for the prototype
- Core loop proven: the fundamental action (jump, shoot, build, negotiate) is fun for at least 60 uninterrupted seconds, verified by people outside the team.
- Throwaway code only: nothing in the prototype folder is destined for production. If you are refactoring, you have already started production without admitting it.
- Playtest signal: at least three external playtests where unprompted comments describe the loop, not the art.
- Scope written down: a one-page note of what the shipped game contains and, more importantly, what it does not.
The kill-or-commit decision gate
Set a date before prototyping starts. When it arrives, the whole tiny crew decides: commit to a vertical slice, or kill the project. Neither outcome is failure; drift is. If you commit, move the surviving design notes and backlog into a single shared workspace like Inferno so production decisions live next to the tasks they spawn, and delete the prototype branch.
What is a vertical slice and why do indie teams need one before scaling up?
A vertical slice is one short stretch of your game that is fully shippable: real art, real audio, real UI, real code, playable start to finish. If the final game runs at 60 fps with polished visuals, the slice should too. It is the moment your pipeline stops being theoretical. For a fuller treatment, see what a vertical slice is.
What must be inside a slice for a 2-8 person team
One complete level or encounter, final-quality art passing through your actual pipeline, sound and music mixed in, menus and HUD, and a build your whole crew can run. The exit criteria are simple: a stranger plays it without you explaining anything, and no discipline needed a placeholder to hit it. If your artist is still using grey boxes, the slice is not done.
Common slice mistakes that hide scope creep
Teams polish the slice into a demo and call it production, or build the slice with throwaway code that never ships. GDC postmortems repeatedly flag this gap between slice and full production as a stall point (GDC Vault). Track slice items against the rest of your backlog in one board, and be honest about what is still a placeholder; Inferno keeps that slice-versus-backlog split visible, though it will not stop a crew from gold-plating one level for three months.
Which engine and language choices affect each stage of the process differently?
Engine choice by phase, not by feature list
For a game jam prototype, the best engine is the one you already have open. Jam speed rewards Unity or Godot with familiar templates, not the engine with the best renderer. At the vertical slice, the question flips: can this engine carry your target platform, your build pipeline, and your art discipline without fighting you? By production, the answer is usually locked, and switching costs a milestone. At launch, porting becomes the filter, so console export paths matter more than anything a feature list promised back at concept.
When a language swap actually pays off
Rarely, and almost never mid-production. C# or GDScript is fine for the whole indie game development process if your team ships with it. A swap pays off in two cases: performance-critical systems that profiling proves are bottlenecked, and tooling your pipeline needs that the engine language handles badly. Otherwise, maintainability beats elegance.
Your crew of four has one shared context, and rewriting it for a language preference is scope creep wearing a technical costume. Whatever you pick, keep decisions and their reasoning in one place your whole team can see, the way we handle it on our workspace, so a 2 a.m. build break never becomes archaeology.
Where do indie projects most commonly stall or get abandoned, and why?
Most indie projects die at four predictable points, and each has a distinct cause you can plan around.
The post-jam hangover
Jam code is written to demo, not to last. The week after a jam ends, the crew reads the codebase, finds no documentation, and momentum dies. If nobody commits to a two-week cleanup sprint immediately, the project is usually abandoned on the spot.
Mid-production backlog bloat
After the vertical slice, every discipline dumps ideas into the backlog faster than the crew can ship them. The board stops reflecting reality, standups turn into archaeology across Discord and Google Docs, and morale drops because progress is invisible. This is the stall point where a shared workspace earns its keep; we break down how Inferno compares to Codecks for exactly this phase in Inferno vs Codecks. For the scope side of this stall, see scope creep vs feature creep.
The 80% trap
The last stretch before alpha is all unglamorous work: save systems, menus, edge cases. Teams misjudge remaining effort because polished slices hide unfinished systems. Track engine-specific known issues against your milestone dates using the engine's own issue trackers and docs, such as the Godot documentation, to keep estimates honest. Launch-week burnout is the fourth stall: crews that skip scope cuts in production pay for it in crunch they cannot sustain.
How does scope management change the process for solo devs versus small teams?
Solo: cut features, protect the core loop
A solo dev's scope problem is volume: every feature is a promise you make only to yourself. The discipline that works is cutting features, never quality. If the core loop is fun, ship it with three enemy types instead of ten. A useful rule: any feature that doesn't feed the core loop goes on a "post-launch" list you actually expect to ignore. Solo scope creep is quiet because there's no one to say no to, so write the cut list down and treat it as a real decision.
Tiny crew: dependencies across Design, Art, Code, Audio
With 2-8 people, scope is no longer just a feature list. Every feature you keep creates cross-discipline work: a new weapon means Code wires it, Art animates it, Audio scores it, Design balances it. Cutting one feature can free four people; keeping one can serialize a whole milestone. The shared backlog becomes the contract. If tasks live in one place with owners and dependencies visible, a tiny crew can see when a "small addition" actually costs a week of the artist's pipeline. If the backlog is scattered across chat and docs, scope creep wins by default.
What should the post-launch phase look for an indie studio?
The first 30 days after ship
The first month decides whether launch momentum turns into a sustainable loop or burns out your tiny crew. Set an exit criterion now: within 30 days, every crash and top-voted bug should be triaged into three buckets: patch this week, patch next update, won't fix. Steam's own documentation on handling player feedback and updates recommends communicating patch timelines directly on your store page, which is where most of your players actually look.
Patch cadence and community loops
Pick a patch rhythm you can hold for eight weeks, then hold it. A hotfix within 48 hours of a build-breaking bug, then a content or balance update every two to three weeks, beats a heroic week-one crunch followed by silence. Fold Discord reports and reviews into the same backlog you used during production so triage is one board, not three. After 30 days, decide explicitly: continue updates, plan DLC, or call it done and start the next prototype. An unmade decision is how indie teams drift for six months.
Which tools keep a tiny crew through every phase without scattered docs?
What a phase-aware board needs
The same exit criteria that gate each phase should live on your board, not in a doc. A phase-aware task board needs milestone-linked backlogs, discipline filters so Art and Code can triage independently, and a way to mark a task as blocking the vertical slice or the build. Generic kanban can sort of fake this with labels, but labels drift, and drifted labels are how "fixed stuff" commits happen.
Honest comparison: Inferno, Codecks, HacknPlan, Trello
Run every option through the same checklist and the tradeoffs get clear fast. Codecks blends chat-like card flow with task management, which suits distributed tiny crews. HacknPlan builds game-production structure in from the start. Trello is fast to set up but stays generic; your milestone logic lives in your head, not the tool. Projects.ink and t0ggles cover lighter multi-project needs.
Inferno, our own tool, pulls the whole production into one workspace so a 2-8 person crew plans, builds, and ships without a second tab. Where it falls short: it is newer, so fewer integrations and tutorials exist than for Trello, and teams deep in another tool's history face real migration friction. If your pipeline already lives elsewhere, switching costs are the honest con, not features.
FAQ
Is indie game development worth it financially in 2026?
Most indie games do not turn a profit, so treat the first project as tuition, not income. The financial case improves when you keep scope small, ship within 6-18 months of production, and cut features that do not feed the core loop. Revenue depends heavily on store page quality and post-launch patch cadence, both of which cost time you must budget for upfront.
How long does the average indie game take to make with a small team?
For a 2-8 person crew, expect roughly 10-24 months from concept to launch: 2-4 weeks of concept, 4-8 weeks of prototype, 2-3 months for the vertical slice, 6-18 months of production, 2-4 months of alpha/beta, and 4-8 weeks of launch prep. Solo devs typically double production time but move faster through concept and prototyping.
Do I need a game design document, or is a one-pager enough?
A one-pager is enough at the prototype gate, where it mainly records what the shipped game will not contain. By production, you need more than a page, but not a 100-page document: a shared backlog with owners, dependencies, and the reasoning behind decisions. Scattered docs across Discord and Google Docs are how mid-production stalls happen.
What is the best indie game development software for someone who can't code?
Godot with GDScript or Unity with visual scripting are the practical starting points, since both have large tutorial libraries and jam-friendly templates. Pick the engine you already have open for prototyping; the choice matters more at the vertical slice, where platform targets and build pipelines become the filter. Switching engines mid-production costs a milestone, so commit before scaling up.
How do I find an indie game development community for playtesting and feedback?
Look for local game dev meetups and game jams first, since jams put strangers in front of your build fast. Discord communities around your engine are the next stop. The exit criterion that matters: at least three external playtests where unprompted comments describe the loop, not the art. If testers only praise visuals, your core loop is still unproven.