You want to plan your next game? Read this post first.
5 tips to save you time, money, and sanity when starting your next game project
Before we start, a quick disclaimer: I know some of you saw the title and immediately thought this was going to sound like a LinkedIn post. But I promise I’ll keep it as lighthearted as possible, ok?
For the last few weeks, I’ve been working as a freelancer, helping a motion capture and animation studio implement new project management processes. I know, fun stuff. The good part is they were open to my methods and eager to adopt ways to organize their projects, especially if that meant lowering their workload so they could focus on finding new clients and letting the team do what they do best. You know… the REAL fun stuff.
But before we started, they gave me two non-negotiable rules:
They didn’t want to be slaves to the project management tool.
The process had to be simple enough that anyone in the studio could follow it.
I couldn’t agree more. They’re still a small studio, but they’re growing fast, so their new methods needed to scale with them, especially when external partners come into the picture. And since some of their projects are related to game design, I started organizing their tools and workflows based on not only these two rules but also some key principles that I believe are crucial in game development.
As I’ve wrote in previous posts, I’ve seen indie teams, mid-sized studios, and even major publishers fall into the same planning traps that could have been avoided with a few practical steps right at the start of the project. Now that I’m having the opportunity to bring the theory to real life, I would love to share what worked with you.
So, if you’re thinking about making a game or joining the industry despite its recent rough patches, here’s five tips that can save you time, money, and maybe even your sanity.
Are you still with me? Still awake? Good! Wipe away the drool from the corner of your mouth, and let’s move on…
Tip n° 1: A game design document is worth your time
GDDs get a bad rep because some teams think they slow down creativity. I’ve saw a lot of teams calling them as creativity-killers, a tedious formality that belongs in a dusty binder.
Well, I’m not gonna lie, these people are absolutely right. But only because they’re doing GDDs wrong.
The thing is the doc will only be a useless piece of junk if you design it that way. The best GDDs aren’t carved in stone (or in a .doc relegated to a forgotten folder in your server), but living documents that evolve with your project, guiding it without boxing it in.
While working for this MoCap client, for example, I made sure to suggest a PM tool that has a wiki feature on it so everybody can update it when necessary. Having a single source of truth makes all the difference, but we all know that creative projects can change in the middle of it, so having a way to document these change requests are a godsend. Not only it makes everybody aware of what is going on with the project, but it also stopped scope creep before it even started and kept features from drifting too far away from the original vision. This way, everyone knows where to find answers, whether they're animators, programmers, or producers, and avoids those “Wait, I thought we agreed on…” moments.
And no, you don’t need a 50-page tome to guide every single decision of your project, either. Even a lean, five-page GDD that covers your core vision, key mechanics, and project scope can keep everyone rowing in the same direction, no matter the size of your game.
You must always aim to reduce bureaucracy as much as possible to ensure that the best ideas can survive the chaos of development, but don’t let your game design’s guidelines be relegated to your team’s memory. Use GDDs wisely.
Tip n° 2: Plan your tools beforehand
Nothing kills momentum faster than changing tools mid-project.
Everyone who follows the game industry has seen it happen: engines swapped halfway through development, asset pipelines rebuilt from scratch, or teams scrambling to migrate entire libraries because “we’ll figure it out later” turned into “we should’ve figured it out earlier.”
I won’t dwell too long here, since I already wrote about this kind of self-inflicted chaos in my previous piece The Price of Failure in Creative Projects. I highly recommend giving it a read (though I might be a little biased, being the author and all. You’ll be the judge).
Planning your tools early doesn’t mean locking yourself into a rigid setup forever. It means you’re picking something stable enough to last the project and making sure the whole team understands it. This foresight pays off in smoother onboarding, cleaner communication between disciplines, and fewer “why isn’t this working?” emergencies.
Think of it as building your racetrack before you roll out the cars. It’s way easier than re-paving while you’re already in the race. Nothing stops you from trying, though. Just don’t be surprised when the cars start sticking to the hot asphalt.
Tip n° 3: Have a project management system (but don’t be a slave to it)
ClickUp, Jira, Trello, Notion… there’s no shortage of project management tools that promise to solve all your problems. However none of them will solve your organization problems if your processes are unexistent to begin with.
The truth is that your tool should support your process, not the other way around.
I’ve seen teams spend more time updating their boards than actually moving their projects forward. And that’s not a problem relegated only to game studios, but especially to big tech companies. If you’re facing this kind of problem, you’re too far gone and should reconsider your approach to focus less on the management methods and more on getting things done.
In case you read the previous paragraph and had war flashbacks, here’s a suggestion for the next time you see yourself in this kind of situation: use a kanban board to keep everyone aligned and make regular checkpoints to ensure nothing slips through the cracks. If you work on site with the rest of your team, you can even use a whiteboard with post-its to make it more visual. Just remember to keep your board simple enough to give visibility, but not so much that updating it becomes a second full-time job. Also, don’t let the checkpoints occupy a significant part of your day: 15 minutes in the morning should be enough in most cases.
Another trick I’ve found works wonders is having a process keeper, someone responsible for making sure the PM tool reflects reality, not wishful thinking. They keep the board tidy, help unblock stuck tasks, and make sure what’s “done” is actually done. However, I know that this is not the reality for most small studios since nobody wants to do this “fun” stuff, so my recommendation is to keep everybody aligned on some simple good practices and make sure they stick to it.
In the end, I can sum this lesson up to the following mantra: a clean board is great, but a finished game is better.
Tip n° 4: Set Milestones with Playable Deliverables
Nothing boosts morale (or impresses a potential investor) like having something you can actually play. Even if it’s rough and the placeholder art is… well, let’s call it “abstract.”
Every milestone should aim for a playable build, not just a pile of tasks marked “done” in your project board. Games aren't like ERP systems that should solely aim to increase numbers or reduce bottlenecks. They are, first and foremost, an interactive media that needs to be experienced to be understood, and that counts not only to players, but to the development team as well. That’s why this approach of aiming to have playable builds keeps everybody motivated, helps spot design or technical issues early, and makes it easier to communicate progress to stakeholders.
Take Hand of Fate by Defiant Development, for example. Less than six months into development, they already had a playable demo ready for their Kickstarter backers. More than prove the concept, this early vertical slice helped build community trust, validate their core mechanics, and drive the entire project forward with clear direction.
The main takeaway here: playable beats perfect at every stage. A rough build will tell you more about your game than a hundred polished concept docs.
Tip n° 5: Plan for the “Unfun” Stuff
Oh, crap! We’ve reached the boring part of the list (as if the rest of it was pure fun). If you’ve made it this far, congratulations on surviving the boredom! Don’t worry, it’ll be ending soon.
I know, we all love building the exciting parts of a game: flashy mechanics, engaging level design, beautiful visuals… all that good stuff. But here’s the cold truth: every game starts as a project, and every project has baggage. Ignore that baggage, and sooner or later it will come back to bite you.
Think QA pipelines, localization, certification, and release logistics. If these are only an afterthought, you can expect delays, crunch, or worse: a launch that flops despite all your effort.
Take Cyberpunk 2077, for example — a game development disaster story I dissected here. Nearly half of its 5,381 credited team members worked on localization alone. That’s over 2,400 people translating 1.1 million words into 19 languages, recording 82,000 voice lines, and running QA across multiple regions. The game had plenty of problems already, but without early planning and coordination, even its localization could have gone off the rails. And remember: localization isn’t just translating text. It includes cultural alignment, UI adjustments, and UX tweaks. Quality testing (LQA) ensures your game plays well in every language and region. Rushing this step risks immersion, player experience, and post-launch goodwill.
Despite being the “unfun” side of game development, these steps aren’t optional. Integrate them into your timeline from day one. Because when the boring stuff is done well, everything else gets the chance to shine.
And that’s about it!
If you made it this far, thanks for sticking around! I hope you’ve pulled a few good insights from this post. Now, for those who jumped straight to the end, here’s the quick version.
My five easy-to-follow tips to start your next game project on the right foot, whether you’re aiming for a breakout indie hit or a AAA blockbuster, are:
Make an effort to create a GDD that works for your team and won’t end up in the dusty bin.
Plan your tools before production begins, especially your game engine.
Make your PM system serve your process, not the other way around.
Set milestones that deliver something playable and keep morale high.
Give the “unfun” stuff the attention it deserves from day one.
These things seem simple in theory, but often overlooked when excitement takes over. Skip any of them, and you’ll pay for it in time, money, or sanity. Typically, all three come together in a tidy bundle of crunch time and desperation. Trust me, it’s not a pretty sight.
Now I’d love to hear from you: if you’ve ever worked on a game or a software project, what’s one piece of pre-production advice you wish every team followed? Drop your thoughts in the comments. Your experience might just save someone else’s project!
Until next time, let’s keep leveling up, one boss level at a time.
Great list! When I understand how games are made, I always focus on the technical, artistic or design challenges. But, no offence, I've never considered the production or project management side of making games before, and I've never really seen it put out there either.
I could add one thing to your list, based on my experience working on (non-game) software projects: make sure your team can interact and support each other well. I once worked at an agency making e-commerce websites where the senior management insisted everyone work in a waterfall pattern: design comes first, then production, then testing, then release. They thought it would allow them to perfectly plan the production pipeline, basically turning it into a factory floor. But guess what? They never considered that testing would throw up issues that meant going all the way back to design and starting again, or that the design passed onto production wouldn't actually work. It caused chaos for us workers, but management wouldn't budge on changing or adapting.
When I finally led a project, I spent many times getting up from my desk, walking across the office to the front end team, and directly talking with them about my issues. We both then left knowing how we could move forward and fix things together. It sped up production massively, because I removed the expensive back-and-forth part that would always happen at the end. I made sure that everyone on my team would allow each other to ask for help and all pull together. Siloing people into functions I found just did not work.
I like all your points though, particularly early demonstrations of something working to see progress and make adjustments early - been in that situation too late myself!