After an extensive project, every video game designer dreams of a quick, clean project. Choose a small concept, design it with critical systems only, and ship in under a year. Easy, right?

That was the plan after Rise of Industry: our second game (Recipe for Disaster) would be a small 6–9 month project to keep things lean. Unfortunately, it spiralled into a 2.5-year marathon, filled with lessons most indies only learn the hard way.

In this breakdown I’ll cover the real production traps that derail so many indie projects: scope creep, runaway teams, process worship, and ignoring feedback – as well as how to avoid them. Whether you’re figuring out how to make a game from scratch, or you’re a veteran designer heading up a studio, these lessons apply across the board. If you want to finish a game without burning out, running out of money, or drowning in features, read on.

How Scope Creep Sneaks In

Most designers with some experience start with a vision that feels manageable. One setting, minimal systems, and a concept with a strong hook. Easy enough to finish.

But scope creep doesn’t show up waving a flag. It sneaks in disguised as “good ideas” – a layout system here, a traits system there, and maybe a full campaign mode, because why not? Before long, that lean 6–9 month sim has grown into a monster that even the best video game designer would struggle to wrangle. Which is exactly what happened to us. 

This is why all designers need to treat scope like a budget. You only get so much, and every new feature costs you. The bigger the scope, the more art, design, and tech debt you take on. Scope creep is gradual, and it always feels reasonable in the moment. The only real defense is to set hard limits early and hold the line. 

Write them down. Tape them to your monitor if you have to. Future you will thank you.

The Team Growth Trap

Here’s another misstep that studios can fall into: thinking that more people means faster progress. It feels logical, right? The game’s growing, you’re learning how to make a game with bigger systems, so why not bring in more hands to help?

Except it rarely works that way. Every new person adds overhead – meetings, dependencies, coordination. Suddenly your tiny, scrappy team that could push builds in a day now needs standups, syncs, and Slack channels just to agree on which branch to use. Instead of speeding up, everything slows to a crawl.

That’s what happened here. Each “reasonable” new feature needed a new hire. Each new hire made production heavier. Scope ballooned, the team ballooned with it, and both fed each other in a vicious cycle. Adding people without a rock-solid vision just makes the mess bigger. A growing team won’t save a moving target.

Growth without stability doesn’t accelerate you – it drags you down. Stay small until your vision and process are clear, then scale slowly and deliberately.

Process Can’t Fix a Moving Target

When things start slipping, the instinct is to reach for structure. Get a Jira board. Try Scrum. Daily standups, burndown charts, sticky notes everywhere.

None of this helps if the vision keeps shifting.

That was the trap that we fell into here: swapping production frameworks like magic potions, hoping one of them would cure the chaos. But no amount of production process can fix a moving target. If your design keeps ballooning and your tech keeps pivoting, no methodology will save you.

An indie game designer doesn’t need a perfect process – they need clarity. A stable vision, clear priorities, and the courage to cut features. Once you’ve got that, then pick the process that fits your team size and stage of development. Until then, PMP, Scrum or Jira is just window dressing.

Even the slickest production hacks won’t help if the plan keeps changing every sprint. You can’t “organise” your way out of indecision.

Feedback and Reality Checks

At some point, you’ve got to stop guessing and put the game in front of real players. That’s where the truth lives – not in your design docs, not in Jira, and not in your team meetings..

For Recipe for Disaster, Early Access became that mirror. Players told us (loudly), what worked and what didn’t. Some of it stung. Some of it was gold. The trick was learning to listen without handing them the steering wheel.

Because here’s the danger: if you obey every bit of feedback, you’ll end up with an amalgamation of systems that please no one. If you ignore it completely, you’ll miss the chance to catch flaws before they sink you. Balance gut feeling with hard data.

Eventually, reality makes the decision for you anyway – money runs out, deadlines arrive and energy dries up. That’s when Recipe for Disaster began cutting features hard, and had to be shipped. Not the dream version, but the finished one.

And here’s the thing: even the best video game designer can’t design in a vacuum. Feedback loops are what keep you honest. You need players to break your work so that you can build it back better. Feedback matters – but so does knowing when to stop. A finished game beats one being endlessly developed every single time.

Final Lessons

If you’re a beginner figuring out how to make a game, here’s my advice: start small and stay small. Ambition is great, but finishing is better.

Prototype inside strict limits. Treat scope like oxygen: ration it, or you’ll suffocate. Build with feedback in mind from day one, because emergent gameplay doesn’t appear in a vacuum – it comes from players bouncing off your systems. Prioritise cash flow so that you have the time and space to actually finish. And most importantly, give yourself permission to say “no,” even to ideas you love.

Every video game designer dreams of shipping the ultimate version of their game that exists instead of their head. Reality is different. The studios that survive are the ones who cut ruthlessly, iterate fast, and keep the lights on.

Conclusion

Running a studio isn’t the same as making games – it’s harder, messier, and often less romantic than it looks from the outside. Most indie teams underestimate that difference, and they pay for it in years of crunch, ballooning budgets and ultimately projects that never ship.

Recipe for Disaster shipped without debt, but not without scars. And that’s the point: success isn’t about chasing the dream build forever. It’s about actually finishing without burning out or going broke.

So whether you’re new to game development or a seasoned pro, remember: fun games don’t come from endless scope, bloated teams or perfect processes. They come from discipline, focus and the courage to cut.

At the end of the day, the only game that matters is the one you actually finish.