Playable Business
Production Notes

Game Development Stages: From Pitch to Live Support

Playable Business · Updated 2026-07-19 · 8 min read
Game Development Stages: From Pitch to Live Support
Quick answerA useful game-development map has six overlapping stages: concept, pre-production, production, validation and quality assurance, launch preparation and release, then post-launch support or live operations. Teams revisit earlier decisions throughout; the labels are management tools, not universal gates. Each stage should have an owner, evidence, budget, risks, and an exit decision. A prototype proves a question, a vertical slice demonstrates a representative quality bar, and content-complete or release-candidate labels require each studio to define them explicitly.
Contents

Use six overlapping stages, each with an exit decision

A useful game-development map has six stages: concept; pre-production; production; validation and quality assurance; launch preparation and release; then post-launch support or live operations. Teams revisit earlier decisions throughout. The labels are management tools, not universal gates: every studio must define the owner, evidence, budget, risks, and decision that make a stage meaningful.

A prototype answers a focused question. A vertical slice demonstrates representative systems and a quality bar. “Alpha,” “beta,” “content complete,” and “release candidate” mean only what a team’s written criteria say they mean. Milestone vocabulary without criteria is office-themed fantasy.

The six-stage map

Stage Core question Useful evidence Exit decision
Concept Is there a coherent opportunity worth testing? pitch, audience hypothesis, core loop, constraints fund exploration or stop
Pre-production Can this team build the scoped game? prototypes, vertical slice, plan, risks, budget enter larger production, revise, or stop
Production Can the team create integrated content and systems predictably? playable builds, throughput, burn, defect and risk trends reach defined completeness
Validation and QA Does the game meet release criteria across users and platforms? tests, research, performance, compliance, accessibility approve candidate or return work
Launch preparation Can this build and organisation release and support safely? certified builds, stores, operations, support, rollback release, delay, or limit scope
Post-launch Can the game be maintained against its promises? incidents, stability, feedback, costs, service measures patch, expand, sustain, or sunset

The table looks linear because tables have a rectangle problem. Actual teams overlap stages, test continuously, and run different features at different maturity levels.

Stage 1: concept turns an idea into a testable opportunity

Concept work defines enough of the game to decide whether exploration deserves time and money. Typical questions include:

Outputs may include a pitch, playable experiment, market and audience research, creative pillars, reference art, technical spikes, and an early business case. None proves demand or commercial success.

The strongest concept documents state uncertainty. “Players will love this” is an aspiration. “We will test whether target players understand and repeat this mechanic without instruction” is a question with evidence attached.

Prototypes are disposable questions

A prototype may test movement, combat, camera, network architecture, procedural generation, controls, performance, or emotional tone. It can use temporary art and rough code because its purpose is learning.

Prototype quality should match the question. A grey-box level can test navigation but not final visual appeal. A polished combat room may test feel but not production throughput. Presenting one as proof of the other is how optimism quietly becomes a budget line.

Teams should record:

The exit from concept can be funding pre-production, another bounded test, a pivot, or cancellation. Stopping weak work early is a production outcome, not an absence of work.

Stage 2: pre-production tests the whole plan

Pre-production connects creative direction, technical architecture, tools, scope, team, budget, schedule, platform needs, and business model. It reduces the expensive unknowns before content production expands.

Common work includes:

The developer and publisher relationship affects who approves milestones, funds work, operates platform accounts, and owns deliverables. Put those responsibilities in writing.

A vertical slice demonstrates integration, not the whole game

A vertical slice is a representative playable segment intended to show several disciplines and systems working together near a target quality bar. It might include one level, encounter, quest, match, or loop.

Its value lies in integration: design, code, art, audio, interface, performance, tools, build, and production cooperate. But the slice can receive unusual focus and senior attention. It does not automatically prove the remaining content can be produced at the same cost or speed.

Define what the slice validates:

Also list what it does not validate, such as network scale, localisation breadth, progression depth, full accessibility, or months of live operation.

Stage 3: production scales systems and content

Production turns proven or sufficiently understood foundations into the planned game. Teams build features, levels, quests, assets, audio, interface, narrative, tools, services, and platform versions while continuously integrating them.

Management focuses on flow and risk:

“More people” does not linearly produce “more game.” Onboarding, communication paths, tools, review, and dependency load grow too. No responsible general article can supply one productivity figure for all teams.

Milestones need definitions and evidence

Studios use first playable, alpha, beta, content complete, feature complete, code complete, release candidate, gold, and other labels differently. Replace assumptions with criteria.

A milestone definition might state:

“Content complete” may mean planned launch content exists, not that it is final, optimised, certified, localised, or bug-free. A label cannot carry more certainty than the checklist beneath it.

