The 7 phases of game development (and what actually goes wrong in each)
A practical guide to every stage of game production, from brainstorming to post-launch
There’s a multitude of versions of this article . Production phases, clean diagrams, everything neatly labeled. I’ve read those and you probably have too. They’re useful the same way a map of a city is useful before you’ve ever visited: they give you a general sense of orientation and then reality immediately complicates everything.
What I want to give you instead is the version I wish someone had handed me early in my career. Not the sanitized process overview, but an honest account of what each phase is actually for, what questions you’re supposed to be answering, what work actually happens in each phase, when things go wrong and why and how you know whether you’re ready to move forward.
Before I get into the phases themselves, I want to say something about the overall structure, because how you think about this shapes everything.
Why phases exist at all
The natural instinct of a new studio is to treat development as a continuous arc: you have an idea, you build it, you ship it. For extremely simple projects with very small teams, it can sometimes work. For anything with meaningful scope or creative ambition, the absence of deliberate phase thinking tends to produce a specific set of problems: ideas committed to before they've been tested, infrastructure missing when it's needed most, and the hardest questions deferred to exactly the moment when they're most expensive to answer.
Phases exist to make the cost of being wrong as low as possible at every stage. They don’t eliminate uncertainty. They give uncertainty a proper place to live, so that when the answers arrive, positive or negative, you can act on them without having already over-committed.
The other thing I want to name explicitly: a greenlight is not permission to stop thinking critically. Every phase transition should raise the bar for rigor, not lower it. I’ve seen teams treat a greenlight as emotional relief rather than earned confidence, and the projects that do this tend to carry unresolved problems forward until those problems become crises.
Now the phases.
Phase 1: brainstorming and strategic feasibility analysis
The question: what are we exploring - and should we?
Most articles treat this as a warm-up. I don’t. This is one of the most consequential phases in the entire development lifecycle and it’s also the one that gets least attention, least time and least rigor.
The goal here is not to pick the best idea. It’s to avoid committing to the wrong one. Those are meaningfully different objectives.
How it works
I like to break the team into small groups and give them a short, fixed window (48 hours works well) to develop a lightweight pitch for one or two game concepts. The constraint is deliberate. Time-boxing forces people to focus on the essence of an idea rather than over-polishing a presentation.
The pitch format doesn’t need to be elaborate: what is the game? What is the hook or differentiator? What does the experience feel like? Who is it for and on which platform? Why this game, why now, why this team? That’s it.
After pitches, I let the team vote or stack-rank ideas, not as a democratic decision, but as a signal. Patterns matter more than winners. If three ideas cluster at the top, that tells you something about shared taste and ambition. If votes scatter evenly, that tells you something else.
Then leadership takes the top ideas and subjects them to a genuine strategic feasibility analysis. This is where the real work happens.
The analysis looks at five dimensions simultaneously, because projects almost never fail at a single obvious fault. They fail at the intersection of constraints:
Market: where is this genre in its lifecycle? How large is the audience and how reachable is it? What are the typical business models in this space?
Trends: platform momentum, shifts in player behavior, tech tailwinds or headwinds, business models rising or fading
Competitive landscape: how crowded is the space? Who dominates and why? What are they not doing well? Is your differentiation plausible or wishful?
Development constraints: team competencies and experience, scope viability, key-person dependencies, runway relative to time-to-ship
The gut check: what genuinely excites the team? Is this a credible next step for the studio? What do trusted external voices say?
The output of this phase is not a pitch deck. It’s a short list of ideas worth prototyping and a longer list of ideas you consciously decided not to pursue. That second list is just as important as the first. Saying no at the right moment preserves energy, trust and optionality. It’s hard, but it’s essential.
Greenlight criteria
A compelling concept with a clear differentiator and identifiable audience
Alignment with studio vision, competencies and financial reality
No obvious strategic blockers that haven’t been named and accepted
Leadership alignment around why this idea is worth further investment
What goes wrong
Emotional commitment before strategic commitment. Teams fall in love with an idea during brainstorming and behave as if it’s already been greenlit. The feasibility analysis becomes performative and market data cherry-picked to confirm a decision already made. The tell is usually a pitch that sounds compelling until you ask how long it would actually take to build.
Phase 2: rapid prototyping
The question: can we find the fun or the hook quickly?
After strategic feasibility, you typically have one or two ideas that look promising enough to warrant further investment. This is where many studios make a quiet, costly mistake: they move directly into concept development or pre-production with nothing more than a loose idea, some references and conviction.
The prototype changes everything. Switching from an idea that only lives in a document to something you can actually play, even if it’s hacky and you have to squint hard to see what it’s trying to be, exposes things that no amount of discussion can. The gap between conceptual ideas and playable reality is almost always more revealing than anyone expects.
How it works
I favor a team of two to four developers, working in-engine, with a hard one-week timebox. Each prototype gets one week. Not two. Not “let’s see how it goes.” The constraint is intentional.
The prototype exists to answer a small number of specific questions:
Is the core loop engaging within minutes?
Does the differentiator actually change the experience in a meaningful way?
Does the mechanic fall apart under basic player behavior?
Are there obvious technical blockers?
Does this feel like something this team can execute?
Everything else is noise. Code is disposable. Assets are placeholders or throwaways. UX barely functions and that’s sufficient. If something cannot be tested in a week, it belongs in a later phase.
While the team prototypes, senior leadership continues feasibility analysis. The prototype doesn’t replace market, cost or funding thinking. It informs it. By the time the prototype is playable, you want creative, technical and business considerations all visible at once, so the greenlight decision is clean.
At the end of the week, everyone plays the prototype. Not a video walkthrough - hands on. The feedback session isn’t a postmortem; it’s signal gathering. Pay as much attention to how people respond as to what they say. Do they lean forward? Do they immediately start suggesting improvements without prompting? Are they excited in a way that feels earned, or politely supportive?
More often than not, the most valuable outcome of this phase is a clear no. A prototype that definitively doesn’t work has just saved you months of development on a fragile idea. That is not failure. In most cases, it is the highest-ROI work you will do all year.
Greenlight criteria
The prototype communicates the core concept in minutes
The core loop or differentiator is meaningfully engaging or surfaces clear insight about why it isn’t
Technical unknowns have been surfaced, not hidden
The team has a realistic read on what worked, what didn’t and what it means
What goes wrong
The classic trap is a prototype that feels fun for five minutes but has no depth, no longevity and no credible path forward. Internal excitement is not the same as player appeal and teams confuse the two more often than you’d think.
The other one I see constantly: letting the prototype bloat with features 'just in case,' or worse, trying to make prototype code reusable. I get the impulse. It feels efficient. It isn't though. The moment you start worrying about code quality in a prototype, you've stopped prototyping. You're just doing production with worse documentation.
Phase 3: concept bolstering
The question: do we actually understand the game we’re proposing to make?
This phase is where things often get confused, because it sits in an awkward middle space: you’ve committed to an idea in principle but you haven’t committed to building it yet. You are still discovering what the game is, not preparing to produce it.
The goal is convergence. By the end of this phase, you should be able to explain the game clearly, consistently and without hand-waving, to your team, to a publisher, to a potential investor, to yourself at two in the morning when you’re not sure why you’re doing this.
How it works
This phase runs approximately two to eight weeks, depending on concept complexity, genre, runway, etc. The team produces a set of foundational documents, not final bibles, but initial treatments that capture what you know and expose what you don’t. You also produce a first playable that builds on the prototype’s core strengths, not as reusable production code but as a more coherent expression of the intended experience.
The documentation produced here spans across disciplines:
For the team’s shared understanding:
A product strategy rubric: target player, underserved needs, value proposition, market analysis, business model canvas, financial projections
A high-level vision rubric: the player experience you’re promising, expressed in concrete terms, a mock review, a “back of the box” description, your mission with this game and its creative pillars
A game overview rubric: core loop, meta loop, core systems, key features, UX vision and game modes
For external use:
An investor or publisher pitch deck, tailored to whichever audience is relevant
A SWOT analysis
By discipline:
Design: a game design treatment covering the core and meta loops, key systems, UX direction
Art: an art treatment with mood boards, references and a rough visual direction
Narrative: a narrative treatment covering theme, tone, story arc and key characters
Engineering: an early technical assessment identifying major unknowns and proposed approaches
Greenlight criteria
The team is aligned around the creative concept
Executive leadership is aligned around the business and market analysis
The first playable reinforces that this is a concept worth pursuing
No major strategic or creative red flags have been left unaddressed
There is genuine buy-in, not just compliance, around the game’s potential
What goes wrong
Phase contamination is the main risk here: teams that are already writing production code or authoring final assets while this phase is still supposed to be producing insight.
The other common failure is producing documents that look thorough but answer the wrong questions. A hundred-slide pitch deck that doesn’t honestly address development risk is not concept bolstering. It’s a confidence display.
Phase 4: pre-production
The question: are we confident enough that we know what to build and how to build it?
Pre-production is far and away the most misunderstood phase in game development, and I want to push back on a pervasive assumption directly: pre-production is not primarily about the vertical slice.
In my experience, pre-production should be roughly 75% preparation - technology, tools, pipelines, documentation, processes and benchmarks - and only about 25% the creation of representative content.
The industry tendency to treat pre-production as “the phase where we make the vertical slice” systematically under-invests in preparation in favor of something visible and impressive. That’s a bad trade. A studio that enters production with robust pipelines, tested tools, solid documentation and clear working standards will consistently outperform one that enters with a pretty vertical slice and no infrastructure.
What I use instead of a full vertical slice is a proper, reusable first playable - a more coherent evolution of the concept bolstering work - combined with dedicated spikes on the riskiest features and content. The first playable doesn’t need to demonstrate every system, every interaction or cover every game mode. It needs to demonstrate the core loop and the primary differentiators convincingly enough to validate continued investment and inform what production needs to deliver.
How it works
The team expands modestly from concept bolstering, though lean and fast remains the right orientation. The focus divides across three main work streams:
Building production infrastructure:
Stress-testing and validating all asset pipelines - 3D art, audio, localization, automated testing
Building, documenting and training the team on all tools and workflows
Identifying, vetting and onboarding outsourcers before production begins
Establishing clear working agreements and milestone structures with publishers if applicable
Authoring benchmark content:
3D art
Sound
Music
Dialog
Etc.
Whatever requires a benchmark and de-risks the authoring of content to the intended quality bar.
Creating production-ready documentation:
This is the bulk of the written output for the phase, and it covers every major discipline:
Art: a full art bible including references, concept art, mood boards, benchmark assets, technical specifications, naming conventions, memory and performance budgets and step-by-step authoring guidelines for every asset type.
If you have outsourcers, the outsourcing guide goes here too - identical standards, platform-specific workflows, vendor tests and onboarding materials.
Design: a design document covering pillars, player journey, core and meta loops, all systems and mechanics (combat, progression, inventory, AI behavior, etc.), UX, controls, game modes, interface design and authoring guidelines. Keep it comprehensive, not exhaustive.
A level design document covering level philosophy, block-out workflows, pacing, difficulty curves, environmental narrative and playtesting methodology.
Narrative: a narrative guide covering theme, tone, full story arc, branching narrative structure, character bibles, dialogue style, delivery mechanisms and integration with gameplay systems.
Audio: a full audio design bible - SFX style guide, benchmark assets, dynamic audio implementation guidelines, music composition and interactive music system documentation, VO casting and direction, technical specifications and memory budgets.
Engineering: a technical bible covering engine selection and version, middleware, development tools, coding conventions, code review processes, all asset pipelines and technical specs, game architecture, network architecture if applicable, platform-specific considerations, memory management, version control workflows, testing and debugging strategy, auto-testing frameworks, analytics and telemetry integration, and certification requirements for each target platform.
QA: a quality plan covering team structure and ramp-up, testing methodology (white-box, black-box, unit, integration, performance), test case design, bug reporting protocols including severity classifications and priorities, bug handling workflows, tooling, localization testing, certification testing and post-launch support.
Production: a work systems plan covering production methodology, organizational design, roles, RACI charts, ramp-up plan, communication strategy, development framework (Scrum, Kanban, waterfall or hybrid), tooling, roadmap, risk register, localization plan, outsourcing plan and a post-launch plan.
Also: a complete P&L, staffing plan and go-to-market strategy including community management.
Yes, this is indeed a lot. It’s supposed to be. The whole point of pre-production is that you walk into full production having already answered as many foreseeable questions as possible, so you don’t have to answer them in the middle of content development when the cost of doing so is highest.
On testing: one thing I want to call out explicitly, because it comes up constantly. Testing is not a phase that follows development. Testing happens at check-in.
Tolerance for build-breaking bugs should be near zero throughout - not because perfection is achievable, but because deferring quality to a dedicated testing phase is one of the most expensive decisions a team can make. Every bug that survives into production becomes more expensive to find, diagnose and fix than it would have been the day it was introduced. This doesn’t change in production; it becomes even more true.
Greenlight criteria
The first playable demonstrates that the core experience is achievable and compelling
All tools, pipelines and guides have been built, documented and validated by discipline directors
Critical risks identified during this phase have been addressed or explicitly accepted
Outsourcers are identified, tested, vetted and fully onboarded
Funding is secured
The team required for production is hired and onboarded (or penciled in, if they’re to join down the line)
This is the last practical moment to cancel the project. If serious doubts remain, address them here
What goes wrong
Pre-production gets cut short in almost every studio I've worked with. Every single one. And the reason is always the same: it doesn't feel like it's producing anything. No build to show, no content to demo, just documents and pipelines and process. So the pressure builds - “when do we actually start making the game?” - and the team pivots before the infrastructure is ready.
The consequences show up around the halfway point of production, like clockwork. The pipeline nobody built properly is grossly inefficient. The documentation nobody wrote means every new hire has to learn by bothering someone who's already behind.
Phase 5: production
The question: are we building the right thing and are we building it well?
Production is where the game actually gets made. It is the longest, most expensive and, in some ways, most demanding phase - and also the one where structural decisions made in every prior phase either pay off or come back to collect.
I want to address the traditional Alpha/Beta milestone structure directly, because I think it’s genuinely flawed.
The conventional model has Alpha representing feature-complete (all features built, assets still in progress) and Beta representing content-complete (all assets in, final polish and bug-fixing). The logic is that you validate gameplay first, then dress it up with final art and audio.
In practice, this creates two problems. Features built without their surrounding art, audio and narrative context are often misleading, they play differently once the experience around them matures, which leads to rework. And expecting final content to “fit” a feature set that’s already locked often surfaces design conflicts that are now expensive to fix because the feature work is done.
My preferred structure is iterative and incremental MVPs (or MLPs, if like me you’re into this kind of stuff). Instead of building all features and then all content, cross-functional pods work together to produce progressively more complete slices of the actual game experience - MVP 1, MVP 2, MVP 3 - each with specific sets of both features and content brought to a reasonable shipping quality (stable, relatively bug-free, optimized, within memory budget). Each MVP represents a genuine, complete increment of the intended player experience, even if small.
This approach has several advantages. The team always knows what the game actually feels like rather than guessing. Real players can be brought in at each step. Early Access becomes a natural milestone rather than a panic decision. And if something isn’t working (a system, a design direction, a feature assumption) you discover it when you still have room to act on it.
Within this production structure, I explicitly plan for and additional milestone:
Closed beta and/or Early Access: bringing real players in before launch is one of the highest-leverage things you can do. It converts community engagement into genuine product intelligence, it creates a base of invested players before launch, and it tells you things about your game that no amount of internal playtesting can. Plan for this deliberately, with clear criteria for what “ready for external players” means.
The same principle about continuous testing applies throughout production with no exceptions. A build should pass a basic test sweep pretty much daily and addressing major bugs and above should be part of the success criteria of most production objectives. Quality debt that accumulates silently in production becomes a crisis in closing.
Greenlight criteria at each internal milestone
Production milestones met on time and within budget
The build continues to reflect and advance the intended vision
Content is complete
Critical issues from internal playtests and QA are addressed or clearly tracked
The team output is sustainable, not in crunch, not losing people, not burning out
What goes wrong
Scope creep is the quintessential production challenge and it usually doesn’t announce itself as scope creep. It announces itself as “one more feature,” “let’s improve this system,” “we should add this mode.”
Each of these decisions, in isolation, often sounds reasonable. Collectively, they slide timelines, exhaust teams and produce games that are broader and shallower than they should be.
The discipline required to hold the line on scope during production - especially when the game is starting to feel good and everyone is excited - is one of the harder practical skills in game development.
Phase 6: closing and launch
The question: is this game ready to be in front of players?
Closing is a phase that most teams tend to organically transition into during production but that I much prefer drawing attention to as a completely separate phase, as it requires a change in mindset and adjustments to the team composition.
Closing begins when production ends, when the last feature has been built and the last bit of content has been authored. The team shifts formally and entirely to stabilization, performance, memory optimization, platform certification and final quality validation with the intention of generating release candidates (RCs) until one is good enough to be launched (the Gold master).
As mentioned, this phase requires the team to work differently and think differently. The creative impulse to keep improving things is one of the biggest risks here. Gold-plating (adding polish, tweaking features, squeezing in small improvements) is the enemy of actually shipping and make absolutely no mistake about it: it can stall the launch of the game in perpetuity.
How it works
First of all, the team reduces in size. When closing begins, the full team is seldom needed for the work of wrapping things up. Closing is typically best done by a reduced group focused entirely on stability and quality.
The teammates who are no longer part of the closing effort need a deliberate destination - ideally one of: beginning ideation on the next project, starting DLC development or taking the time off they’ve earned. Leaving this ambiguous is a fast path to people finding their own answers, which are not always the ones you would choose.
For the closing efforts, I’ve used cross-functional “polish pits” (small tiger teams that move through the game level by level, section by section, with explicit completion criteria for each area). Version control moves to atomic check-ins, where one check-in produces one build which produces one full test sweep. Every remaining bug is triaged, not everything will get fixed, and deciding what makes the cut requires judgment, not wishful thinking.
The closing phase also produces its own marketing and community output: launch-relevant materials, final trailer, launch campaign execution and the community push that converts your built-up audience into day-one players.
Typical documentation and artifacts
Gold master build, submitted for certification
Platform certification compliance documentation (TCRs/TRCs)
Launch-ready marketing assets and community materials
Post-launch plan, with team structure and priorities established before launch, not after
Greenlight criteria
Bug-free (or within explicitly accepted tolerances) Gold master and meeting the studio’s quality bar
Passes platform certification
Marketing and PR campaigns are prepared and scheduled
Post-launch team is assembled and has a clear plan
What goes wrong
The hardest challenge in closing is not technical, it’s emotional. Teams that have spent years building something find it genuinely difficult to stop. There is always one more improvement, one more bug worth fixing, one more thing that would make it better. The discipline to declare done when the game meets the bar rather than when it meets some imagined perfection is essential and it requires active leadership, not just process. This is especially true when the person driving for changes at the 11th hour is a founder deeply invested in the game.
The other form of failure is simpler: running out of steam. Closing phases that drag on past their natural end see motivation drop, which makes them drag on even longer. It becomes its own kind of loop. Keep the target visible, make the end feel real, and ship the thing.
Phase 7: post-launch
The question: what kind of game is this once real players are involved?
Post-launch is another underestimated phase and that underestimation usually traces back to the cognitive release that shipping provides. The game is out. That must mean we’re done.
For some games, that’s essentially true. A clean post-launch consists of monitoring stability, fixing critical bugs, releasing a patch or two and then moving on. That’s a legitimate and honorable outcome.
For others, post-launch is where the real work begins. Live service games, games with Early Access periods, multiplayer games, all of these have post-launch development cycles that can dwarf the original production effort. The mistake is not choosing one or the other. The mistake is being ambiguous about which one you’re doing.
The questions that need explicit answers
Are we committing to continued support and for how long?
What does “support” mean in this context - bug fixes only? Content updates? Feature development? Live ops?
Are we willing and able to respond to player feedback? Through what channel? On what timeline?
Does continued development make financial and creative sense given the game’s actual performance?
These decisions need to be made deliberately, before launch if possible and certainly within weeks of it. Post-launch ambiguity (everyone hoping someone else will decide what happens next) is one of the fastest ways to burn a team that just survived a long production cycle.
On live games specifically
For live service games, the post-launch team typically organizes around three objectives: acquisition (finding new players), retention (keeping existing players engaged) and monetization (converting engagement into sustainable revenue).
Each of these requires its own strategy, metrics and ownership. This is a deep topic that warrants its own dedicated article, but the important note here is: if you’re building a live game, post-launch is not a phase you plan for after you see how launch goes. You plan for it in pre-production and you staff for it before you ship.
What goes wrong
The most common failure is reactive post-launch management - studios that didn’t plan for post-launch scrambling to respond to player feedback, stability issues and community expectations with no clear framework for deciding what to prioritize.
The second most common failure is over-commitment: promising players a roadmap of updates and then failing to deliver because the team is exhausted, under-resourced or has already been moved on to the next project.
The map in one view
For reference, here’s the full sequence:
Brainstorming and strategic feasibility analysis - Idea generation, feasibility across five dimensions, strategic go/no-go
Rapid prototyping - Throwaway prototype, one week per idea, core loop and differentiator only
Concept bolstering - First playable, foundational documentation across all disciplines, investor/publisher pitch
Pre-production - 75% infrastructure (pipelines, tools, documentation), 25% first playable and feature spikes
Production - Iterative MVPs with both features and content, closed beta/Early Access milestone, closing sub-phase, team transition
Closing and launch - Stabilization, certification, reduced team, no new features, launch campaign
Post-launch - Explicit decisions about support scope, live ops if applicable, team health
If this was useful, you might also like:
