Picture the scene. A small team - talented, excited, under pressure - ships a prototype to a publisher. The core game mechanic is there. It's rough around the edges, the UI barely exists, and there's no audio to speak of. But it works, and more importantly, it's fun. The publisher, suitably impressed, greenlights the next stage. Funding lands. The team expands. Development accelerates.

And then, quietly, a clock starts ticking.

The code that made the prototype feel fun was written in a sprint. Architecture was an afterthought. Nobody profiled it. Nobody needed to - it was a prototype, and it was doing its job. But now that prototype is the foundation of a production codebase, and the team is building on top of it, fast, because the milestones are tight and the next funding tranche depends on hitting them. The clock keeps ticking. By the time someone finally asks "will this scale to a full game?" the answer, too often, is no.

This is the Fail Fast trap. And right now, it's playing out in studios everywhere.

What "Fail Fast" Actually Means

The Fail Fast philosophy - sometimes called fail early, fail cheap, or fail better - originated in the lean startup movement and migrated quickly into software development. The core principle is sound: validate ideas with minimal investment, surface flaws early when they're cheap to fix, and cut losses decisively when something isn't working. In game development, it maps neatly onto a pipeline of rapid prototyping followed by milestone-gated funding, where each stage is a proof point before the next tranche of investment.


Rami Ismail, co-founder of Vlambeer and a widely respected voice on game production, describes the research and prototyping phase as exactly this: its primary production goal is to "fail fast." The intent is to move quickly through variations, surface what doesn't work before months of investment are sunk into it, and pivot without losing the game. If prototyping gets stuck, he notes, the smart call is to cut losses early - because at that stage you've lost a month or two of work, not a year.

Info

The prototype stage isn't the problem. Moving fast at the beginning is exactly right. Prototypes are supposed to be thrown away. The failure mode is when the urgency of the prototype phase doesn't end when the prototype does.

The trouble is that milestone-driven funding creates structural pressure that doesn't simply turn off when you move into production. Each milestone is a gate: prove the game is fun, prove the mechanics work, prove the vertical slice, prove the first playable. Publishers, quite reasonably, want evidence that their investment is going somewhere before committing the next tranche. The result is that development is almost permanently in a sprint mindset - and the question of whether the codebase will hold up at full scale keeps getting pushed to the next milestone, and the next one after that.

The Pipeline and Its Pressure Points

The standard pathway from idea to full production runs through several well-defined stages, each with a different funding and risk profile.

flowchart TD A[Concept & Pitch] --> B[Rapid Prototype] B --> C{Viable?\nFun?\nNew?} C -- Yes --> D[Vertical Slice] C -- No --> X[❌ Kill / Pivot] D --> E{Worth funding\nfull production?} E -- Yes --> F[Full Production] E -- No --> X2[❌ Kill / Pivot] F --> G[Alpha] G --> H[Beta] H --> I[Ship] style C fill:#c8a84c,color:#1a1a2e style E fill:#c8a84c,color:#1a1a2e style X fill:#e07b3a,color:#fff style X2 fill:#e07b3a,color:#fff style I fill:#1dbba8,color:#fff

The rapid prototype answers one question: is this idea fun? It doesn't need clean code, good performance, or a scalable architecture. It needs to demonstrate a core loop, a central mechanic, something a player would want to do for five minutes. If it can do that, it moves forward.

The vertical slice is a different beast.
As the Ask A Game Dev production blog describes it, the vertical slice signals the end of pre-production and the beginning of commitment - a fully playable section developed to near-final quality that shows all disciplines working together: art, code, design, audio. It's the showcase that convinces publishers and executives that the team can actually make the game, not just prototype it. Most publishers won't fully fund a project from inception to completion without it.

What sits between the vertical slice and full production is where teams most consistently struggle. The vertical slice is often an intense, focused sprint - one level, one mission, a tiny slice of the final game brought to as high a standard as the team can manage. It proves the vision works. What it doesn't prove is whether the architecture that got you there will survive building the rest of the game on top of it.

The Technical Debt Clock

The concept of technical debt was first articulated by Ward Cunningham at OOPSLA in 1992 - the idea that shortcuts taken now create a form of debt that accrues interest over time. The longer it goes unaddressed, the more it costs to service: slower development velocity, more bugs, harder-to-maintain systems, and eventually the dreaded big rewrite.

In game development, this debt accumulates in particularly insidious ways because the early phases actively incentivise its creation. Prototype code isn't supposed to be clean. Vertical slice builds are supposed to be fast. The problem is that this code often doesn't get thrown away - it gets built upon.

Martin Fowler, who has written extensively on the subject, makes an important distinction about where the debt matters most: stable, untouched code can carry debt indefinitely, because you never have to pay the interest. It's the high-churn areas - the systems you're adding to, the code you're touching every sprint - where accumulated debt becomes genuinely crippling. In a game in full production, almost everything is high-churn, almost all the time.

Warning

The hidden danger of milestone pressure is that it creates a systematic incentive to defer. Every sprint, the team faces a choice: address the architectural issue that's slowing everyone down, or hit the milestone. In almost every case, the milestone wins - and the debt grows. By the time the codebase becomes genuinely unmanageable, the team may be two-thirds of the way through production, with a ship date immovable and no budget for a structural refactor.

So When Do You Stop and Breathe?

This is the question the funding structure doesn't easily answer. And it's the right question to be asking - because the answer genuinely matters for the quality of what ships.

Too early, and you're spending money refactoring a game that hasn't yet been proven to be worth building. A publisher who has funded a prototype doesn't want to see a sprint's worth of architectural cleanup. They want to see the game moving forward.

Too late, and you're in the situation many teams find themselves in: close enough to ship that no one will authorise the time to fix what's broken, far enough from quality that players will notice when they play it.

The answer isn't a fixed milestone. It's a condition. The right moment to pause on raw feature velocity and invest in structural quality is when you can answer yes to all of these:

That third point matters more than people acknowledge. A codebase written by two or three people who know every corner of it is manageable even if it's messy. Add five more developers, and the same codebase becomes a productivity sink. The investment in legibility and structure pays back quickly once the team scales.

Tip

Build a "tech debt sprint" into your production plan deliberately - ideally immediately after the vertical slice is approved and before full production staffing ramps up. This is the highest-leverage moment: the game is proven, the scope is set, and you haven't yet added the people who will be trying to work with the code you're about to clean up.

What Crunch Does to Learning

There is a related problem that doesn't get talked about enough in the context of fast-cycle development: under sustained pressure, people don't learn.

This matters enormously in the current era, where most studios are building on complex, deep platforms - Unreal Engine 5, Unity - that reward genuine expertise and punish superficial familiarity. When a development sprint is followed immediately by another development sprint, developers don't have the bandwidth to properly understand the tools they're using. They learn to do things, not to understand why they work. And when something breaks in a way that requires deep knowledge - a frame budget that doesn't add up, a memory profile that makes no sense, a physics system that's somehow running everywhere - they don't have the foundation to diagnose it.

The IGDA's 2023 Developer Satisfaction Survey, conducted in partnership with Western University across 777 respondents, paints a clear picture of the working conditions that characterise this environment. Some 28% of respondents reported their job involved crunch time, with a further 25% reporting extended working hours they simply didn't call crunch. Of those who did experience crunch, 59% were working more than 50 hours per week during those periods - and 10% were working more than 80 hours a week.

The trend is improving - crunch in 2023 was meaningfully lower than in 2017 - but more than half of respondents in 2023 still reported working beyond standard hours in one form or another. And behind that number is a development environment that consistently doesn't leave room for the deep, deliberate practice that turns a competent developer into an expert one.

If your team is constantly sprinting to hit the next milestone, they are not developing the kind of platform knowledge that prevents the architectural mistakes - the kind of expensive, late-stage problems that kill launches and derail post-release support. The time spent learning isn't wasted time. It's an investment in future velocity that the milestone model systematically undervalues.

Info

A note from the trenches. When I started in games, development cycles like the ones I'm describing weren't new - they were just the industry. Destruction Derby went from concept to shipped product in under a year, by a team of seven. We were learning a new platform while building on it at the same time, and most of us had come up through 8 and 16-bit assembly code before landing in C.

C++ came later - and in the meantime, we did something that I suspect will be familiar to anyone who has found themselves reaching for structure without quite having the tools for it. We wrote C, but we tried to make it feel more organised by prefixing functions with something class-like: Math_Min(), Math_Max(), Math_Abs(). A kind of Frankenstein-OOP - all the naming conventions, none of the actual language features. It made no real technical difference, but there was a genuine belief at the time that we were doing something cleaner. We were, in a way: the intent was right, even if the implementation was more cargo cult than computer science.

The jump to C++ eventually came, and it came - as most learning does in this industry - in whatever hours were left at the end of an already long day. It wasn't until much later, when there was finally some breathing room, that we understood how much of what we'd been doing was more expensive than it needed to be. Understanding a language deeply doesn't just make you a better developer. It makes you a faster one. The time spent learning compounds. The time not spent learning costs you forever.

The Right Balance

The Fail Fast model is not the problem. It is, in fact, a genuine innovation in how the industry de-risks investment. Building a prototype to prove game mechanics before committing to full production is simply rational. Milestone-gated funding, for all its pressures, aligns the studio's incentives with the funder's - both parties want to know as early as possible whether the game is worth building.

The problem is treating that model as the entire development philosophy rather than as a gate-management tool. Here is what the studios that balance it well actually do:

They plan for the structural sprint. Rather than hoping to find time later, they build it into the production plan from the beginning - a deliberate period after the vertical slice, before full production scale-up, to address the architecture that the prototype phase deliberately ignored.

They separate prototype code from production code. The best teams treat their prototypes as throwaway by design, keeping them in a separate branch or codebase, and making a conscious decision - at the start of production - about what gets rebuilt and what gets carried forward. Carrying prototype code forward should be an explicit choice, not a default.

They establish non-negotiables early. Performance targets, profiling cadence, minimum frame rates on minimum-spec hardware. These aren't things to think about at beta. They're constraints that shape production decisions from the day full production starts.

They invest in platform knowledge even during production. Setting aside a small allocation of each sprint - not a heroic amount, just a meaningful one - for developers to deepen their understanding of the engine and the tools. This looks, in the short term, like slower feature delivery. In the medium term, it pays back faster than almost any other investment a studio can make.

They profile continuously, not at alpha. The best-performing studios treat performance profiling as a daily practice on target hardware, not a final-stage fire drill. The earlier a performance problem is found, the cheaper it is to fix.

The goal isn't to slow down the Fail Fast model - it's to recognise that failing fast is a design philosophy for the beginning of development, not a production philosophy for the whole project. There comes a point where you've proven the game is worth building. Once that point is reached, the job changes. You're no longer failing fast. You're building something that has to last.

The teams that confuse those two modes - that keep sprinting at prototype velocity all the way through production - tend to find out the hard way that technical debt has a reckoning. And that reckoning almost always arrives at the worst possible moment: close enough to ship that it can't be fixed properly, far enough from acceptable quality that the players will make sure you know about it.

If your studio is navigating a milestone-driven project and you're not sure where the architectural risk is accumulating - or if you're already in production and suspect the prototype codebase is starting to cause problems - I work with studios at exactly this stage. Reach out, and let's look at it before it looks at you.