Stage 4: validation and QA run throughout, then intensify

Quality assurance is not a room the build visits after production. Requirements review, automated tests, code review, asset validation, build checks, playtests, user research, compatibility, accessibility evaluation, localisation QA, security testing, and performance profiling should begin earlier.

Late-stage validation broadens because integrated systems reveal interactions:

Testing finds information; leadership decides risk. “QA approved it” should not become shorthand that transfers release accountability away from the people authorised to accept known defects.

User research and public testing answer different questions

Moderated research can observe comprehension, emotion, controls, onboarding, or accessibility with selected participants. Closed or open tests can expose scale, hardware variety, balance, server behaviour, and community dynamics.

Participants are not automatically representative of the full market. Self-selection, recruitment, incentives, platform, geography, and skill shape feedback. Combine qualitative observation, telemetry collected with appropriate disclosure, defect data, support themes, and business constraints.

One popular post can identify a real problem without measuring its prevalence. One dashboard can measure behaviour without explaining why it happened.

Stage 5: launch preparation is an operational release

Launching involves more than uploading a build. Teams coordinate:

A go/no-go review should include current build evidence, open risks, owner availability, rollback or containment, and the consequences of delay. Marketing spend already committed is a constraint, not proof that the build is ready.

The chosen revenue model expands the checklist. In-app purchases need entitlement, receipt, restoration, fraud, regional, and support testing; subscriptions add renewal and cancellation states.

Release is a transition, not the end

At launch, real players create combinations no test matrix fully captured. Monitor crashes, performance, servers, queues, payments, support, reviews, exploits, abuse, accessibility barriers, and data integrity.

Triage distinguishes:

Communicate what is known, what is being investigated, and when the next update will arrive. Avoid a confident root-cause story before evidence exists.

Stage 6: post-launch support or live operations

A finite offline game may receive patches, compatibility updates, localisation, DLC, or a final supported state. A live game adds server operations, ongoing content, economy management, security, moderation, anti-cheat, customer support, community, and an eventual service-ending plan.

The stage needs budgets and owners for:

An Early Access release overlaps production and public operation sooner. That makes feedback and expectation management production systems, not side-channel marketing.

Run a review at every gate

Use the same six prompts:

  1. What did we intend to learn or deliver?
  2. What evidence exists in this identified build?
  3. Which risks changed?
  4. Which assumptions failed?
  5. What work, money, people, and time does the next stage require?
  6. Is the decision proceed, revise, reduce, pause, or stop?

Record dissent and conditions. A green status produced by deleting every yellow row is not project health; it is spreadsheet gardening.

The stages work when they improve decisions. Concept narrows the question, pre-production tests feasibility, production creates the game, validation tests the promises, launch releases an organisation as well as a build, and post-launch proves whether that organisation can keep them.

FAQ

What happens during game pre-production?

Teams clarify the audience, core loop, scope, technical approach, art direction, production plan, risks, staffing, budget, and platform needs. They may build prototypes and a vertical slice to test different questions. Good pre-production reduces uncertainty; it does not guarantee the plan survives production. Exit criteria should state what evidence justifies larger spending and what remains unresolved.

What is a vertical slice in game development?

A vertical slice is a representative playable segment intended to demonstrate how several disciplines and systems work together at a target or near-target quality bar. Its exact scope varies. It is not automatically production-ready architecture, a public demo, or proof that all content can be produced at the same cost. Teams should state which risks the slice actually tests.

When does quality assurance start in game development?

Quality work should begin before the formal test phase. Requirements, prototypes, tools, builds, automation, and feature reviews all create opportunities to prevent defects. Dedicated QA activity typically expands as systems and content integrate. Testing near release cannot compensate cheaply for every architectural, scope, accessibility, localisation, performance, or usability problem discovered late.

What does content complete mean?

It usually means the planned release content has been implemented to a defined threshold, but studios use the label differently. It does not necessarily mean bug-free, fully optimised, certified, localised, or ready to ship. A useful milestone includes written inclusion criteria, known exceptions, build identification, owners, and the remaining work needed for the next gate.

What happens after a game launches?

Teams monitor stability, crashes, servers, support, reviews, accessibility issues, exploits, economy behaviour, and player feedback; ship patches; maintain platform compliance; and decide on content or service changes. A finite offline game still needs support planning. A live service adds ongoing operations, moderation, security, hosting, analytics, content cadence, and an eventual end-of-service responsibility.

Is every game-development pipeline the same?

No. Team size, genre, technology, financing, platform, external partners, regulation, release model, and organisational culture change the pipeline. A solo mobile game and a multi-studio console release cannot share one literal workflow. The transferable practice is to define terms, dependencies, evidence, decision owners, and risk—not copy stage names while leaving their meaning blank.