I’ve written a ton of articles about leadership, management, production, processes, operations, teambuilding, all the “boring” stuff. All meant to help studios not fail in an already brutal, hit-driven business. And then it hit me: if I were reading all this early in my career, I’d probably be drowning trying to keep up.

Understanding company incorporation isn’t make-or-break for making a wonderful video game. Neither are the production phases. Same for mentorship, culture, efficient pipelines, knowing how to prioritize. All of that matters, a lot, which is why I write about it, but none of it is make-or-break.

Being an effective leader? A good game director? Building a great team? Surely that’s critical, right? Nope. I’ve shipped games under terrible leaders, with first-time game directors and exhausted teams that disbanded right after release. Some of those launches did fine. So... also no.

That last one bugged me for a while. There has to be something that makes those launches succeed despite everything, right? Looking back, I think in every one of those cases, the people making the game understood their genre inside and out. And the game honored the genre.

That’s what saved those projects.

So the mini-epiphany I had a couple days ago is this: there’s an order of operations here. Not all the topics I write about carry the same weight, urgency or importance. And one of them absolutely towers over the others. I haven’t made that clear.

So what IS mission critical for making a wonderful video game?

Poetry

A while back, I accidentally coined a phrase I kept using over and over. I’m now going to pedantically share it with you: The best video games read like an ode to their genre.

The games that get people obsessed, the ones that enthrall you, move you, break your heart, rebuild it and leave you changed, those games have a deep, almost bone-level understanding of what makes the genre tick. And they honor it by being an ode to that space.

Let me give you a few examples.

Horror. Games like Darkwood, Outlast or Amnesia don’t rely on cheap jump scares or gore. They get, consciously or not, that buildup, anticipation, negative space, the thing you know is lurking that you can’t stop or even see... that is horror. And they build the whole experience around that incredibly understated notion.

Automation. Factorio, Satisfactory, Dyson, Shapez, they’re not great because they have little machines digging up resources to put on a conveyor belt to take to another machine thingy. That’s just a means to an end. The genre lives or dies by that Zen state, capped by a big hit of accomplishment. You get A to navigate to B so you can C, which lets you build D, which levels up E and finally, finally lets you build F. And you’re grooving. Gliding. And when you finally build F? Huge satisfaction. Yuuuuge.

Shooters. Lots of sub-genres here, boomer, tactical, hero, military, looter, so there’s variance. But I bet you won’t be surprised that at the heart of it all is... gunplay. If you don’t feel that kinesthetic pleasure of firing the weapon, the impact, the differentiation between weapons, the camera shake, the way the muzzle sound defines the scene, you’ve already lost the player. Flow, speed, level design, choke points, progression, they all matter. But they’re borderline non-factors if the gunplay sucks. That’s what games like Ultrakill, Dusk, Stalker get so right.

If you put on your best Walt Whitman hat and wrote an ode to these genres, you’d probably name-drop some of these games.

Love too

So I keep saying teams and games need to understand their genre. What I mean is that it takes years of being immersed. Hundreds, even thousands of hours of playtime to really get what makes the genre special.

You see it in a kid going absolutely nuts after scoring a pentakill on League with 5 randos in a match they were definitely going to lose. Or in that Soulsborne player (me) peeking around a corner in a catacomb with that pseudo-pixel-perfect level of paranoia in Demon’s Souls.

When you’ve been through all that, you know the genre’s expectations cold. You don’t need a game design teardown, a GDC talk, or some competitive analysis spreadsheet to understand the magic. You need time. Closeness. Passion. That’s what falling in love with a genre looks like.

If you love a genre and you’ve played the classics, you just “get it.” You develop strong opinions about what worked, what didn’t and why. Then you play your work-in-progress build and realize the feeling isn’t there, that special something the good games in this genre give you. You just know. Right there. On the spot.

You can’t fake that. At least not well enough to make a great game. Real fans of any genre just know when the people who made the game aren’t legitimately passionate about it. They-just-know. They feel it playing the game, the same way I feel it getting facerolled for the 500th time trying to solo Radahn in Elden Ring, or when I fall asleep at the keyboard on some generic, uninspired soulslike.

Every year we get a new crop of well-funded, competent games that tick every genre box on paper and still get completely ignored by players. There’s more than one reason for that. But one of them, as naive as it sounds, is that someone somewhere greenlit the game thinking of the genre as a market opportunity instead of a labor of love.

The oh so very unromantic reverse-engineering of game development poetry

So yeah, feeling those butterflies actually matters. Unfortunately, thirty people can’t build a video game on vibes alone. Vibes don’t scale. At some point you have to articulate that feeling and turn it into actual guidance a team can act on.

I think there are three things that make a genre. Any genre.

1. The emotional root

Players often say something “just feels right” without knowing why. That emotion - that’s the root of the experience.

Take horror. The root feelings are dread, vulnerability, impotence. Something dangerous is lurking in the corridors of Amnesia, and you can’t see it or stop it. That’s the whole genre right there.

Automation is order from chaos. That Zen state of building blocks that build blocks that build a self-running Factorio megabase you’re proud of, topped off by a massive hit of accomplishment.

And shooters? Kinesthetic mastery. Plain and simple. Inputs and outputs working so tightly, so symbiotically, that they feel like one continuous, ultra-satisfying motion.

Our jobs as developers is to pull these apart, label them, and put them in terms the team can act on. A solo dev or very small studio can run on intuition alone. Plenty do. Thirty people can’t. So at some point you have to make all of this explicit and actually decide what it is that really makes or breaks the game.

2. The fantasy

When you play a game, you’re always fulfilling some kind of fantasy, even if you don’t realize it.

You play The Stanley Parable or West of Loathing to be silly, laugh, break the fourth wall. You play Doom to be a total, ass-whooping badass. You play soccer games to roleplay your favorite players and dream about your team winning the Champions League.

Horror is weird because the fantasy isn’t winning. It’s surviving something stronger than you. Not beating it. Not dominating it. Surviving it. That’s why power kills the genre. Give the player mad combat powers and you’ve swapped survival fantasy for power fantasy. Might still be fun, but it’s not really horror.

In automation you’re the mastermind, the architect looking down at your sprawling, self-running creation. The one who tamed chaos one problem at a time.

The shooter fantasy is being lethal and in control. The character that does exactly what you tell it under extreme pressure. Gunplay is how that fantasy reaches your hands.

Jesse Schell wrote a great book called The Art of Game Design: A Book of Lenses. The chapter on the Lens of Fantasy has great guidance on this. Go check it out.

3. The currency

Every player trades something for something when they play. Honoring the genre means understanding what that trade is.

My favorite is automation. The player trades effort, concentration and patience for the system’s progress. The whole game is about shifting work off your hands and onto the system. You trade manual work for... yes, automation.

The tactical shooter trade is trickier to express, but you can think of it as trading cover for a shot. To shoot, you expose yourself. Exposure can kill you. Every angle you peek in Counter-Strike or Ready or Not is a bet on that trade.

In horror you trade safety for knowledge. You have to move toward the scary thing to learn what it is. Every step toward knowing is a step toward danger. That stress is the genre at its best.

Never forget your why

I’m going to go out on a limb and guess you didn’t get into game development to negotiate the darkest clauses in a term sheet with a publisher. Or to make value stream maps so you can maximize efficiency in your content-authoring pipelines. Or to write a long guide on how to merge your dev branch into Main without causing chaos.

Those things are important. That’s why I write about them. But they’re not why you do what you do. You got into game development to create incredible worlds. To awe and inspire. To make people laugh, connect and dream. To make time fly and to pull real emotions out of people.

To do that, you need to be an artist first. And to be a good artist, regardless of your discipline, you need to know your playground. In game development, that’s the genre you’re working in.

So here’s your order of operations. Way before the hiring plan, the publisher deck, or any of the other stuff I write about, ask yourself: do I actually love and understand the genre I’m about to spend years of my life on?

If yes, then everything else can be learned and fixed along the way. My newsletter will be here to help with exactly that :) But if it’s anything other than yes... maybe pump the brakes for a moment. Read some poetry. Go fall in love first. Play the classics until you truly get why the great ones are great.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

Part one of this article was about the inward work, the person, the judgment, the behaviors, the dynamics. This second part is about the structure around all that. In my experience, judgment and effective behaviors are every bit as important as you think they are, but they do need a little help to translate into action and then into value. You can know that a quick and imperfect decision might be better than a late decision and still twiddle your thumbs for a week, and you can know that your own composure and disposition determine what information reaches you and still massively lose your temper in a milestone review.

Understanding something doesn’t automatically make you do it, especially in the heat of things. What helps with that is a set of practices and rhythms that are simple and repeatable enough that you go through them even on the days you’d much rather not.

I’m putting these the article the way they’ve actually worked for me, from the week, through the month, to the quarter, together with the handful of things I recommend that you measure and the people who keep you humble and grounded, since executives, especially in smaller companies, very often have no one above them holding them to account.

The executive week

Think of the week as the time unit in which you can notice most issues and opportunities while there’s still time to act. A day is typically too short to show you anything other than the fire straight in front of you, and a month is long enough for a small unchecked problem to turn into a full-blown crisis, so the week is where I recommend concentrating the effort.

The weekly leadership meeting. I want to poke you to never skip a weekly sync with the people who lead the studio alongside you. I’m talking CTO, game director, lead audio designer, anyone in an official leadership capacity really, regardless of title, provided this group is not too large.

The common mistake here is turning this weekly sync into a status report in which everyone takes turns robotically reciting every menial thing that they did last week and/or is on their radar, which in my opinion is a pretty significant waste of time. Unless urgent, status updates can be shared in writing, where people read them in a few minutes, on their own time, or in a smaller group.

What this meeting is truly for is getting everyone on the same page and making decisions together. I structure I used before, in an admittedly much more simplified form, is EOS’s Level 10 format. The agenda is roughly: a scorecard of the week’s key numbers, a quick pass over the quarter’s priorities to mark each one on or off track, a round of short updates on the status of players and team, then the bulk of the hour is spent identifying, discussing and solving the two or three most important issues. My modification is mostly subtraction: at studio scale I just drop the parts that start to feel like bureaucracy and keep the scorecard, the priority check and the problem-solving.

The scorecard is mostly a few leading numbers that tell you if the studio is healthy. For most studios that’s runway and burn against plan, revenue trend and player retention (if you have a launched game), roadmap progress, team health and critical risks that need to be addressed (I lay out the full set under Metrics further down). So you basically read one at a time and you call it on-track or off-track with no speech attached. The point for the meeting is that everyone arrives with those numbers already updated and with a short list of issues to raise, so the hour is primarily focused on the two or three most important problems or opportunities, instead of on status. You stay on each one until it ends in a decision with clear follow ups that somebody owns. If no decision comes out of it and nobody’s name is on anything, then you probably just held a status meeting after all. If these are not pragmatic and useful, something’s wrong.

A protected block for your own work. The second thing I encourage you to do is to protect one block of time a week that belongs entirely to you. Protecting that block is one of the oldest disciplines in executive leadership. Peter Drucker called it knowing where your time goes, and treated guarding these uninterrupted blocks as probably the first habit of an effective executive.

This block of time needs defending because of where the time tends to disappear. Michael Porter and Nitin Nohria tracked this in detail and found that most of a chief executive’s time, something like seventy percent, goes into meetings, and the little time that’s left tends to get chopped into bit that are just too short to support deep, strategic thinking. Thinking really is a part of the job, as obvious as this may sound, and it just doesn’t happen in any of those five-minute breaks between calls or meetings. So if you don’t defend the block, the calendar just finds a way to claim your time.

A weekly glance at runway. There’s one number in the literature that is highly recommended to look at every week (I personally do it every two to four weeks, depending on how much money is in the bank), which is how many months of runway you have left at the rate you’re currently burning. It’s not a full review, mind you. It’s just a quick look, so the figure is present in your head, instead of in one of the dozen spreadsheets you open once a quarter and dread to no end. I’ll come back to this later on, but the gist is that it’s very important to always know where the studio stands financially.

One-on-ones with your reports. It’s also imperative that you spend part of the week with your direct reports one at a time. I’ve written before about how to have those conversations, so I’ll only say here that they’re the best early assessment you’ll get on what’s really going on at the studio, usually well before any of it reaches you through a more formal update.

Also let me briefly add that talking to every single person at the company at least once per year (within reason and provided it’s not hundreds and hundreds of people), is a really, really good idea. Anne Mulcahy from Xerox and Herb Kelleher from Southwest Airlines spent inordinate amounts of time meeting with their employees, but they got an exceptional grip on the reality on the ground of their businesses, enabling them to achieve fantastic results.

A short review of your own week. I close the week with a short review of my own, half an hour at most, spent on three concrete things: the metrics I track, the decisions I can see coming so none of them ambushes me next week, and the one thing I got wrong in the last few days. That last habit gets almost systematically skipped, but I do believe it pays off over time. Being explicit about your shortcomings week after week keeps you honest and humble, and if you do it in front of the team now and then, it teaches everyone that being wrong is just a thing you work on and correct, not something to hide.

The executive month

If the week is where you catch the more immediate problems, the month is where you step back and check that things are generally still heading in the right direction. A month is just long enough for you to be able to notice if objectives are slowly starting to veer off course (ideally before they have), and just short enough that you can still make the necessary corrections, as well as capitalize on untapped strategic opportunities before they’ve flown by.

The monthly financial review. About once a month I’d go through financial numbers like revenue, operating expenditure (and a rough breakdown of where the money is going), burn rate against planned expenditure and cash flow. Unless a game is live and you have revenue coming in, or you’re striking new deals affecting your bottom line, or you’re fundraising, this is typically pretty simple. About an hour a month to make sure that things are on track.

To the point of things being “on track”, Paul Graham’s default-alive question is a really good, really simple heuristic worth trying out. This is the question he asks: at the rate you’re spending and at the rate you’re growing, do you reach profitability on the money you already have, or will you need someone to write another check to keep the lights on? That very simple question cuts through a ton of noise and gets you to what actually determines the studio’s near-term fate, which is whether it can survive on the money it already has or not. If you remember from part one of the article, one of the three things an executive needs to ensure is that a company never runs out of money. This simple monthly question, realized through a quick runway recalculation, as mentioned above, is how you keep an eye on that goal at all times.

The game’s performance. If you have a game live, or one that launched and is still monetizing, there are a handful of metrics worth staying on top of: revenue trend (is the game making more or less money than last month?), monthly active players and their trend, refund rate month over month, store ratings (especially in relation to your last patch) and the general sentiment around the game. The finances tell you if the studio can pay the bills, but these tell you if your game is actually connecting with the people playing it, which can actually be an early financial warning. If you don’t have a somewhat intimate understanding of how players feel about the game, you’re stuck in reactive mode and you can’t effect change for your players promptly, which will sooner or later reflect on your bottom line.

The roadmap check. Once a month, step back from the week-to-week execution and look at the whole roadmap at once. The goal is not to rewrite it, since that’s more of a quarterly job, but to confirm that the milestones are still roughly aligned with the plan, that the priorities still make sense, and that nothing has slipped far enough to need a correction now instead of in three months.

The risk review. Unless you’re in the preproduction or closing phase of a game, which require a higher frequency, the month is also the right cadence for a proper look at the risk register. Weekly is too often for most risks to have changed significantly, and quarterly is just too long to effect change promptly. So once a month, go down the list: what’s the status of the action items from the last risk review, are there any new risks, have past risks been dealt with, etc. The goal is to move you from reactive to proactive, and act on risks promptly, before they’ve become major issues.

Your game and the market. A year into running a game studio, it’s very easy to start losing touch with the status of the game in development. Make absolutely no mistake about it: that’s not acceptable. You can never lose touch with the product that your company makes. So at an absolute minimum, which I deem to be once a month, play the current build the way a player would. Just play. Then spend an hour or two playing a competitor’s game, even if it’s just once, because that’s how you keep a feel for what you’re actually up against. And keep a light finger on the wider market while you’re there: the reviews of the month’s big releases, who raised money and who didn’t, what the platforms and publishers are doing and saying about where the industry is heading.

The assumptions audit. Overconfidence is one of the most costly and damaging habits an executive can have, so please consider doing a candid audit of your own assumptions. Once a month, write down what you believed a month ago that turned out to be wrong. For instance, you thought the build would be stable enough by mid-month and it wasn’t, or you thought the publisher wanted a vertical slice when what they actually wanted was two really polished levels, or you thought the team was fine and two people were actually not. Write it all down. As I mentioned in part one, the act of putting pen to paper forces a an inner dialog that just thinking-about-it doesn’t. It helps internalize things better. The discomfort of seeing the delta between what you believed and what actually happened is humbling and grounding. That’s why you do this.

A written update to investors and shareholders. On a fixed monthly schedule, it’s good hygiene to send a written update to everyone with a financial stake in the studio. The obvious outside group is your investors and the board (if you have one), but if you offered equity to employees, then it’s also the people inside the studio who have shares. Keep it transparent and short. The reason to make it a habit instead of an occasional event is that bad news ought to reach these people early and in writing, not get sprung on them live in a meeting. A steady monthly note trains them to associate your name with a calm, truthful account of where things stand, instead of with the occasional emergency. Include progress, key challenges and mitigation, personnel changes, burn rate and runway, and any other major relevant news. If you have meaningful visuals or video, link them.

An honest look at yourself. The month ends the way the week does, with one honest look at yourself. Replace the weekly assessment with a monthly assessment every four weeks and ask yourself: what did I get right, what did I get wrong, and what have I learned that should inform my decisions or behaviors next month? Write it down.

The executive quarter

The quarter is for the more structural, high-level questions that would be too disruptive to ask more often. For instance: are our strategic objectives still sound, do we have the right people in the right roles, are we making the right games? Those are big questions.

The quarterly reset. Verne Harnish thinks about the quarterly job as four decisions, people, strategy, execution and cash. I think that’s a great way of framing the quarter because it forces you to cover the whole studio, instead of just the areas most on fire this quarter. Harnish leans on the Rockefeller Habits for this, and there are two things out of that work that I want to highlight.

The first is priorities. You set three to five priorities for the studio for the quarter, and then, out of those, you pick out the single one that, if you get it right, makes the rest easier to reach. That one is your top priority for the quarter, and Harnish attaches what he calls a critical number to it, a single measurable target that tells you at the end of the three months if you hit it or not. The challenge is choosing that priority deliberately and explicitly, and ranking everything else beneath it.

And second (which in a quarterly reset actually comes before setting the new priorities), you score the quarter you just finished. You go through the priorities you set three months ago and you grade them as a binary result: which ones you hit, and which ones you missed and why. This type of scoring, this metric, helps raise the sense of urgency, and helps all relevant parties stay laser-focused on these top strategic priorities.

Capacity and competencies. Once a quarter, take a hard look at whether you have the people to build the game you’ve committed to. It typically comes down to three questions: is there enough capacity for the work ahead? Do we have the competencies needed to develop this game? And are people working where they’re strongest, or has the studio ended up organized in a way in which people spend their days on work that doesn’t play to their strengths? This isn’t headcount planning as a spreadsheet exercise. It’s not a ramp up/down plan. It’s making sure that the team is legitimately set up to do its best work, and it ties straight back to the point from part one about building on strengths instead of spreading everyone thin.

Team health survey and culture check-in. In part one I made the case for anonymous team health surveys. Twice a year is a cadence I’d recommend for running them, and the quarter in between can be for following up on the last one, which is just as important. Running a survey and not acting on the results, not closing the loop with its participants, does more harm than not doing it, because it teaches people that being honest changed absolutely nothing. So after every survey, publish the results transparently, tell the team what you learned from it and what you plan to do about it (ideally, make it a conversation with the studio), and close the loop on what you did with the action items from the last survey.

In parallel, I encourage you to sit down with the other leaders in the studio and talk candidly about the culture itself, what’s healthy, what’s slipping, what lives up to your agreed upon values, and what you’re all tolerating that you shouldn’t be. I’ve already written an article on building a healthy studio culture, so here I’ll just say that culture doesn’t maintain itself, and the quarter is a sensible cadence to check on it deliberately with the people most needed to embody it.

The technology check. You don’t need to be a technologist to run a studio, but you do need to know, at least once a quarter, that the technical foundation is still doing its job. Forget about the minutiae, the gist is this: is the engine serving the game or fighting against it? Are build systems and CI/CD fast enough that the team isn’t losing hours to them? Is the infrastructure stable? Is security actually handled instead of assumed? Is there enough automated testing that people can do things without breaking more things in the process? And is the time from idea to playable in-engine fast enough that the team can be creative, test, and iterate fast?

You’re not auditing any of this yourself. You’re just asking internal customers of the tech stack (artists, designers, game engineers), as well as the people who own it, these simple and direct questions and listening for whether the answers come back with confidence or evasiveness. What you’re protecting is the team’s ability to build the game well and fast. That’s all. Technical foundations do decay over time, they’re not perennially portable, so it’s important to stay on top of it.

The launch window. If you’re heading toward a release, the quarter is where you keep an eye on when you’re planning to ship relative to everything else coming out. You never want to launch into a GTA, whether you’re a direct competitor or not, or whatever the cultural juggernaut of that month happens to be, and you want to stay sufficiently aware of the release calendar to move if the window you picked turns out to be bad business for you. This isn’t a decision you make once and forget. The competitive landscape changes, big releases or direct competitor releases slide into or out of your launch window, and revisiting the tradeoffs every quarter can potentially help you pivot with as little pain as possible.

The board meeting. Mostly for chief executives, since non-chief executives don’t necessarily sit in board meetings unless they’re pulled in for a specific topic. Unlike the weekly leadership meeting, this is not so much a problem-solving type of meeting, but more of a traditional report to the board. You update them on the state of the business, answer their questions, and part of the board’s job is to hold the CEO (maybe that’s you), accountable. That distinction changes how you prepare.

Send the numbers out ahead of time, five to seven days is a good norm, so the hour with the board isn’t spent reading. A useful board pack covers the financials (burn, runway, revenue against plan), a handful of critical studio metrics (studio objectives progress from last quarter, game performance, personnel), major risks and proposed mitigation, the two or three decisions you actually need the board’s input on, each with your recommendation attached, and what the board should expect to see next quarter. The meeting itself is then for those salient items and a real discussion about them, not a status recital of countless menial tasks and metrics. The investors worth having want to think alongside you, not just sit through an update they could have read on their own, so I recommend you bring them the things you’re actually stuck on, the burn, a key hire, a decision you’re struggling with, and leverage their capabilities.

One last thing, tedious but non-negotiable. Board meetings need minutes, and in most jurisdictions that’s a legal requirement. So run the meeting with a real agenda, and have someone take proper minutes (I suppose AI bot will do just fine) that record the decisions and the action items, then circulate them afterward. Good structure and good logging protect you and the studio, and they make the next board meeting start from a clear record instead of a foggy memory of what everyone agreed to.

The all-hands. Once a quarter, get the whole team in one place, virtual or physical, and tell them earnestly where the studio is at: how the last quarter went against what you’d set out to do, what the priorities are for the next one, salient and relevant updates, and just generally an honest account of where things stand, including whatever isn’t going well. The urge under pressure is to protect the team from bad news, but in my experience, if what the team only ever gets is a rehearsed dog and pony show about how everything is great, they understandably stop trusting the all-hands. The best all-hands I’ve had were conversational and constructive, and I think that’s best achieved through honesty and humility in your communication.

Warming the outside relationships. Once a quarter, deliberately reach out to the people outside the studio you may depend on later, before you actually need anything from them. Your publisher, your investors, the partners you rely on, a few other studio leaders, the journalists who cover your kind of game, the platform holders. Not with an ask, just to keep the relationship alive and current. Relationships you only ever touch when you need something have a way of going cold exactly when you need them most. The quarter is a reasonable cadence to make sure someone you might have to call in a crisis has heard from you recently for a good reason.

The project kill-review. The quarter is also the natural place for a review about continuing or stopping the project. Once again, I’ve made a full case for scheduling those before you need them in a past article, so I’ll keep it short here. If your project kill-review only happens when things are on fire, you’re already late and your chances of effecting change are going to be diminished. Set the criteria while you can still think clearly and give someone with nothing sunk into the game a seat at the table, because you greenlit the project and championed it through every rough patch, which makes you close to the last person who should be assessing the playtest results alone.

A read on your own performance. Once a quarter I’d get an honest assessment on myself, separate from the studio. In the first part of the article I floated the notion that you can’t produce a fair assessment of your own performance from inside your own head. So unlike the weekly and monthly self-review, this is where you go and get one from outside, whether that’s a structured round of feedback from the people you work with or an hour with an advisor whose whole job is to tell you the truth. Put it on the calendar like everything else.

Metrics

Many executives track either too many things or the wrong ones. What you need is a handful of really strong, really meaningful metrics that tell you what’s coming, good or bad, while you still have room to do something about it.

Let me start first with a common mistake, which is tracking a short list of metrics that somehow all point at the same thing. Peter Drucker made this argument decades ago: a company that measures only its profit is steering half-blind, because profit is a result, it’s an outcome of how the business performs in a handful of other areas, not a lever you can pull directly. He argued that a business has to set objectives across several of those levers, precisely so that no single number can hide trouble building somewhere else. For a game studio, the impulse would be to track the most obvious metrics, which are the money and the schedule, but the real value is in tracking the things that inform money and schedule, like the state of the game, player sentiment, team health, team effectiveness, etc.

A distinction to bear in mind is between lagging and leading metrics. The lagging kind, revenue, shipped milestones, players who’ve already left, tell you what happened once it’s too late to do anything about it. They’re still worthwhile, but they’re not immediately actionable. The leading kind tell you what’s about to happen, and while not all the metrics below are leading, that’s where I argue the short list should concentrate:

1. Runway, in months. We touched on this one already. The number of months of money you have left at the current burn, assuming no new revenue comes in. Everything else on this list is open to some argument, but this one is a straight calculation, and not knowing it at any given moment is close to negligence.

2. Burn against plan. Your actual monthly spend set against what you budgeted, as a variance in both dollars and percent. Runway tells you how much time you have, and burn against plan tells you if that number is about to change, since an unplanned climb in spending is usually the earliest warning available.

3. Revenue trend. The absolute number is one thing, but the trend month over month, as a percentage, tells you a lot more, because a live game that slides ten percent every month, as opposed to a game that holds steady, completely changes the future strategy of the studio. Track the direction, not just the snapshot. Use it to foster intelligent conversations.

4. Player retention and sentiment. For a game already in the market, that’s retention (how many players come back on day one, day seven and day thirty), your store rating or percent-positive reviews and the refund rate, as well as a qualitative assessment of reviews and commentary on social media. For a game still in development, it’s your quantified playtest results: the share of testers who would play again, where they drop off, how they score the fun. The sooner you notice the trend changing, the sooner you can get in gear and proactively add value.

5. Scope against the plan. How much scope has been added since you agreed what you were building, tracked as a concrete number in staff days. When it climbs, someone has been saying yes, and putting a figure on it turns a vague sense of bloat into a decision you can actually make.

6. Team health. Take the anonymous survey from the quarterly rhythm and treat its score as a number you track over time, alongside regretted attrition, meaning how many of the people you could least afford to lose actually left. The research on why executives derail puts the inability to build and keep a team right at the top of the list, so this is one of the most serious numbers on the whole board, not a soft one. This is a lagging indicator, but you want to know as fast as possible and be deliberate about next steps.

The last two are about you instead of the studio.

7. Your calendar against your priorities. How closely the week you just had matches the priorities you claim to have. Pull up last week and count how many hours went to the two or three things you keep saying are the most important, and if you find dissonance there, treat it as data and make concerted adjustments to maximize your use of time in relation to your priorities.

8. Proactive time against reactive time. The ratio of time you spent driving your own agenda to time you spent reacting to whatever came at you. Porter and Nohria found that even the best chief executives lose more of the week to reacting than they’d like to admit. You won’t get that ratio perfect either, but you should at least know roughly what it is. Try to do some root-cause analysis, look for small wins to get you as much as possible from reactive to proactive.

What not to track. In a nutshell: menial, tactical metrics. Team velocity, number of bugs, performance, outsourcer asset pass rate, etc. Those are all important things, but this isn’t your job, this isn’t your domain as an executive. Empower your people to lead and manage those tactics and hold them accountable for results, but do not indulge in taking ownership for these things or you’ll never have time to be an effective executive.

Accountability when there’s no boss

In almost every studio, people have someone who sets their expectations and has an accountability conversation when those fall short. But for many executives in the industry, especially in the indie space where so many people are founders, there’s just no boss above you. That’s probably the freedom people start companies to get, which is great, but it’s also a challenge, because with nothing or no one external to answer to, even disciplined people tend to slide toward what’s comfortable and away from what’s needed. So you have to build the accountability that your circumstances can’t provide you.

A few things that work, in my experience.

Candid peers. A small group of very senior colleagues you trust. Two or three people who understand the job and have your permission to ask you challenging questions, like what it is that you’re avoiding, what decision you’ve been idling on, what you’re pretending is fine when in reality it isn’t, that kind of stuff. One good hour a month with one of them can be incredibly valuable.

An outside voice. An outside voice with nothing at stake in your studio, which might be a coach, a fractional executive or an advisor. This is the same person I argued for putting in the kill-review, the one with nothing to lose who can look at hard evidence clearly, but this time around, you’re asking them to assess your own performance. Most executives, especially founders, bring this person in after something has already broken. That’s a bit late. I’d suggest bringing them in while things are calm, so the relationship is already there before you need it.

Public commitments to the team. These are commitments you make transparently and explicitly to your team and that you follow up on when you said you would. It can be about a hiring effort that you’re spearheading, a strategic decision, a high-level revenue update for the team, whatever. Almost invariably, your team is your studio’s secret sauce, so if you fall short on your commitments to them, it would behoove you to own up to that with clarity, maturity, remediation plans and a Kaizen mindset.

How you react to bad news. Accountability only works if the truth actually reaches you, and how you react when someone comes to you with something bad, especially if it’s about you, determines whether challenges keep reaching you or dry up. The executives that handle this well treat problems as mere information, not something to punish. That idea is at the heart of the Toyota story I wrote about a while back.

Why do all this?

So why put yourself through all of this, the meetings, the reviews, the candid audits, week after week, month after month? Well, it’s because after a year of enacting these rhythms, the studio is a fundamentally different place from the one you started with.

The studio starts making most of its own decisions without routing them through you, because the people closest to each challenge have the authority to manage it as they see fit and they’ve learned you won’t come back around later and reverse their decisions. Problems reach you earlier, while they’re still small, partly because the rhythm helps create regular expected moments to raise them and partly because you’ve made it safe for people to be honest about challenges. And to boot, you get some protected time to think again.

What unfortunately doesn’t change is how challenging and demanding it can be to be an executive in the games industry. You’re still tired. The weight feels enormous at times, and most of it is yours alone to carry, because many of the things you do cannot be delegated, and the loneliness of the role, especially if you’re a chief executive, never fully goes away. You still have taxing conversations and hard decisions, and at times, some of them keep you awake at night. None of what I’ve been writing about makes the job easy, but hopefully it does make it possible to keep doing it, and doing it well, without burning yourself out.

If you spend say, a year training yourself diligently on how to be a better executive, most of the change will be largely invisible from the outside. The people around you might not be able to point to what’s different. They’ll just feel that the studio is steadier, that decisions get made promptly and problems get caught early and that the founder is no longer the giant bottleneck they used to be. Another year or two on from there you might look back and say to yourself: “Oh, wow! We just had a really good year.” And with a little bit of luck, you might just be able to connect the dots and realize that effective executive leadership might have contributed a little something to that outcome.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

I’ve only been in executive roles for a few years, so my experience is limited. But I wanted to write about this topic, and provide some guidance, for three reasons. First is that I had valuable hits and misses in my journey towards being a hopefully decent executive, and I think I have something to contribute from those moments of success and failure. Second is that I had the benefit of being able to learn from good and bad executives, so that also provided me with valuable context and benchmarks. And third is that there’s a dearth of literature and guidance out there on how to be a better executive in games. And if the past few years have taught us anything, it should be that we do not do a great job at the executive level in the games industry.

Part of the reason for that, I suspect, is that you can cross into executive work without quite really noticing that it’s happened or what it really entails. At the indie level, it can be both unexpected and fast. You most likely don’t set out to run a game company, you set out to make a cool game, which is exactly what you’re good at, and which is largely the reason people were willing to join you in a game studio in the first place. Then suddenly the game does well enough that you raise a bit of money and start hiring to keep up and to scale your studio to do potentially cooler things. And a year or so later you look up and you realize that there are thirty or forty people who desperately need things from you, but you’re still spending your best hours in Maya, or Unreal, or Visual Studio, because that’s what you know how to do well and it’s where you feel most useful.

The problem is that contributing to the build is no longer your job, or at least no longer your main job. It kind of changed around the point the team got too big for you to keep your hands on everything. What the studio needs from you now is to be the executive that enables the entire studio to thrive. You’re still a great artist, or designer, or programmer, but your individual contribution, no matter how good, pales in comparison to the impact that is needed from you at the executive level.

So this is part one of two articles about this new job of being an executive. Even though the overlap between being an effective executive and being a good leader is massive, I won’t go super-deep into leadership, first because I've written about that already, but also because what we don’t talk about nearly enough is how to run a studio, how to be an effective leader specifically at the executive level. So let’s do that.

What being an executive actually means

An executive is someone accountable for the performance of a whole system, not just their own part of it. In a studio, that means you own whether the entire organization produces good work or not, instead of how much you personally produce. Your job is to build and perennially strengthen the conditions in which everybody else can do their best work and get results. This isn’t tied to a title, and it isn’t only about chief executives. A studio head, a game director, a chief marketing officer, anyone accountable for an organization, or a subset of an organization and the people inside it, is doing executive work.

Andy Grove, former CEO of Intel, made the underlying point decades ago in High Output Management: a manager’s real output is the output of the teams they lead and influence, not the sum of what they produce with their own two hands. Your craft, however good it is, stops being the thing that gets measured once you’re the one running the studio. What gets measured now is if the studio as a whole is making good video games or not.

The core duties

There are two useful ways to frame what an executive is actually on the hook for, and I think they actually work well together.

The first is a short list of duties you can’t hand over to anyone else. According to Fred Wilson, who has funded and sat on the boards of many companies, a chief executive really does three things:

1. Define the vision and keep communicating it to everyone who needs to hear it

2. Recruit and keep the best people you can

3. Make sure the organization never runs out of money

(I personally believe that a chief executive also needs to be accountable for ensuring that people are empowered to get things done, not just that they’re there, but that’s just me.)

You may or may not be a chief executive, and depending on your role and the stage of the studio the exact emphasis is likely to change, but the gist is solid: vision, (empowered) people, cash. Two of the three face inward, into the studio, which are the vision and the people. The third, cash, faces outward, at investors, publishers, platforms, players and whoever it is that signs the checks that keep the lights on.

The other way to think about what an executive does is a set of domains that you have to keep in balance, and that you just cannot neglect for long. Martijn van Zwieten, who coaches game studio founders (arguably my competition, so please don’t tell him I sent you), thinks of studio leadership responsibility as four areas: yourself, your team, your clients or players, the wider community you have some stake in. This is a really sensible and pragmatic model.

These two ways of thinking about executives in our industry overlap a little, which is fine. Wilson’s three are the duties only you can shoulder. Van Zwieten’s four are the domains you have to keep an eye on so that none of them collapses while you’re busy with the others.

Once you accept that the job is mostly those duties, not merging your dev branch into Main, a surprising amount of your calendar frees up. You don’t need to sit in every creative review to own vision, and you don’t need to read every clause of every freelancer contract to own legal or finance. What you can’t do is hand any of the core duties to someone else. One common way founders come undone, myself included in my journey, is pouring their hours into something else, usually the craft they came up in, while one of the real duties falls through the cracks.

Start with what the studio needs

Before talking about any of the behaviors below, there’s a well-known habit underpinning all of them. Peter Drucker, widely understood to be the father of modern management, put it like this: effective executives start from what the situation actually needs, not from what they personally want to do. Drucker presented this as two questions: “what needs to be done?” and, separately, “what is right for the enterprise?” Neither of those is “what do I feel like working on,” and neither is “what would make me look good.”

For a gaming entrepreneur this is actually harder than it sounds, because what you want to do (the craft you came from and in which you feel most comfortable) and what needs doing (running the studio) are almost always different things. And the wanting tends to win out. So it has to become a deliberate habit.

At the start of anything, a quarter, a project, even a week, it’s useful to ask yourself what the studio actually needs from you right now. Sometimes that’s a hard hiring decision that you’ve been avoiding, sometimes it’s working with your game director and EP to cut a feature that the team loves, sometimes it’s a fundraising push that you just dread having to even think about. It’s almost never the task that happens to be the most comfortable one for you.

Then what you do is you check your answer against what’s right for the whole studio, not what’s right for you or your co-founder or the loudest person in the last meeting. Drucker’s point was that the executive is the one person whose actual job is the good of the entire enterprise, so when the convenient answer serves you but not the studio, that’s the tell that you’re answering the wrong question.

And none of this works if you aren’t honest about your goals to begin with. If you don’t really know what the studio is trying to become over the next couple of years, “what needs to be done” has no answer, and then you fall back on whatever is loudest or whatever you enjoy.

What effective executives do

The study of what makes an executive effective goes back to Peter Drucker’s 1966 The Effective Executive, still a foundational must-read. Drucker’s core claim was that effectiveness is a discipline you learn rather than a gift you’re born with, and he boiled it down to a handful of habits: manage your time, focus on the contribution you’re there to make, build on people’s strengths, concentrate on the few things that make the biggest difference and decide in a systematic way.

Some sixty years later, the firm ghSMART worked through detailed assessments of seventeen thousand executives and largely confirmed what Drucker put forth, while also shedding some additional light: the strongest performers decided fast, engaged people well, adapted early and delivered reliably. Charisma, confidence and an impressive pedigree barely predicted anything.

The sections below bring the two together, Drucker’s habits and ghSMART’s behaviors, into a working set for a game studio, along with a few things from my experience, watching this go right and wrong up close. I also include practical and actionable ways to embody these behaviors.

1. Managing your emotional state

Your emotional state sets the tone for the studio, whether you want it to or not. If you catastrophize when a milestone slips, the team catastrophizes with you. There’s a practical reason to keep yourself in check that has nothing to do with being pleasant: if you react badly to bad news, people stop bringing you bad news, and you end up steering the studio based on erroneous or simply missing information. The good news is that this is a skill, not a personality trait, and a few concrete habits go a long way.

Put a beat between the news and your reaction. When something bad reaches you, your first move should be more of a question than a verdict. “Walk me through what happened” nets you a few seconds to cool down, and it tells the person you want to understand the problem instead of finding someone to blame. Difficult Conversations and Crucial Conversations are two books I cannot recommend enough for this.

Reward the messenger, especially when the message is bad. Thank people, out loud, for flagging things early. The first time someone gets punished for raising a problem, consciously or unconsciously, everyone else determines that maybe sharing the bad news that they have to share is probably best left for another time, preferably way, way down the road.

Keep your own stress off the team. You are allowed to be worried, and you need somewhere to put that worry that isn’t the people who work for you: a co-founder, a peer at another studio, a coach, even a notebook or a boxing bag. The team can handle the truth about the project, but they really shouldn’t have to manage your anxiety on top of their own.

Learn the tells you leak without even noticing. Pissy one-line replies, a sudden jump in how often you check in, questions that sound like interrogations. You’re unlikely to catch these in yourself, so consider asking someone you trust to tell you when you’re doing it. The “Getting a candid assessment on yourself” section below expounds on this.

And none of this is about feeling calm inside, mind you. You can be deeply distraught and still be the steadiest presence on the team. The whole point is to establish a buffer between emotion and behavior, to not transmit the panic, so the information keeps reaching the one person who most needs an accurate picture, which is you, the executive.

2. Being focused

Attention is a scarce resource, both yours and the team’s, and concentrating that attention is what Drucker meant when he said first things first. Deciding what not to do, which opportunities to pass on, which fires to leave burning, is one of the most important things an executive does.

A few concrete practices that can help here:

Keep an explicit, short list of the studio’s priorities, no more than a handful, with one that outranks the rest. Every new request, yours or anyone else’s, gets checked against that list. If it doesn’t serve a priority, the candid answer is no, or at least not now.

Treat your list as a backlog. For every yes, be explicit about what it displaces. What’s the opportunity-cost of accepting a new objective? Saying yes to a new game feature is always saying no to something else, because time and money are finite. So be transparent about it: “if we build this, we’re not building that.” “If I take on this executive task, what am I not going to be able to do instead?” That keeps you from ever inadvertently pretending the extra work is free.

Get good at saying no while keeping the door open. “Not this milestone.” “Not until the vertical slice is done.” And provide context, because after collaboratively assessing the problem with the team, people can absolutely accept a constraint they understand. What they tend to resent is constraints that look arbitrary.

Protect the team’s focus, not only your own. A large part of the job is absorbing yourself the drive-by requests and the pivot-of-the-week, so they never reach the people trying to actually build the game. That focus needs to be protected at all costs.

And own scope concertedly. When a game grows past what you agreed to build, someone actually made that decision, either you or someone reporting into you, by saying yes one feature at a time. Track what’s being added and make the call deliberately, rather than discovering six months later that the game doubled in size while no one was watching.

3. Making decisions effectively and fast

There are two parts to this. The first is clarity about who decides what. If every call routes to you, you become the bottleneck and the whole studio slows down, so part of the job is making sure each kind of decision has a clear owner who isn’t always you. The second is how you handle the calls that really are yours. The ghSMART data found that strong executives decide with speed and conviction. They aren’t reckless, they’ve simply accepted that a decision made and then corrected usually beats one deferred while everyone waits for information that never quite arrives. No to analysis paralysis.

Some practical tips:

Codify who owns which decisions. For the recurring kinds, creative direction, hiring, spending above some threshold, publisher concessions, put one name next to each as the person who decides, and note who advises and who just needs to be told. A single page, something like a RACI chart, is enough. This is the thing that stops everything from funneling back to you and turning you into a bottleneck.

Then actually let people decide, and live with the result even when it isn’t the call you’d have made. If you override a decision you handed off, everyone learns that the “decision” was really just a recommendation, and it all routes back to you again. This is a remarkably pervasive mistake at the executive level.

For your own calls, decide in advance how much information is enough. Most decisions can be made well at around seventy percent of what you wish you knew, and waiting for ninety usually costs more than being wrong would have. Alacrity and momentum are hard to measure but they’re real and they matter.

Separate the reversible decisions from the ones you can’t take back. Most are reversible, so make those fast and fix them if they turn out wrong. The few that aren’t, a senior hire, a platform commitment, spending a big chunk of the runway, are the ones to slow down on and make really sure you get right.

Draw out some disagreement before you commit. Drucker’s rule was that good decisions come from dissent, not consensus, so if everyone falls in line right away, you probably haven’t tested the decision as well or as much as you could. On anything important and within reason, try to make sure that someone has actually argued the other side before you lock it in.

And decide out loud, with your reasoning attached, so people can act on it and so a bad call comes to light quickly. State what would change your mind, then go.

4. Achieving alignment and buy-in

ghSMART calls this “engaging for impact”. It means understanding what each person and each stakeholder actually needs, and then helping them align and pulling them toward the same goal, instead of issuing decisions and hoping people fall in line. In a game studio, a team that helps shape the plan ends up owning it, while a team that is handed down a plan will just comply with it, and compliance tends to fall apart the minute things get hard. And things get hard right quick in game development.

A few more possible actionable approaches to achieve that:

Bring people in before the decision is final, while their input can still change something. People commit to what they helped build, and they can always tell the difference between being consulted for real and being handed a decision that was already made.

Explain the why far more often than feels necessary. What’s obvious to you, because you’ve been thinking about it non-stop for months, might be new to everyone else. Assume you’re going to have to repeat the reasoning behind a direction many more times than seems reasonable. The day you’re sick of repeating yourself is probably the day the team starts to absorb it. If you have doubts about this one, Start with Why is an excellent book for any leader.

Connect the studio’s goals to what each person actually cares about. Alignment is everyone seeing the same plan, which is different from everyone agreeing with it, or disagreeing but committing to that plan. Agreement is very closely tied to individual wants and needs. Seek to understand what individually drives your people so that you can help them commit to the strategy.

Check for real buy-in instead of nodding. Ask people to paraphrase the plan back in their own words, or to lay out the risks they see in it. Celebrate challenges to the plan. Silence in a meeting rarely means agreement. More often than not it means the disagreement will only materialize by the watercooler.

And when you can’t take someone’s input, close the loop and tell them why. Being overruled with a reason, with context, feels completely different from being ignored, and it’s the difference between someone who stays bought in and someone who checks out.

5. Establishing long-term and short-term thinking

This is what ghSMART refers to as “adaptability behavior”, which really comes down to thinking about two time horizons at once: steering toward where the studio needs to be in a year or two, while also responding to what’s actually changing this week or this month. Ben Horowitz, a well-known venture investor and former founder, has a useful shorthand for the switch between the two that he calls peacetime and wartime. The mindset that works in a boom can sink you in a downturn, and the games industry is firmly in a downturn in 2026.

In practice, having that dual-timeline view comes down to a few moves:

Protect regular time for the long view, or the urgent, the fires, the problem du jour will take up all of it. If left unattended, a week tends to fill up entirely with this month’s crises, and you’re left with not time to ask the strategic multi-year questions, let alone answer them. The operating rhythm in part two is largely a way to force that time onto the calendar.

Build early-warning habits for the short term. Try to keep an eye on the leading indicators and stay close to the people doing the work, so you catch issues while they’re still small and cheap to deal with, rather than after they’ve forced your hand. Put simply: talk to your people, play the latest build with some regularity, join in on the occasional sprint review or risk management sync.

Be explicit about which mode you’re in, and let the team know. Wartime, a cash crunch or a launch going sideways, calls for fewer priorities, faster calls and more direct leadership. Peacetime allows exploration, real consensus and longer bets. Problems emerge from being in the wrong mode for the moment, and in my experience, that very often comes from assuming a peacetime mode while the studio is decidedly at war.

6. Being exceptionally reliable

Reliability is the least fancy of the behaviors ghSMART flagged, and I’d be surprised if it’s not one of the most underrated. It just means doing what you said you’d do, roughly when you said you’d do it. Modeling behavior is just plain old good leadership and it sounds almost too basic to write about, but it’s a good chunk of what earns you the trust of senior people, every one of whom has worked for a boss who talked the talk but seldom walked the walk.

So being reliable is mostly unglamorous follow-through:

Promise a touch less than you think you can do, then deliver on it. Under pressure the urge is to promise everything so the discomfort in the meeting goes away. Reliability comes from committing to what you can actually deliver, even if the more measured promise is actually harder in the moment.

Track your own commitments the way you track the team’s. Write down what you said you’d do and by when, then close the loop on each. If the things you promise routinely evaporate, the team notices, and they slowly stop counting on your word.

You’ll still miss things sometimes. What good reliability looks like in this case is simply to flag the miss the moment you see it coming, with a new date and with context, so it never comes as a surprise to anyone.

7. Building on strengths

Effective executives lean on strengths, one of Drucker’s oldest rules, instead of spending their energy trying to be “just adequate” at everything. There are, again, two levels to this.

The first is your own strengths as an executive. Work out the few things that you do that only you can do well, and spend your time there. The common mistake here is trying to become a well-rounded executive who is passable at finance, negotiation, org design, etc. You’ll do all of it at a C-minus level and have no time left for the things you’re actually great at. It’s far better to be excellent at your two or three strongest competencies and cover the rest with people who are strong where you’re weak, whether that’s a hire, a fractional finance person or an advisor. Not my favorite, but a popular and relevant book that you may want to check out is Strengths Finder 2.0.

The second is the studio’s strengths. Pick the projects and the bets that play to what your team is distinctly good at, rather than chasing a market that would need capabilities you don’t have and can’t build in time. If your team’s real edge is art direction and game feel, that’s the kind of game you should be making, not the one everyone else happens to be chasing this year.

Neither of these works without an honest assessment of what your strengths actually are, which leads to the next section.

8. Getting a candid assessment on yourself

Most people can’t see themselves accurately, and the more senior you are, the worse it tends to get. Tasha Eurich’s research found that about 95 percent of people believe they’re self-aware, while only 10 to 15 percent actually are, and, worse for you specifically, that experience and power tend to erode self-awareness instead of building it. So the more the studio defers to your seniority, the less reliable your own self-awareness becomes.

She also found that introspection on its own doesn’t necessarily fix this. Sitting and reflecting tends to make you more confident about yourself without making you any more accurate, so while reflection is valuable and important, you can’t just think your way to a true picture. It has to come partly from outside of you, which means you have to go and get it.

There are a few practical ways to do that.

Build a small set of people who will tell you the truth, and ask them specific questions. Instead of “how am I doing,” ask “what’s the one thing I do that gets in the way?” or “where am I the bottleneck?” Keep in mind that a vague question gets a vague, polite answer that helps no one. Reward their courage for giving it to you straight with a thank you, humility and follow through.

Run upward feedback now and then, a proper 360, or an anonymous round once the studio is big enough. Structured, anonymous feedback surfaces the things people won’t say to your face. I’m fond of anonymous, bi-annual (2x/year) team health surveys for larger teams.

Be very mindful about the absence of pushback. This is a nearly airtight warning sign: if pushback dries up entirely, please don’t interpret that as a sign that you’ve become right about everything. It more often than not means that you’ve made it painful and/or costly to disagree with you, which loops straight back to managing your own reactions.

9. Disposition

Your temperament, your attitude, they matter so much more than you think. They affect how people perceive you, how much they want to work with you, trust you, and more. Your disposition to people and to circumstances completely affects how empowered you’re going to be to positively affect change in the organization.

These last three recommendations come less from the ghSMART data and more from watching which executives people actually want to work for, though Drucker and the HBR distillation of his work point to all of them.

Lead with opportunities, not problems. Effective executives spend their best attention on the opportunities in front of the studio, not only on the fires. Problems still have to be handled, but crisis is opportunity and a studio run entirely on problem-solving, on reactive mode, never quite gets ahead of anything. When you set priorities, put at least one genuine opportunity above the firefighting.

Say “we,” not “I.” The executives people trust tend to talk about the studio’s wins as the team’s and its failures as their own. It’s a small habit but it has a very large effect: “we shipped this” and “I got that call wrong” build far more trust than the other way around. Let the words inform your intrinsic disposition.

Listen first, speak last. This is the single most useful habit on the list and oh so very often the hardest for a studio founder operating at the executive level. If you say what you think at the start of a discussion, everyone adjusts to it and you stop hearing what they actually believe. You can bias the entire studio with one sentence, potentially to the detriment of the team, the game, and their future. Ask questions, let the discussion run, then give your own view at the end. You get better information and better decisions, and it once again ties straight back to keeping honest information flowing to you.

How executives grow and learn

Experience on its own isn’t necessarily going to make you a better executive. Five years of running a studio can be five years of actually getting better, or it can be one mediocre year repeated five times. So it matters how deliberate you are in learning from what happens to you and around you.

These are a few of the things that some of the better executives I’ve had the privilege of working for and learning from, did in what seems to me like a concerted manner.

They had some form of structured reflection. Not journaling as therapy, but as a regular, deliberate review: what did I decide this month, what actually happened, what would I do differently next time. Just like with a non-professional form of journaling, the act of putting pen to paper and writing these things forces a certain level of precision and inner dialog that just thinking-about-it doesn’t. I believe once a month is plenty.

They seemed to have gone looking for evidence that they were wrong. Many executives suffer from confirmation bias, which is searching for validation that what you believe is correct. The counter-habit is to deliberately ask questions to humbly challenge your perspective, like “what evidence do I have that contradicts my viewpoint?”, “how might someone with an opposing perspective interpret this situation?”, or “what assumptions am I making that could be incorrect?”.

They had a small clique they could trust and rely on. I don’t mean a networking group, but just two or three people who run gaming companies, or were in other executive roles, and had permission to ask difficult questions and give critical feedback. One candid conversation every few weeks with someone you trust and who understands the job can help keep you honest, humble and on your toes.

And they actively learned from the executives they’ve worked under, the good ones and the bad ones. Every executive boss you’ve ever had taught you something, sometimes what to do and just as often what never ever to do. It all counts, it all adds up to your growth and I strongly suggest writing these things down and keeping a logbook of lessons learned. It pays off down the line.

Don’t overwhelm yourself

As you can see, being an effective executive is a lot. A lifetime worth of a lot. I’ve said in the past that leadership is not a destination, it’s a journey. There’s no end in sight. You can spend your entire career trying to grow and improve as a leader. It’s really about self-assessing, being humble, internalizing lessons, asking for help, finding your own courage, finding your own leadership style, your own mojo, and lifting everyone around you to the best of your ability. You’re never done doing this. No one is.

Being an effective executive is no different. You may be a great executive today, but that doesn’t mean you will be tomorrow, or that new challenges won’t put your strengths to the test, or that you can’t continue to evolve as a leader of gaming organizations, whether they’re five people or five thousand. And maybe you’re not a good executive today and you can tell. That’s OK. It really is. No one is born knowing these things. Like I said, it’s a growth journey you embark upon.

So pour yourself a cup of tea, be kind to yourself, make a plan with the competencies that you think your game company would most benefit from you having, and start chipping away at them. This can be an incredibly rewarding experience. Don’t let the volume of things to learn overwhelm you. Let it drive you.

That’s the inward first part of the article, the judgment and the person doing it. Part two is the more outward, practical half: the weekly, monthly and quarterly rhythms that keep a studio on track, the handful of metrics you should actually be tracking, plus how to hold yourself accountable when you have no boss to do it for you.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

Sooner or later someone with money looks at your studio and asks themselves: “Do we want to open our checkbook for this?”. That might be a publisher checking out your latest build to determine whether to fund the project or not, or an angel investor reading your deck and asking questions about traction, or maybe further down the road, a larger company evaluating putting on an offer to acquire your studio. That’s due diligence.

However friendly the chat is, the person on the other end is doing something very concrete and highly calculated: they’re putting a price tag on the risk associated with this potential investment. They already have some interest, which is why they’re conducting due diligence, so now they’re hunting for a reason to offer you terms more beneficial to them, or the reason to simply offer you less, or to pass altogether.

It’s useful to know that no matter the circumstance, roughly the same lenses tend to be used in the evaluation. And you know what? There’s absolutely nothing stopping you from proactively leveraging those lenses by turning them on your own studio and making sure that if those conversations with prospective investors were to happen tomorrow, you’re ready for them.

I posit you should do that self-assessment for two reasons. First, you’re the only one who can fix what the lenses uncover. When investors find significant problems, more often than not what happens is that they lean hard on flowery euphemisms, and walk away leaving no actionable feedback or value behind. So it’s entirely up to you to affect change.

And second, you’re perhaps the person with the least perspective and the one most emotionally compromised to effectively introspect and evaluate the state of the studio. It’s your studio, you love it, and you’ve been in the trenches too long to evaluate dispassionately. So as counterintuitive as this may sound, this is exactly the reason why you should self-assess. If you’re going to raise funds from anyone, the more you see what they see, no matter how hard it is for you to accomplish that, the more empowered you will be.

Due diligence can be fairly straightforward or inordinately complex. This guide is not exhaustive by any means, but it should give you a solid idea of what the key areas of evaluation are. I go through seven lenses: the game itself, the team, the people leading them, the culture they work in, the technology under the hood, the systems that turn effort into shipped work and the money keeping the lights on.

1. The game itself

Assuming, for simplicity’s sake that you’re a one-game studio, what a publisher or prospective investor checks first, and weighs highest, is of course the actual video game. I made the case in a different article that the demo or the build is 80 to 90 percent of a publisher’s decision, and that holds true whoever’s looking. In gaming, it’s seldom the technology, the talent, the patents or something else.

The fundamental question here is this: will this game make money? More sophisticated investors will approach this with more nuance, hopefully, but it comes down to that. And to answer that question, there are a multitude of other questions that are typically asked (some more suitable for games in development, some for games already shipped):

1. Does the game have a clear and compelling vision and pillars?

2. Does the game have a clear and credible differentiation?

3. Is there a large enough addressable market? Some games are fantastic but the player base is just not that big, so the revenue ceiling is relatively low. They may be worth some investment, but this puts an emphasis on how much is financially reasonable

4. Can the game continue to monetize after release? Is DLC a good fit? Are there any other revenue streams that make sense?

5. Does the IP have good franchise potential? Does it afford any transmedia opportunities?

6. Does the game fit in the competitive landscape or is it fighting in a red ocean and/or against 800 lb. gorillas?

7. Is there some traction already that can help validate interest, whether on Discord or wishlists or perhaps reception to a trailer?

8. Is the game marketable? Some games are great but they’re really hard to communicate or building a community around it is especially challenging given the nature of the game. Or vice versa

9. Does this game fit our product portfolio and roadmap? If a publisher is interested in your game, they want to make sure that it doesn’t cannibalize sales from some of their other games. Or that it doesn’t come out roughly at the same time as GTA VII

10. Are there any macroeconomic trends that might support or disrupt the commercial performance of this game? For instance, if your game is geared mainly at a Chinese audience but relationships between your country and China are deteriorating, you may be looking at regulatory hurdles that could perhaps undermine distribution

An additional question that I like to ask by just talking to a few random people in the team is about the strength of the connection between the team and the game. What I want to know is if the team is “locked in”. And what I mean by that is: are they aligned on the vision? Do they buy into it? Are they excited? Are they driven by the genre or is this something that they don’t have much of a connection with? Do they still believe in the potential of the game? Do they still believe that the game is doable in time? And are they setting a really high quality bar for themselves or are they just going through the motions?

If the answer is no, then that’s a problem worth looking into. It’s hard to extricate team from game and game from team. They form an important and often overlooked symbiosis. Which leads to the next point.

2. The team

The next evaluation is about the team, the people making the game, and, as I see it, it’s on five axes.

Capacity: this is really straightforward: are there enough hands to do the work in the time available? And if not, is there a credible ramp up plan in place to reach that capacity? The operative word here is “credible”. I once worked with a studio that intended to hire about a hundred people in a matter of months in order to hit the needed capacity target. Technically doable, but an absolute recipe for disaster, as you can imagine.

Competencies: are the right functional areas of expertise covered? E.g.: systems design, network engineering, narrative design, pixel artists, etc. Publishers especially tend to be a little more blunt about this, which I think is great and I’ve written about it before: if you’re making say, a combat game, and you don’t have a combat designer, that’s almost inevitably a deal-breaker. A promise to hire one later doesn’t really count for much. Angel investors and early-stage VCs lean on this dimension hardest of all, because early on they’re betting on the team far more than on the build.

Seniority balance: does this team have the right mix of direction, seniority and execution? Maybe you need 6 animators for this specific game and indeed you have them, but 4 of them are junior and 2 are mid-level. No lead animator. And there’s no art director to help coalesce all the art disciplines, just a 2D art lead who’s never worked a 3D project like this one. That’s not great. Equally not great is having 7 director-level people with no one at the mid to senior level to execute on all that direction.

Genre and platform expertise: do the developers have experience making this kind of game on this platform? A great team that released a fantastic, stylized 2D platformer on PC is far from automatically great if they’re now making a high-fidelity, 3D first-person shooter on Playstation 5 that is supposed to run as a... live service. Some of that expertise will translate, sure, but that team is inevitably going to go through growing pains learning about the genre, the platform and the business model.

Team cohesion: a collection of great developers is not necessarily a great team. An effective team knows how to work together, how to disagree constructively, how to support each other, they have a collective identity, well-understood idiosyncrasies, they’ve shipped together, they won and lost together. Those are invaluable intangibles that regularly separate the studios shipping seminal games from the rest. Not highest on the investor priority list, but pretty high on mine.

3. Leadership

To their own detriment, I don’t think publishers put a great deal of emphasis on this. VCs do so more, but I don’t believe that this isn’t an area they dig deep into either. I’m not sure why. Perhaps because they’re primarily driven by (relatively) short-term returns. I, for one, spend a good chunk of my time and attention on this lens.

In my experience, most studios tend to have a bit of a leadership vacuum. Most studio executives in indie studios come up as developers. They’re either a great programmer, or a great artist, or the smartest designer around, or they’re simply the ones who started the company, and leading a team is something that gets tacked on as a side effect of being good at something completely different or being entrepreneurial. The leadership training and/or mentorship is not available to them, at least not immediately so. And sadly, founders or studio directors tend to be the last to understand this.

So what you typically get is a team that’s underled and overmanaged, drowning in perfunctory standups, Jira boards with nine hundred tickets of equal priority, all sorts of complicated status reports for no one, and no sense at all for where the game is actually going, or why coming to work on Mondays has meaning and value, or why the team is crucial to the success of the organization.

What makes this hard to spot from the inside is that the studio looks busy, and it looks managed, because it is. But leadership is lacking.

So the thing I’m checking is if the leadership job is being done by anyone at all, title or no title. Questions that I typically ask, in no particular order, are:

• Who ensures that there’s a clear, ambitious, exciting and agreed upon vision?

• Who actively empowers and sets teammates up for success?

• Who decides what gets cut and what pivots or new ideas to pursue?

• Who celebrates successes and holds the team to account when they’re not quite hitting the mark?

• Who models important behaviors like integrity, honesty, humility, consistency and hard work?

• Who brings people together when they’re at each other’s throats?

• And does this all work? Does the team believe in the project, in the plan, in themselves?

This isn’t easy to quantify and track on a spreadsheet, but the work of asking these difficult questions, with humility, with kindness, with perseverance, is supremely important for game studios.

4. Culture

I read somewhere the culture is what the team does when the founder isn’t watching. It’s the lingering effects from every behavior the studio has rewarded and punished, on purpose or by accident, since day one. The values on the careers page are the aspiration, but the culture is the good and bad behaviors that the organization built over time.

Patrick Lencioni’s five dysfunctions of a team maps how those behaviors tend to go bad. It typically starts with trust, when people are OK being wrong in front of each other. If you take that trust away, disagreement starts disappearing, people slowly start nodding along during sprint planning, during reviews and then they slowly start building not what’s necessary, but what feels right at the time, or even worse, what the boss asks, whether right or wrong. With no real disagreement there’s no commitment. With no commitment there’s nothing to hold anyone to, so accountability dies. And once accountability is gone, no one really cares about results anymore. Without trust, it’s just some job and absolutely nothing else.

Now, the problem is that while rubrics and scorecards do exist, assessing the quality of an studio’s culture through internal or external assessment, with honesty, is exceedingly hard. Culture is many things, many behaviors at once, and surveys require some degree of safety and candor, which is highly dependent on... a healthy culture. So if that’s not there, ascertaining the cultural reality of a studio is hard.

With that said, here are a few instruments to put the ball in the park.

Information flow. Ron Westrum sorted cultures by how they handle information: pathological (messengers shot), bureaucratic (messengers ignored) or generative (messengers trained). The DORA research turned it into a validated six-question survey that statistically predicts both delivery and organizational performance. The item I pay most attention to is whether messengers are punished for bad news. Test it: when the last playtest or vertical slice came back bad, what happened in the next 48 hours? In a generative studio the bad news travels up fast, gets met with “what does this tell us,” and changes the next milestone. In a pathological one it gets buried, and the same problem returns next quarter. Of course, this requires a subjective analysis, but it can be telling.

Psychological safety (but only as one facet). This is perhaps where you see some assessments overreach a little. Google’s Project Aristotle did find psychological safety, the freedom to take a risk or admit a mistake without it costing you, to be the strongest single predictor of team performance, and Amy Edmondson’s seven-item scale measures it cheaply. But Aristotle found four other factors, and the one that counts most beside safety is dependability, whether people do what they said they would. A studio can be perfectly safe and perfectly unaccountable, everyone lovely and nothing shipping. So score safety, then score dependability (whether team members reliably complete their work on time and to the required standard) and decision-clarity right next to it (roles clear, goals clear, plan clear, strategy clear), and never take safety on its own.

The adequacy of culture relative to a creative studio. The Competing Values Framework (Cameron and Quinn) plots organizational culture across four types, clan, adhocracy, market and hierarchy, and its OCAI instrument asks people to allocate 100 points across for specific statements twice: what they’re like today and what they’d prefer them to be tomorrow. The Now versus Preferred approach shows where people feel the culture is failing them. And leadership’s scores versus the rest of the studio’s show whether the founder’s self-image matches the actual reality. A creative studio usually needs real adhocracy (experiment, risk) plus enough clan (people, belonging) to hold talent. One that has slid into dominant hierarchy or market while its people beg for adhocracy is a studio in which maybe deadline-and-control management is strangling the thing that makes the games good.

A few other common metrics at your disposal to assess culture.

• Regrettable senior attrition. Raw turnover can sometimes be misleading in games, because teams disband so often after shipping. What I put more focus on is how many senior and lead people that you wanted to keep actually left mid-project, and how long they took to replace. And I mean truly replace, not just staff the position. Seniors have the most options and leave first, so their flight is the hardest thing to conceal and the most predictive of a culture possibly hollowing out.

• eNPS, the would-you-recommend-working-here score. Above +20 is good, above +40 is strong, negative is a red flag. The trend tends to reveal more than the number itself.

• Internal mobility. Can a mid designer become a lead here, or do they have to leave to level up? Healthy studios fill something like 15 to 20 percent of roles from inside, and the top reason people quit is lack of growth, not pay.

• Crunch, possibly the defining game-studio metric. The IGDA’s 2023 survey found roughly a third of developers still crunch, a third of those get nothing extra for it, and the top reason developers want out of the industry is quality of life, ahead of pay. And I can’t believe I still have to say this in 2026 but crunch doesn’t buy what studios think it does: labor research going back to Pencavel finds output per hour falls off a cliff past about 50 hours a week. Habitual crunch burns the team to produce roughly the same work while loading up burnout debt that comes due as post-ship attrition.

So as you can see, there are multiple options for you to at least take a stab at trying to understand the effectiveness of your studio’s culture. Unless there’s an egregious and overt level of toxicity and dysfunction, publishers, angels and VCs are unlikely to pay a great deal of attention to any of this, but you certainly should, because a healthy culture will inevitably inform the other lenses.

5. Technology and tools

Unless your studio is defined by technology, for instance if you’re at the cutting edge of high-fidelity graphics, or you run a live service that requires a massive backend infrastructure, the thing you’re going to be graded on isn’t the choice of engine or stack, but whether the technology is a real, legitimate asset that enables the team to meet their objectives, build fast, build safely... or not.

There’s a fair deal of nuance at play that goes beyond the scope of this article, but to give you the broad strokes, these are some of the things that most prospective investors are likely to assess, or at a minimum should assess:

The build and iteration loop. A combo of healthy technology and healthy tech practices means that the build runs, the whole team can play it daily, and “the build is broken” is an event that’s being addressed, not a regular Tuesday. Coupled with that, the number that telegraphs effectiveness really well is iteration time, meaning the time between a developer changing something in the build and seeing it in the running game, even if it’s in a feature branch that still needs to be merged into Main at some point or go through a battery of tests. If it’s seconds, then that team can conceivably explore a hundred ideas and find the fun or validate hypotheses rapidly. If it’s minutes or more, for whatever reason, then what inevitably happens is that the team ends up iterating less and doing less work in-engine, because the turnaround time is just too punishing. So, productivity takes a hit and the game suffers, because that was precious time that could have been used to iterate, fix, polish, etc.

Technical uncertainty and debt. Whether it’s the inability to understand the true performance impact of your changes because the profiler is not good enough, or the inability to understand the memory impact of your changes because the memory manager sucks, or the myriad hidden bugs that won’t be found until a manual human pass because there’s no auto-testing in place, or because the architecture is simply not ready to accommodate the systems and feature work that emerged organically throughout development, or a multitude of other reasons, the outcome is always the same: inefficiency, surprises and frustration. Each feature starts taking a little longer than the last one, ghost problems emerge, velocity gets chipped away at by impromptu issues, you can’t meet your milestones, everyone starts getting irked by what feels like a series of Sisyphean challenges. Technical visibility and rigorous standards to mitigate tech debt are a must.

Delivery and live-ops health. For anything online, the DORA metrics are a decent gauge of a delivery pipeline: how often you can ship, how long a change takes to reach players, how often a change breaks something, how fast you recover. The main finding is that speed and stability rise together, so a team that says it must trade one for the other is describing a weak pipeline, not a law of physics. And the backend is one of the most under-examined, highest-mortality parts of a games deal. Some of the questions that matter, from a backend vendor that watches studios die on exactly this, are: what’s your cost per concurrent user, and where does it go at 10 times the load? Can you update the service without dropping the players in it? What’s the plan if day one brings double the players you modeled?

Technical budgets and certification readiness. Mature teams define and enforce GPU and CPU performance budgets in milliseconds per subsystem and they keep a close eye on how new content and code affect performance on each platform against different hardware specs. Same for memory management. And on console, certification is a hard gate you don’t control, Sony’s TRC, Microsoft’s XR, Nintendo’s Lot Check, and most titles need two submission rounds, with a failure resetting the clock every time. This isn’t software per se, but it speaks to the technology maturity of the studio. If a VFX artist is capable of saying “I can’t use this assets because we’ll be GPU-bound on this scene”, that’s a pretty good indicator that the team is proactively thinking about this type of technical readiness.

Key-person risk, per subsystem. Bus factor is how many people would have to leave the studio before the work in a specific area stalls, and in games it concentrates in a few modules: the engine, game logic, netcode and backend, the build and asset pipeline, the platform-cert integration, that kind of stuff. It’s imperative to understand if the studio has a company-wide disaster on its hands if a developer who’s a single point of failure walks out the door. A bus factor of one on the engine or the backend is a liability the org chart can hide but that gets uncovered after a mere handful of simple questions, so be ready for that.

6. Work systems

Work systems is an umbrella term for all the practices and artifacts that enable the team’s effort to ultimately become a shipped game (e.g.: processes, standups, team charter, sprint burndown, definitions of done, QA dashboard, etc., etc.) There are two traps when assessing this. The first one is that, at a glance, a busy studio looks like a healthy one. That might be true, or not. We can all be very diligent at all the wrong things. And the second is that people who evaluate work systems, whether it’s you or the consultant hired by the company looking to acquire your studio, put far too much emphasis on production methodologies. Are they doing agile? Great. Do they have standups? Great. How about burndown charts, can we see some of them? Yep, great. It looks good, but none of that necessarily means anything. They’re just tools, means to an end. they may or may not enable effectiveness and efficiency.

So what are some of the things you should look for to ascertain the health of your work systems?

Clarity. Do people understand their roles, what’s expected of them, and how they interrelate to other roles? Are the game’s vision and pillars crystal clear to everyone? Are the tactical goals well-understood, discussed and realistic? Do developers know exactly how their work ends up in the game?

Communication and collaboration. This is closely tied to culture and team: do people share their ideas with each other, do they respectfully and openly disagree with each other, do they selflessly help each other?

Clear processes. Disabuse yourself from labels for just a moment. Forget about Agile, waterfall, crystal, the pomodoro technique, and think about this: do people know how to size the work in front of them, do they understand what they’re supposed to work on next, what the priorities are, how to do that work, how that work blocks or unblocks others, how their work gets into the engine, what to do when they’re blocked?

Value delivered over tasks moved to the done column. The goal is not to move tickets from the To Do to the Done column. It’s to make an amazing video game, little by little. The goal is to create value, day in and day out, stacking value on value until the game is excellent. Is the team clear on the notion that they’re not there to merely execute on tasks? Are they empowered to make decisions, to use their judgment, to lean on their subject-matter expertise to create something great, or are they in a system that simply rewards shuffling tickets in Jira?

A combination of predictable delivery and legitimate creativity in action. Investors are (understandably, I’d argue) going to obsess over your capacity to hit sprint goals and milestones a great deal more than whether the output of those goals and milestones is any good. You shouldn’t. Completing tasks is very important, it’s not easy, but again, it’s a means to an end. The end is to build a great video game. And game development is creative exploration: you start with a set of ideas that you hope may work and as you put things together, you learn, you realize that certain things don’t work, that new ideas work better, and you make judgment calls on the fly, within reason, in the interest of making a great game, not just hitting a bunch of predefined goals from three months back. So the goal is to strike a healthy balance between scope discipline, meeting your goals and judiciously welcoming the empirical insights you acquire along the way. I wrote about how to do this here and here.

Proactive risk management. It’s uncanny to me how many times the same teams trip over the same stones. Game development is a reasonably well-documented process. So does the team have a risk register, are they asking challenging questions, are they humble about issues, do they take ownership for following up on mitigation tasks, are risks being proactively defused? Or is the team performing risk management theater?

Sustainable development. Sustained crunch is a God-tier metric that tells you with remarkable precision that the work system isn’t converting effort into progress. Keep an eye out for after-hours activity for the tell that a death march has begun, the team working longer and producing less per hour, the bug backlog growing faster than it gets cleared. And the quintessential smoking gun: the studio buying pizzas for the team.

7. The money

Money is the most measurable lens and it’s pretty straightforward.

Survival first. Two figures, both shockingly underestimated. Runway, in months, at the current net burn, where under six months means every conversation, the pitch included, happens under duress. And the cost to finish, estimated candidly against that runway, because the last 20 percent of a game, the polish, the stabilization, certification, the long stretch where it finally gets good, that eats up something like half of the real effort. A plan that funds 80 percent of the game tends to fund zero shippable games. To boot: the deal that you’re counting on to refill the runway always takes months longer to close than you hope. Investors will zero in on your burn rate, runway and game development progress in relation to those. Be prepared.

Quality of earnings. A quality-of-earnings review doesn’t quite ask how much a studio earns but instead how real and repeatable those earnings are. Translated to a studio, this would be: is the revenue recurring, or a string of one-off work-for-hire jobs masqueraded as a trend? Are refunds, chargebacks and discounts hiding churn the top line doesn’t show? For a live game, is the revenue broad or propped up by a handful of whales who can all leave at once?

Concentration. This is one of the numbers that outside assessors value the most. A studio that draws more than 80 percent of its revenue from a single game, or leans on one client, is a single cancellation or one lifecycle-end from gone. To a prospective buyer that’s a discount on the price of the acquisition. In principle, there’s not much you can do about this if you make premium games and thus far you’ve only shipped one game, or you’re in the process of doingthat. But be prepared for this to factor into an investment conversation. And let this be a data point for the value of some basic level of diversification for your business.

Revenue mix. Work-for-hire pays the bills and builds nothing you own. Owning your IP burns cash and builds an asset. Neither is wrong, but the split should be a deliberate strategy, not an accident you backed into. Prepare for that argument too.

Finally, a quick comment on the timing of negotiations. Runway is bargaining power, so the time to raise funds is well before you need them, because a studio with two months of cash negotiates with a gun to its own head and investors will know and understandably leverage that for their benefit. Be savvy about it.

(If you’re running a live game, the money has its own metrics, and they’re their own subject.)

On acquisitions and other formal due diligence variables

If you’re being evaluated for an M&A (merger and acquisition), the due diligence process tends to be significantly more complex and involved than what I cover in this article and puts a lot more emphasis on legal and financial requirements. If that’s you, please do some more digging and get ready to prepare things like: corporate governance, compliance documentation, complete legal and contract history, litigation history, financial health (P&L, income statement, balance sheet, cashflow statement), tax reports, credit history, past investments, cap table, past valuations, board and shareholder minutes, copyright, trademarks, patents, turnover information, workplace safety, insurances, and resolution on any ethics violations.

Acquisitions are very legally demanding, so suffice to say, I encourage you to not move a finger before retaining the services of legal counsel and a financial M&A specialist.

And while we’re on the topic of buying and selling, I want to very quickly poke you to consider turning the lens back around on prospective buyers for just a moment, because the founder being assessed for acquisition should undoubtedly be doing some assessing of their own. The record for acquisitions in our industry is demonstrably awful. And I mean truly dismal. Again, this is more than there’s room for in this article, but you need to be very clear on what’s statistically likely to happen to your studio if you sell it to a large publisher or conglomerate.

Self-assessment

Hopefully I made a strong enough argument for the value of doing due diligence on your own studio. It’s good for you, good for the team, good for the studio, good for the game and sets you up for better, more empowered conversations with prospective investors.

So, how do you do it?

Separate symptom from cause. Almost every studio has “stated” problems: the engineers are slow, we keep missing milestones, the team’s lost its spark, etc. I encourage you to initially treat these challenges as a symptom, not the full diagnosis. Surveyed executives overwhelmingly admit their organizations are bad at diagnosing problems before they start solving them, which is how studios end up fixing the wrong thing with great energy (I wrote about this). So ask why, then ask why again, and then ask why some more. You might just learn that the slow engineers were a leadership problem, or that the missed milestones were actually a clarity problem. And please do prepare yourself for the notion that if you’re running the studio, you’re statistically the most likely driver of at least a fir share of the structural issues. And it’s OK. Leadership can be hard. We’re all trying, we’re all growing. Just be humble and solve one problem at a time, even if that involves you.

Triangulate, because no one account is the single source of truth. Ask the same few hard questions across the studio and see where the answers diverge. The game director gives you the official story, the leads give you a slightly different one, and the developers in the team tell you a completely different story from the trenches. When three people answer one question three different ways, you’ve found an issue that demands your attention. Ask the blunt questions: who actually makes the calls here, what happens when you disagree with that person, when something’s broken does anyone say so? Follow the bread crumbs and do your best to solve root causes, not symptoms.

Time-box it and check your biases. You don’t need months. In days you can form a view and pull the hard data, the runway, the build, the milestone history, the turnover rate, the subjective perspectives from various conversations with team members. In a week or two you can form a decent picture. The mistake is the one every diagnostician faces, which is anchoring on the first answer and then collecting evidence to support your initial impression. So do the opposite. Try to disprove your own conclusion and be transparent with everyone about your findings.

Wrapping up

Boiled down, a studio that’s going to make it tends to have most of these seven lenses in decent shape. Maybe not all perfect, but in shape. More importantly, studios with the best odds of success are looking into these things, with humility, with empathy, with a kaizen mindset and genuine desire to continuously improve and make things better.

Luckily for you, the due diligence that most most investors carry out to see if your studio is worth the risk, ultimately entails things that you would benefit greatly from looking into first. Arguably, you must, investor or not, if you want your studio to do well. So I’m gently poking you to put time on your calendar to self-assess and tend to your garden with regularity.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

Every long project has a stretch in which the mood just takes a nosedive. More often than not, there’s nothing particularly awful causing that. The game is progressing reasonably well, the team is working sensible hours and getting along just fine, and yet morale is in the gutter. Standups that were lively, engaged and used to run over are done in five minutes, and the creative meetings that were fun and constructive are now unbearably icy and contentious. Something’s just wrong.

The first time you go through this, you understandably go looking for what’s wrong. Maybe the game is the problem, maybe it’s the team, maybe it’s you. And you’re just not sure exactly what it is.

That’s what I want to talk to you about, because a drop in engagement and excitement is rarely a verdict on any of those. As a matter of fact, it’s a quite predictable part of the process of making a video game. A team’s morale over a long production follows an arc you can more or less count on.

Morale swings are much more predictable than you’d imagine

Let me start with what was a surprising realization for me: that the worst stretches of a project are actually mapped pretty cleanly to the project plan.

Researcher Connie Gersick followed real teams from their first meeting to their deadline and found a very discernible pattern. A team sort of coasts through the first half of a project on the assumptions it made at kickoff, and then, at almost exactly the midpoint between day one and the deadline, it hits a hard turn. What happens is that people raise their heads, look up, they register how far there still is to go, they stress themselves and start tearing up the plan. The clock is what sets it off, not the work left to do, and it happens at around the same point in time whether it’s a six week or six year project.

Now connect that to morale. That upheaval, a team determining mid-project that the plan they’re following somehow wrong, is inevitably going to crater the team’s mood. So the worst morale stretch tends to hit a remarkably predictable spot on the schedule, the midpoint. We essentially know it’s going to happen and when it’s going to happen before the project even starts. While that’s a little upsetting, knowing that can also be empowering.

The second thing about this mood predictability is that the emotional lows weigh more than the highs, and we know roughly how much more. Teresa Amabile and Steven Kramer collected almost twelve thousand daily diary entries from people doing creative work inside companies. On people’s best days, the most common thread was some degree of progress, of forward momentum. On their worst days, it was a setback. Nothing surprising there. But what’s interesting is that they learned that the setback drags a person’s inner state down two to three times harder than an equivalent win lifts it. So the canceled feature and the failed playtest and the milestone that slips a week each set the team back more than a good day of development can move it forward. Which is exactly why fostering, protecting and celebrating the small, visible wins, as much as humanly possible, is unbelievably important to protect team morale and counter the inevitable setbacks of game development.

The third thing is that mood is contagious. Sigal Barsade ran a fascinating experiment on this. She planted a trained actor in working groups, gave the actor a mood to act out and saw it spread to everyone else. The groups that caught a good mood cooperated more and argued less. Even a contained gloom infects a team about as efficiently as a loud one. And these moods spread much more strongly from the top down. A second study from Sy and Côté put team leaders into a good or bad mood and then sent them in to lead a group through a task. The leader’s mood clearly transferred to the whole group, and the upbeat-led teams coordinated measurably better. People catch the boss’ state far more than the boss catches theirs. Your calm can be contagious, and so can your dread. If you bring to a meeting a broken build and an angry publisher plastered on your face, everyone in that meeting is about to have the same morning as you.

When you put the three together, morale is no longer something random that happens to you or your team. It maps well to the calendar, the lows cut deeper than the highs, and mood swings tend to start with the leader. That makes it something you can plan for, prepare, train and ultimately manage better.

Morale across dev phases

I’ve written before about production phases. The emotional arc of a team tracks the dev phases with so much precision that you can pretty much anticipate it.

The first phase, brainstorming and feasibility, is probably the best the mood will ever be, and you should enjoy it while it lasts. This is the most fun the team will have in a long while. People are dreaming out loud, throwing ideas around and building on each other’s creativity, and the studio is fueled by the thrill of a game that could one day become the next Hollow Knight, or the next disco Elysium. Nothing’s built yet, and an unbuilt game is a perfect game. It’s got no bad reviews and nothing’s broken. Good times.

Then comes rapid prototyping. This is where the team face their first lows, because prototyping is where you kill many, actually most ideas. The concept that was amazing in your head is put to the test with a hacky, janky prototype and, more often than not, disappoints. Most prototypes fail, and that’s far from a bad thing. They’re there to show you what’s feasible and what’s not. But it still stings every time, because each dead idea is a setback of sorts, and we already talked about the actual weight of setbacks.

Concept bolstering is an ambivalent time. On the one hand, you’re excited about the game, creativity is flowing, you start working on a first playable, something is being created, and that’s great. On the other hand, you’re actively poking holes to make sure that the idea still holds, you’re working on treatments and documents (which is seldom great fun) and the game isn’t 100% locked in just yet, so you’re kind of holding your breath waiting for that yay or nay call. The mood here rides on one thing, which is whether people feel the game idea coming together or feel like they’re going in circles and might need to go back to the drawing board.

Then comes pre-production, where the mood tends to deflate and especially catch first-time teams off guard. Pre-production is mostly plumbing. I’m talking about developing tools, pipelines, style guides, finding and testing vendors, and authoring all the nitty-gritty documentation that’ll make production survivable later. It’s very important work and it’s the right thing to do, but it produces almost nothing you can look at and feel especially proud of. The concept high is kind of spent at this point, production’s clearly visible progress hasn’t started yet, and the team’s building scaffolding for a while. You can see how that’s not a recipe for exhilaration.

Production is the long, long middle, and it’s where the full spectrum of the ride lives, the breakthroughs and the walls, the good playtests and the bad playtests, the week something finally clicks and the week somebody everyone loves hands in their notice, the day that amazing streamer celebrated your game and the day the press tore your open Beta to pieces. It’s a real rollercoaster.

As mentioned, this is also where Gersick’s midpoint shows up most consistently. Somewhere near the halfway mark, the team looks at the state of the build, looks at the plan, looks at how much time it’s left and how much they still need to produce, and their world is rocked. Understandably, energy sags even though every burndown chart at the office may claim you’re on track.

With that said, it’s important to understand that crisis is also opportunity. Similar to Gersick’s findings, the design firm IDEO mapped the emotional arc of creative projects and found the low point in the same place nearly every time, the unglamorous middle they call synthesis. The confusion and the self-doubt of that stretch, the getting lost and then finding your way back out, are in their words the essential experiences for the emergence of creativity. Ed Catmull, who ran Pixar through its first thirty years, put the same idea more bluntly in Creativity, Inc. when he wrote that early on, all of their movies suck. He means every single one of them starts ugly and unformed, and the job is to climb out of all that. Your project is likely no different, and that’s a good thing.

Closing is consistently and predictably rough. Creative work is mostly behind you and what’s left is stabilization, certification, playing the same level for the four hundredth time hunting the one bug that crashes it on a particular console. Certification fails, the porting partner is way behind schedule, you learn that the small performance problem that you have is actually a colossal rework that touches every system and every second asset in the game. The team is bone tired and stress levels are through the roof. So yeah, a very emotionally demanding moment.

Then comes launch. First, every team goes through a moment of high anticipation, tension, excitement and suspense. And pride, because getting across the finish line is legitimately hard. Everyone is on pins and needles waiting to see how the game performs. And here there’s a fork in the road: the game can either do well, do poorly, or somewhere in the middle. And morale tracks directly to how the game performs: a great launch is a high like almost nothing else in this work, and a bad one brings all manners of frustration and grief.

Finally, there’s post-launch, which is a phase we regularly fail to proactively plan for. Even a good launch is followed by a profound flatness. The comedown that comes when the thing that marshalled your every waking hour for years of your life is suddenly out in the world, finished, gone. It’s like a massive, collective, extended adrenaline dump. This is an emotionally really weird time of reflection, adaptation, identity formation and more.

Assessing where your team is

Start with the uncomfortable truth: it’s hard to measure morale directly, and the people who could tell you how they’re really doing often won’t, especially as things start to slide. So before any technique for reading a team works at all, the team has to feel safe enough to be honest with you in the first place. This happens to be the single most studied finding in team research. When Google studied a hundred and eighty of its own teams to work out what separated the great ones from the rest, the top factor by a wide margin wasn’t talent or experience. It was psychological safety, the term Amy Edmondson coined for the shared belief that a team is safe for taking interpersonal risks, like admitting a mistake or saying out loud that the plan is in trouble. Without it, every measurement you take is worthless, because everyone just tells you they’re fine.

Assuming you’ve built some of that safety, the most reliable read is when people stop bringing you problems. That’s the alarm, not the loud standup with the heated disagreement, but the silence, the systematic compliance. A team that’s still arguing with you still cares. The dangerous meeting is the calm one where everyone says they’re good and not one of them means it, and a sudden drop in bad news is itself bad news.

A great tool for surfacing all of this is the old, boring, trusty, recurring one-on-one, held every week or two whether or not there’s a crisis. The group setting is where people perform being fine. The private conversation is where you have a much better chance to find out they’re not, while there’s still time to act. Dropping one-on-ones the second things get busy is exactly backwards.

Then you need to take the pulse of the group, not only the individuals inside it. Because mood is contagious, one person’s state rarely stays contained, so pay attention to the team’s overall temperature and not just one face in a meeting. One person flat is a person to check on, but three people flat in the same week is the team, in a way, trying to tell you something. Watch your most committed people the closest, because they’re the ones you lose first: the one who cares most keeps going long past the point where everyone else would stop, so by the time they visibly dim, you’re already late. And because setbacks weigh so much more than wins, you need to keep an honest count of which is piling up.

Preparing the team

You can’t carry the entire responsibility of the entire emotional ride of game development all by yourself. It’s not possible. And you’re not supposed to. A lot of this work is preparing and empowering the team to manage it with you, and the best time to start is while the mood’s still high, which is precisely when it feels least necessary. So I encourage you to do it anyway. At kickoff, when everyone’s still optimistic, you can have a plain, honest, no BS conversation about what’s coming. Share this with them, tell them it’s normal, that it’s on the schedule, that you’ll all get through it together, by being kind, supportive, empathetic and by finding together the team’s inner courage.

This may all sound a little obvious (”talk to the team”, duh), but a team that’s empowered with the understanding that the slump is coming and that it’s normal, is a team that manages it completely differently when it arrives. The morale drop stops being validation that the game’s broken and becomes the thing the studio leader said would happen.

It’s the same logic we use when we create a team charter, which is one of the most underrated things a small studio can put in place. Agreeing early on how you’ll make decisions, how you’ll raise problems and what you’ll do when one of your own agreements gets broken is a powerful pre-commitment. You write the rules while everyone’s calm and reasonable, so that when things get tense you’re not also trying to invent the rules from scratch. The worst possible time to decide how your team handles emotional setbacks is in the middle of one.

Another concrete thing you can do is plan the calendar so the team isn’t running at full intensity the whole time. Amabile’s research found that people can do hard creative work under heavy pressure, but only when they also have focus and a sense that the work means something. If you take those two away and leave nothing but the pressure, you get burnout in a jiffy. No team can sprint for a year straight without consequences. So after a brutal, high-pressure milestone, deliberately schedule a lighter, more exploratory stretch, a real breather where people can catch up, recover and experiment a little. That breather isn’t lost time. It’s what keeps the team able to push hard again the next time you need them to.

Vanessa Druskat and Steven Wolff studied what makes groups emotionally capable and found something a little counterintuitive, which is that a group of emotionally intelligent individuals doesn’t automatically add up to an emotionally intelligent group (this is something that I wish I had known a decade ago). The group ability is its own thing, and it’s deliberately built rather than hired. It comes out of habits, the practice of trust, the sense that you’re all one effort instead of a set of separate careers and jobs, the willingness to call out a foul when someone crosses a line, all that. A team with those habits starts to regulate itself. If say, someone points out the slump in the retro before you have to, the whole weight of holding the group together stops resting on you alone. Which is the only arrangement that lasts anyway, because leading a small studio was never meant to be something one exhausted founder does single-handed.

Leading the whole ride

This ebb and flow is unavoidable. The emotional ride is a part of the work, the cost of making something that didn’t exist before with people who care a great deal and don’t know for sure what the outcome will be. The highs will come and the lows are already on the schedule. And a lot of what happens to a team’s spirit across a long project simply isn’t in your hands.

What is in your hands is meeting this challenge with your eyes open, seeing the midpoint slump coming and telling the team it’s on its way before it arrives, banking the trust before the day you have to spend it and keeping some steadiness in reserve for the bad weeks.

Get that right and you might have just built two things by the end of the project, not just one. There’s the game, of course, but there’s also the team. A team that’s now ridden the whole thing with you, start to finish, a team that learned, grew from the experience and now knows it can do it again.

How do you manage morale at your studio? Tell me in the comments!

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

Every studio that ships its game, sooner or later has to figure out what comes next. It can be a sequel, an expansion, a new IP, pivot to a new genre altogether, or a make a deliberate pause to recover. It’s a fairly important call that a studio has to make, and plenty of them make it without a great deal of strategic thought.

The chat tends to happens late-ish, when the team is pretty darn worn out, and it gets pulled around by whoever feels strongest that week or by whatever the revenue dictates at the time. So, important facts go unchecked, good options get dropped for weak reasons, and questionable ones get extra attention because they feel exciting in the moment.

There’s a better way to approach this. Before the creative question even comes up, five practical variables have somewhat narrowed your options already. They’re what your contract allows, what your revenue enables you to do, how much of your existing work carries over to the next game, what your team has left in the tank and only then what it is that you’re all creatively driven to do.

In this article I walk you through all five, so that whatever you choose does right by the studio, the team and the people who’ll play what comes next.

1. Contractual obligations

If you self-published and kept all rights, go ahead and skip this section. Everyone else, I suggest you dig out the agreement before the first brainstorm, because your publisher gave your next game a great deal of thought long before you did. They kind of have to.

There’s a study of 3,576 UK game companies showing that publishers go under at far higher rates than developers, and that they cope by funding follow-ups to titles that already worked instead of new bets.

So when your game performs, a sequel becomes a publisher’s safest possible investment, and the agreement you signed probably already reflects that.

Some clauses constrain what you’re allowed to develop next. The non-compete is the worst one. Raw Fury’s published example contract restricts releasing “a similar type of project” for 12 months after launch, and depending on how broadly yours is drafted, that can rule out a fast follow-up in your own genre. The license scope is trickier. If it’s written around your characters and universe rather than the game itself, it can block a sequel outright , since any sequel lives in the licensed universe by definition.

Other clauses don’t dictate the game so much as who you’ll be making it with. These are the option rights on future work, and Brandon Huffman, a games attorney and general counsel to the IGDA, describes the three common forms.

A right of first look means showing them the next game before anyone else and giving them a window to make an offer, which you may refuse, so as obligations go it’s a light one.

A right of first negotiation is heavier: no talking to other publishers until you’ve tried in good faith to close a deal with this one. Some come with a no-shop clause on top, so you can’t even use their offer as leverage elsewhere.

And a right of last refusal lets them match any deal you bring back from the market, which sours the other publisher’s enthusiasm for ever negotiating with you again. Huffman recommends refusing all of these at signing, and I’d echo that. If one is already in your agreement, then at minimum negotiate a hard deadline by which the publisher must commit to the next game or release you, so the studio isn’t stuck waiting while they make up their mind.

All of this is boilerplate, mind you, signed back when getting funded was understandably the only thing on anyone’s mind, and it tends to resurface around this point in time. If game two involves pitching publishers again, the publisher relationship guide can help with the negotiation. In any case, one afternoon rereading the PDF with the contract and taking notes is pretty much a must.

2. Funding

The second variable is your bank account, or more precisely the durable monthly revenue rather than the launch spike on the partner dashboard. I’m talking about the post-refund, post-platform-cut, post-tax number (more on the financial primer). Once you have that, sorting the options gets a lot easier.

Take DLC for instance, which plenty of teams treat as the seemingly cost-effective continuation. But is it? Chris Zukowski scraped all 14,399 Steam releases from 2024 and found that DLC tracks the base game’s revenue very tightly. Around 68% of games that grossed over $1M shipped at least one DLC, versus 21% for games in the $10k-to-$149k range and 5.7% below that.

His advice is consistent with all that: headed past $150k? Prepare DLC. Around $10k? A small supporter pack is fine, say a week or two of work. Below that, he recommends skipping the expansion business altogether and making your next game. An expansion only sells to people who already own the game, so that revenue ceiling is your existing audience multiplied by their attach rate. On a small base, that’s months of effort to sell something to very few people.

A new game is of course a much bigger check. Say, two-plus years of production funding, give or take. If the first game banked that kind of money, then congratulations, you’ve earned the rare privilege of self-funding. This is how Supergiant built Transistor entirely off Bastion’s earnings without taking a cent from publishers. If your game didn’t, then you’re bound to pitch again, except this time with a shipped title to your name, which does count for something.

On Steam, second games average 40% more revenue than debuts, $168k against $120k per Video Game Insights’ estimates. That said, you have to take that number with a pinch of salt, because it’s an average over a hit-skewed distribution, and the sample only includes studios that managed to ship a second game at all, which the same report suggests is roughly one studio in three. Experience pays, yes, provided you survive long enough to collect.

Then there’s taking a break, which no P&L will ever recommend. Doing nothing still costs full burn, which is largely salaries times months, and produces nothing immediately visible. Some studios can afford one. The ones that can have usually earned it on game one’s revenue, and if yours can’t, the pause shrinks to the few weeks of leave I’ll get to below, with the next project starting rapidly out of necessity.

And if keeping game one alive as a live game is on the menu, please understand that you’re not weighing a “just a project”, you’re weighing a permanent operation with economics all of its own. I wrote a whole primer on what that life costs, so I won’t repeat it here, other than to say: read it before live ops makes it onto the whiteboard.

3. What may transfer to the next game

Shipping one game leaves you with a fair bit more than just the game. By the end you own a pipeline that demonstrably works, tooling shaped to the genre, a team that knows how to work together, a team with institutional knowledge of this type of game and this type of genre, an audience, possibly an IP with some recognition attached to it, relevant partnerships, etc.

Every candidate for game two keeps part of that transferable inventory of capabilities and abandons the rest. That’s a major consideration.

Tech is the first and most obvious evaluation. When Klei followed up the Shank 1 and 2 brawlers with a stealth game, they were taking a total design risk but close to zero technology risk. Their Mark of the Ninja postmortem credits the reused stack: “Had we also started our technology from scratch, we could easily have spent over a year in pre-production.” They still built new tools for the stealth iteration, of course.

As a rough rule, an adjacent genre reuses most of the stack, a distant genre maybe keeps the engine and not much else, and swapping engines means starting from very nearly nothing.

The audience is another element that might conceivably come with you. Mechanically speaking, wishlists die with the game they were collected for, they do not transfer. That said, what does transfer on Steam is followers of your developer and franchise pages, who get an email when the next game goes live. The rest is cross-promotion run from inside game one, which is admittedly an unglamorous channel, but one that performs really well. Butterscotch Shenanigans found that linking to the sequel from the original’s store page and from inside the game outperformed everything else they tried, combined. So if you stay close to what your audience already bought, the carryover can be substantial. Strange Antiquities, the follow-up to Strange Horticulture, opened with 180k wishlists where the original had opened with about 20k, and an estimated 68% of its buyers owned the first game.

If you wander far, the carryover evaporates, as developer Introversion learned. Prison Architect sold over two million copies, and the studio’s next release, a first-person exploration experiment, managed around 6,000 copies in its first two months. Chris Delay admitted afterward: “I wrongly assumed that would just give us a minimum number of people looking at our game.” The audience, in this case, belonged to the game, not to the studio that made it.

There’s also academic backing for that. One study of 2,918 console releases found that new-IP games sell substantially less on average than sequels and licensed titles. The penalty gets even worse late in a platform’s life, once risk-averse late adopters make up most of the buying public.

Let me give you a couple of examples from two studios that went in diametrically opposed directions. Image & Form had a hit with SteamWorld Dig and refused the obvious follow-up. As Brjann Sigurgeirsson put it at the time: “If we make Dig 2, we’re going to be this mining platform game developer. Can’t we do something else?” The one constraint he kept was the universe, so every new genre still launched into the previous game’s audience. Ten years on, no genre is off the table for SteamWorld and a sequel still counts as an option. Zachtronics, on the other hand, went very much the other way and spent twelve profitable years in a single programming-puzzle niche, with an audience that was cheap to reach and glad to pay. Mind you, Barth addressed the cost when he closed the studio in 2022: “while we got very good at making ‘Zachtronics games’ over the last twelve years, it was hard for us to make anything else,” he wrote.

4. What the team has left in the tank

The team that shipped game one may not quite be the team that will start game two, even if every single person stays. Shipping changes people. There’s a great GDC talk on this, Danny Day’s 2016 survey of indie teams after release, built on 18 recorded interviews plus a few dozen questionnaire responses, and its findings are sobering. Morale trends downward as projects drag on, and individuals report feeling worse than their teams let on. Post-launch depression, in his words, definitely exists.

There’s one specific finding that I want to draw attention to: every studio he spoke to gave at least two weeks of paid leave after shipping, with most giving more. Clearly that doesn’t seem to be enough. His advice was to wait until people are going crazy from not building anything, because the appetite does come back on its own. If you drag people back early, you might get a team that says yes to the sequel in week two, but that resents it throughout production.

Observationally, I’d say that the studios with the better track records seem to treat rest as a scheduled step, not as a reward. Supergiant said their plan after Hades 2 reached 1.0 was support the launch, then take a break and only then figure out what comes next. A Hades 3, Amir Rao went out of his way to add, is “not preordained” even with two hits in the franchise. Innersloth went a step further and built the recovery into their portfolio. After years of live-service grind on Among Us, they spun up a smaller “pit stop game” on purpose because, as Forest Willard put it, “It allows for a cooling-off period for employees.”

And then of course there’s the creative and professional appetite, which I think is best addressed person by person rather than at the all-hands. Who really, truly, genuinely wants another tour on this game, or even in this genre? You’ll hear different answers from the people who joined for the game itself than from the ones who joined for the craft or the ones who simply joined because it’s a job, which is perfectly fine. And a sequel staffed by people who privately wanted out is unsurprisingly more likely to produce a flat second game and a retention problem at the same time. I’ll admit I have no study to back that one, just a fair amount of body language seen over the years.

5. The studio’s creative itch

After all that homework, you’re finally at the creative choice, the one the team wanted to have on day one. The good news is that the studios who’ve made this call repeatedly have left somewhat of a method lying around for the rest of us.

Ryan Clark has shipped profitable games for two decades, Crypt of the NecroDancer among them, and his approach to picking the next one is a comps test. Take the 10 or 20 games closest to your candidate and explain, game by game, why each one succeeded or didn’t. He also warns about the default instinct of taking hit game X and making “X but better, or game X but in space,” which in his telling produces good games and rarely noteworthy ones. As he puts it: “If you are not confident in being able to explain why the hits hit and why the others do not, you shouldn’t be confident about your game’s chances either.” I created a game analysis rubric for this, so consider checking it out.

Also prototype before you commit, rather than debating in the abstract. Supergiant’s third game didn't even have a pitch document. It grew out of a theme, what happens when you face defeat, that the team prototyped until it became a playable answer, with external playtesting closing arguments in a much more effective way than meetings.

Subset Games took the same idea to an extreme and spent years after Into the Breach building prototypes without promising any of them to anyone, openly saying they had no idea which would become a game, if any. Granted, that kind of patience is a lot easier with FTL money in the bank. The gist of the idea holds though: a hundred hours of prototyping will answer questions that a hundred hours of debate won’t. It’s as simple as that.

A couple of warnings before you run off to prototype. Day’s survey had one that stood out to me: don’t put the studio’s survival on the prototypes’ shoulders, because prototyping under a “we need a hit by March” deadline is a surefire way to stress the hell out of the team. I also have a writeup about how to cultivate a culture of experimentation that might be relevant if you’re at that stage.

And last: you should be cognizant that you are allowed to decline what on paper seems like the obvious option. Larian got on a GDC stage in 2024 and walked away from the most anticipated sequel in the industry. No Baldur’s Gate 3 expansions and no Baldur’s Gate 4, Swen Vincke told the audience, the studio was simply going to move on. Re-Logic had spent three years on Terraria: Otherworld when they pulled the plug. Their statement said the build was still far from the vision and far behind schedule, and that quality was “not something we are willing to compromise on to make a quick buck.” And back to updating Terraria they went.

I’d be remiss not to point out that both studios said no from a position of overwhelming strength, with all four facts in their favor, and both kept supporting the game that built that strength. So please know that you too are allowed to refuse the default option, whichever that may be, as long as the contract, the bank and the team agree.

The timing of the decision

Everything above has assumed you decide after the game is out. That’s the simple case, and for a small team it’s often the most common one. But it isn’t the only option. There are three reasonable moments in which you can stop and figure out what the studio’s next game will be.

The earliest window is during closing, before the game has even shipped. The closing phase very often doesn’t need the whole team (provided it’s not a game made by only 2-5 people, in which case they’re much more likely to all be needed), so as the game moves into stabilization and certification, some people finish it while the rest find themselves free. Those freed-up people need a deliberate destination, as I argue in the closing guide, and concept work on the next game is one of the better things to do during that time. There’s a money argument for it too. If you’re 15 people on a platformer you already suspect won’t bankroll the next project, every idle month is burn rate you just can’t justify. So, plenty of studios peel off a couple of people late in development, even part-time, to start spinning ideas, or run a two-day hackathon that doubles as a way to re-energize a tired team.

The second window is the few weeks right after launch. The team is wrung out, the sales numbers are still mostly launch-window noise, and you’re being asked to make a big call on both at once. It’s not ideal, and many studios decide here regardless, because waiting is a luxury their runway might just not afford. If that’s you, lean on the contract and the capability facts, which don’t change with the team’s mood, and treat the early revenue assessment as provisional.

The third window is a little later, six to twelve weeks out. By then the revenue curve is a lot more stable, and credible, and the team has had some time off, so the appetite question is hopefully no longer a factor. It’s probably the most transparent and honest analysis you can get, but it’s also the most expensive, because you buy that clarity with weeks or months of thin to no creative output, which is a lot to shoulder if the revenue numbers are not strong.

None of the three is right in the abstract. They’re all very much contextual. A funded team coming off a hit can afford to rest and choose late. A lean team on a modest earner often can’t, and starting during closing is less a best practice than a survival move. Pick the window your money and your headcount actually allow.

Wrapping up

None of this tells you directly what to pick next, but it hopefully keeps the choice from “happening to you”: by a contract clause you forgot, a revenue number you hoped was bigger, an audience that isn’t quite there, or a team that checked out six months ago. Being deliberate requires some discipline but is not that hard. An afternoon with the contract and a few honest conversations can go a long way. Getting it wrong isn’t always expensive but it can be.

That’s the whole case for evaluating these variables before the exciting one: what do we feel like doing? Being concerted simply maximizes the chances for the studio to succeed, the team to thrive, the next game to start with its best foot forward, and gamers to have the best, most fun game possible.

What did your studio choose after its first game, and how did it go? Reply or comment and tell me about it.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

A Bloomberg report on Redfall’s development found that roughly seventy percent of the developers who had worked on Prey left Arkane Austin before Redfall shipped. The ones who stayed were interviewed and said they hoped that Microsoft would step in and cancel the project. The game launched in May 2023 and it was a bit of a train wreck. Both critics and players were brutal. Arkane Austin closed the year after that.

What happened between “the team knew” and “the game shipped anyway” is what this article is about. This happens at every scale, not just at a studio with two hundred employees and a massive publisher with Microsoft’s resources. Very often, four-person indie teams end up in the same place too.

Let’s talk about why pulling the plug on a game is so hard once you’re deep in development, what you can do to identify the inevitable signs as soon as possible, and if necessary, how to make this extremely difficult decision.

Indicators

There are typically two main scenarios in which a game in production gets canceled.

The first is when the decision is made for you and you have no agency over this outcome. For instance: an investor pulls out, a publisher rejects a milestone and invokes the termination clause, a funding round that was supposed to close falls apart at the last minute, or the platform that you were developing for collapses. Those are catastrophic circumstances. You probably can and should look into what you could have done differently and what you can learn from this, but ultimately the decision is forced upon you.

The second scenario is when the decision is yours to make. One way or another, things are just not working and you know that potentially bringing things to a close, as painful as it is, might be the right call.

These are the usual suspects:

Playtests consistently showing that the game is just not working: if you can honestly say that you invested enough time, energy, and iteration cycles on the game and the loop is still not fun, people aren’t engaged by it, developers dread playtests, and the only ones telling you that the game looks great are your spouse and kids, then this is far and away the most powerful indicator that you may need to sunset the project.

Following from the previous point: there’s no clear path forward other than a complete overhaul of the project: blowing up things and trying out new ones is a pretty integral part of game development, but within reason. Sometimes the game isn’t fun, but you can see a credible path to get there. There are very concrete ideas that are reasonable, that the team buys into and that are aligned with the game’s vision and pillars, which still hold.

Development seems to have completely stalled: this is when you take one step forward and two steps backward. The user stories keep going from the To Do to the Done column, but the game still looks and plays like it did in preproduction. There’s fundamentally no progress, chiefly on the fun and engagement fronts.

The team no longer believes in the project: this is legitimately hard to come back from. There are many reasons why this can happen, but if you lost the team’s trust in the project, it’s typically over. If you lead a project or a studio, read your team’s body language: if they’re mum about solutions, if they’re going through the motions, if the idea of bringing this piece of art to the public is no longer getting them excited, it’s because at least at some level they no longer think it’s doable or worthwhile. They’re in the trenches, they know the game intimately, so you’d do well to heed their signals.

The team hates working at the studio and/or together: if after investing enough time and effort into this problem, the team dynamics are still unhealthy, the environment is toxic, work is not only not fun, but a real mountain to scale every day, even if it’s through sheer apathy, then pulling the plug might be in order. Good games have been shipped in toxic or deeply demoralized environments, but the question you should probably ask yourself is if its worth it. Life is short and as much as you may love this project, this is ultimately just a video game. Is this how you want to spend your time? Is this how you want your people to spend their time?

The studio mismanaged the funds: unless you’re bootstrapping, what typically happens is you raise a certain amount of money (angel, VC, publisher) and you commit to a body of work that is commensurate. If you’re at the brink of running out of money, the game isn’t finished and it’s still not in a position to impress and help raise more funds, and you don’t have a rich uncle who can come clutch and save the day, then it’s most likely time to bring the project to a close.

If you run a studio, you have a responsibility to game plan these scenarios and be as proactive as you can about managing risks. It’s impossible to cover all bases, but the more forward-thinking you are and the more preparation you put into this, the better your chances to avoid disaster.

Diagnosis

The diagnostic challenge is rarely about surfacing the indicators above. In most cases, the information is there already: development velocity is measurable, high turnover and chronic absenteeism are hard not to notice, burn rate and runway are dead-easy to track, remaining scope is quantified and visible, team morale is largely qualitative but observable, player feedback (if acquired correctly) is available to all. So what’s compromised is the ability to process that information dispassionately.

I propose three simple questions to help you cut through the noise.

Have players outside your team confirmed the core is engaging? Studios spend years in production without running a single meaningful playtest with people who don’t already know the project. A real session with strangers who fit your target audience but that aren’t paid by you and aren’t early advocates on your Discord server, will show you right quick whether what you’ve built is interesting to play or not. That data is cheap to obtain and rarely obtained early or often enough. I’ll expound on this later, but the absence of good and recurrent playtesting is, in my experience, the most consistent factor in situations where a studio gets deep into production only to then discover that the game isn’t working. It doesn’t have to and it really shouldn’t be like this.

Can this game be made into a good one with what you currently have? Not eventually, not with more funding, or more time, or yet-to-be-hired silver bullet of a developer that will make it all make sense, or a lucky breakthrough of some kind. With the team, resources and timeline you actually have. If the path to a good game requires inventing capacity you don’t have, then the answer is no. The core loop, the thing someone who knows nothing about the project would experience typically in the first few minutes (maybe longer, depending on the type of game), needs to be reasonably engaging with what exists today or with incremental work that’s realistically completable very soon. If you need a fundamental redesign of the vision to get there, you’re solving a concept problem at the most expensive phase in the production lifecycle. Like I said, iteration is reasonable and very, very much expected in game development. Complete reboots, from the ground up, are not. So if you’re looking at the latter, then you need to be extremely deliberate and judicious about if and how to continue.

Does your team still believe in what they’re building? Sundae Month, the indie studio that eventually shipped Pupperazzi, canceled two games before finding the right project. What’s striking in their account is that by the time the decisions were made, half the team had burned out, and they were running thirty-two-hour weeks. The burnout wasn’t from overwork but from working on something that had lost direction and was hard to believe in. When the people doing the work have stopped believing in the project, what you’re really asking at that point is: can the team deliver this anyway? As you can imagine, that tends to produce worse games.

If the answer to those three questions is yes, then there’s merit to keep going, to keep fighting. Of course, these decisions are nuanced, contextual and multifactorial (perhaps your answers to these questions were yes but maybe you’re out of money, or an 800 lb gorilla in your genre just released a game that makes it impossible for yours to be profitable), but at least you have an argument to grind it out.

Why teams don’t pull the plug when they should

Even when the indicators are plain to see, you understandably have doubts, you’re worried that canceling the project is akin to quitting, to throwing the towel too early, to giving up on your dreams, or just a huge mistake on your part, so you’re struggling to make a rational over an emotional decision. It’s legitimately not easy.

In my opinion, there are five distinct reasons why projects that are clearly not going anywhere stay alive longer than they should.

The first is escalation of commitment. This is the proverbial sunk cost fallacy in its broader form. Every decision to continue builds a case for the next one. Stop in month six and you’ve lost six months of investment. Stop in month eighteen and you’ve lost eighteen. The psychological cost of stopping grows with each passing sprint, which makes what might look like perseverance from inside the project functionally indistinguishable from being trapped by it.

The academic literature on this is pretty consistent: when people feel responsible for an initial decision, they tend to allocate more resources to a losing course of action precisely to justify the initial decision.

The second mechanism is about perception. We overvalue things we’ve built ourselves. Not because we’re irrational, but because the labor has legit emotional weight for us and the brain calibrates value accordingly. Researchers call this the IKEA effect. A developer who has spent two years on a project, building every system, living with every mechanic, has a fundamentally distorted view of whether the game is engaging to play for the first time (there’s a great section in this article, called the The echo chamber of expertise, expounding on this). This is a perceptual distortion created by investment, not self-deception. It’s a thing. As unintuitive as it may sound, the team is sometimes the least qualified set of people to assess whether the game is fun or not.

The third is organizational silence. In any group, the first person to bring up a problem takes the social risk. In a studio built around a founder’s creative vision, that risk is significantly amplified. Challenging the game means challenging the person who conceived it. Good luck with that. Research on this is clear about the most common reason people stay quiet: fear of being labeled negatively and damaging valued relationships. In game development, that translates to the person who says the game isn’t working getting treated as a defector, a morale problem, someone who isn’t committed or just doesn’t “get” the game. So people stay quiet and wait for someone else to take the plunge.

BioWare had a name for the cultural belief that let Anthem get as far as it did. They called it “BioWare magic.” Do you remember? It’s the belief that things would come together in the final stretch, the way they always had before. This isn’t without some degree of truth, admittedly (I’ve seen it happen multiple times myself), but the team, by multiple accounts, didn’t know what they were making well into production. Yet, the belief held that the pieces would “automagically” fall into place. The people who worked on Anthem’s final production later described months of stress leave and mental health crises so pervasive that they required formal acknowledgment from EA.

The fourth is lack of gameplay feedback. I mentioned earlier that studios sometimes spend years in production without validating the game with well-structured playtests. Well this IS one of the reasons why teams don’t pull the plug: shying away from feedback. Putting your game in front of other people can make the entire studio very vulnerable, and if the results aren’t good it can feel like a very definitive verdict. Unfortunately, this is part of game development.

If you don’t get data from players on what’s working and what’s not, you’re just rolling a dice.

And the fifth is that for most indie studios, canning a project means having to close the studio. Even if you’re perfectly aware that the game is not working, most studios just don’t have the runway to pivot. There’s typically no war chest to support another concept discovery phase, another first-playable, and another fundraising cycle. In that context, pushing forward on a struggling game starts to look much more rational. You’re preserving the team, buying time, maybe hoping that you roll a 20 and the game finds an audience. It’s a very understandable response. And hey, every blue moon, the game does succeed against all odds, and that makes those extra-special.

The cost of not making this difficult decision

Before talking about how to make the difficult decision of stopping a game in production, let me touch on what I think the real cost is of not making this decision: time. Human time.

The time of the people on the team on this Earth is not a renewable resource. Let’s math it out together. Say you graduate at 23 and you work in games until you’re 65. That’s 42 years of professional work. The first 5 years you’re doing a fair bit of grunt work, the last 10 or so years you’re probably operating at a very strategic, perhaps executive level, more detached from the game itself. That leaves you with 27 years. Of those 27 years, at least 10% are going to be spent being unemployed, or working for an awful company that you’re actively trying to get away from, or working on games that are, well, bad. So that leaves you with about 24 good years of creative output (red bracket in the image below).

That red bracket is 4 Hollow Knights, or 4 Undertales, or 5 Spelunkys, or 5 Dead Cells cycles. Or if you want to look at it from the less successful perspective, that’s two Duke Nukem Forever or one and a half Beyond Good & Evil 2 games.

Do you really want to spend say, 25% of that incredibly short time on something that you can clearly see is not going to be good, or that no one will play, or that is a shameless copycat or cash grab, or that is highly unlikely to actually ship?

We think a lot about jobs, and financials, and our creative dreams. As we should. Those things matter a great deal. But when we embark on a journey nowhere, the main cost that we pay is in human time. So when doubt creeps in and you know what needs to be done but you’re struggling to make the call, factor in the precious, extremely limited time that you and your developers have available.

Making the decision

Most of what makes this call so hard (the escalation, the distorted perception, the silence) comes from needing to call an audible at the worst possible moment, years in development, with likely most of the money already spent, and everyone downright exhausted. I would therefore suggest that you don’t improvise and instead define the cancellation criteria in advance, in preproduction or right when funding closes, while you can still think straight, while you’re not clouded with emotion and while your identity is at least not that attached to the game.

Those criteria are conveniently the three diagnosis questions from earlier, made measurable, plus a hard minimum for the money. A page is enough.

1. Outside validation: define who counts as a real tester (strangers who fit your target audience, not friends, not fellow devs), how often you put the build in front of them and what result counts as a pass. For example: by MVP1, most first-time testers finish a session without prompting and a few ask to play again. Write the miss condition too, in advance, so nobody gets to reinterpret a bad session later.

2. A path forward with what you have: the work remaining to reach a fun core loop has to fit inside your actual team, actual velocity and actual runway. Check the milestone plan against what the team delivered in the last three months, not against the original roadmap’s wishful thinking.

3. Team belief: there’s no number for this one, so write down the behaviors you’ll keep an eye out for instead. People going silent when problems come up, brainstorms that used to run long now ending early, the turnover and absenteeism from the indicators at the top of this article. It’s not inconceivable either that you may run an anonymous survey with the team to get a pulse from them on how they see the project.

4. The money: the runway level at which, if the lines above are being missed, the project needs to stop. If winding down with severance and dignity would cost you three months of payroll, the financial floor needs to be above that number, not at zero.

Be specific, because eighteen months from now a tired team with potentially millions sunk into the project will find a way to lawyer its way around anything that’s vague.

Then schedule the reviews before you need them, because a review you only call when things feel bad will always come too late. Production gates are the natural slots (first playable, MVP1, MVP2, Closed Beta, etc.), since fresh evidence exists at each one anyway. In full production I’d default to roughly every three months (more often if it’s a smaller game, less often if it’s a larger game). The review itself is a meeting, and an hour is usually plenty. You, your leads and at least one outsider you trust go through the page line by line with the evidence in front of you: the latest playtest results, the runway sheet, what changed since the last review. It ends with a simple verdict, continue, correct course or stop, and the reasons behind it. Of course, if the outcome is stop, that’s understandably going to lead to more conversations, further review, etc. That’s to be expected.

Supercell has a similar approach. Their teams take a game into beta knowing what it has to hit, and if it misses, the team itself makes the kill call, not management. The team behind Smash Land killed it in 2015 after talking it through over beers and a sauna session, and then told the CEO. Ilkka Paananen later told a BAFTA audience that the team “didn’t even bother to consult me, which is brilliant.” Of the ten projects Supercell ran before Clash Royale, seven died at prototype, two more died in soft launch and one shipped worldwide.

That may sound like it contradicts what I said earlier about the team being the least qualified to judge their own game, but it doesn’t, because those teams aren’t trusting their feelings. They’re reading player data against targets that were set before anyone had something to defend. You’re not Supercell, and a premium indie game doesn’t live or die on beta retention curves the way mobile free-to-play does. The mechanism still makes sense: agree on the bar before the dev team falls in love, and anchor the verdict to player feedback rather than to the people who develop the game.

If you run the studio, the IKEA effect doesn’t spare you for having the biggest title. You greenlit the project, championed it to investors and defended it through every rough milestone, which arguably makes you the last person who should be reading the playtest results alone. So give someone with nothing sunk into the game a real seat at the review: an advisor, a board member or a founder friend from another studio.

Blizzard ran the opposite experiment. Titan’s game director Jeff Kaplan went to Mike Morhaime in 2010 and proposed shutting the project down. Leadership said no. Titan limped on for four more years and Blizzard finally canceled it in 2014, seven years of development in total, with an explanation that I would wager Kaplan was well aware of back in 2010: “We didn’t find the fun. We didn’t find the passion.” Blizzard had World of Warcraft underneath them to cushion a miss that size, and the wreckage eventually and happily became Overwatch. A studio without that cushion doesn’t get to amortize a seven-year mistake into its next hit.

All of this assumes the decision is fully yours to make. If a publisher is funding the game, part of it belongs to them, and the contract you signed before anything went wrong has a lot to say about what stopping even means.

If you have a publisher deal

The typical publishing agreement does not recognize “we’ve concluded this game can’t ship” as a decision you get to make. Termination for convenience, the right to walk away with notice and no cause, almost always belongs to the publisher alone. Your side of the deal is a delivery obligation. So if you stop delivering, you’re not canceling the project, you’re defaulting on the contract, and default usually means repaying every advance, sometimes with the publisher entitled to take the game, source code included, and finish it without you.

That’s the average deal. Raw Fury made their standard contract public in 2020, and it has a reputation as the developer-friendly one. Even there, you’ll find no developer-side exit. Delivery by the final date is “of the essence of this Agreement,” and missing it is material breach. On an uncured breach, Raw Fury chooses the remedy: you repay all the funding to keep your rights, or every right to the game transfers to them free of charge and they can finish it with another team. Conversely, if Raw Fury terminates for convenience, you repay the funding out of the game’s future revenue only. A canceled game that never earns another cent leaves you owing nothing, and the advance never turns into a debt with your name on it. Most deals you’ll see handle both of those worse than this one does.

So can you cancel at all? Not unilaterally, no. What you can do is negotiate a mutual termination, and the case you bring to that conversation is the one from the previous section: the playtest data, the runway, what a credible path forward would actually cost. Publishers fund portfolios, and they don’t want to keep paying milestones on a game that simply won’t succeed. A wind-down where they recover something beats pushing a studio into default and litigating over the remains.

When publisher Starbreeze collapsed financially mid-deal, OtherSide got the System Shock 3 publishing rights back in exchange for Starbreeze recouping its development costs. In this example, the publisher was the one in trouble, not the game studio, but the unwind works the same way. If that negotiation doesn’t happen, then you get something like Take-Two suing 3D Realms over Duke Nukem Forever’s twelve-year death. Or you get TimeGate Studios, which lost a $7.35 million arbitration to its publisher, lost the Section 8 rights with it and closed within a month.

The best exit you can probably get is the one you proactively negotiate before signing, when you still have leverage and nobody is upset. It’s the same move as the kill terms but made before you need it. Games lawyer Kellen Voyer analyzed thirty indie publishing agreements and found that 81 percent require the advance to be recouped, 42 percent in full before the developer sees a single royalty dollar. So don’t expect the default paperwork to be built around your risk management needs. Ask who can terminate and for what. Ask what happens to the advance if the game dies (push for repayment tied to the game’s revenue rather than turning into debt) and where the IP and the source code go in each termination scenario. And negotiate hardest on exactly the clauses everyone at the table hopes will never fire. Rami Ismail has a solid list of publisher contract red flags. I wrote about this too, as well as what you can expect from different funding partners. I encourage you to give those a read before you sign.

If you’re already mid-production on a funded game that’s in trouble, talk to the publisher early rather than last. They see your milestone builds, so they probably already know. Walking in with the evidence and a wind-down proposal before they reach for the termination clause is the difference between negotiating the exit and litigating it.

And then there’s the conversation that’s harder than any contract, the one with your team.

Ownership and transparency

An old mentor of mine said to me once: “Seb, leadership is not that complicated. You just treat people the same way you want to be treated“.

It should go without saying that when and how the team finds out that the game is being canceled is a reliable indicator of the studio’s leadership, culture and values.

If the studio has been transparent throughout, the conversation is hard but reaches everyone with context. Unless the driver for the decision is financial, the team has already been seeing the same indicators and an announcement would just confirm what people were already intuiting.

If the studio has been keeping quiet about challenges, with the hopefully well-intended but deeply misguided notion of maintaining morale or stopping people from leaving, you should of course expect that the cancellation will be a shock to the team. The director of The Last of Us Online, Vinit Agarwal, led that project for seven years before Naughty Dog canceled it. Very recently in an interview, he explained that he found out a mere twenty-four hours before the public announcement. Seven years, and twenty-four hours’ notice. While there could be many reasons why this happened, suffice to say that’s not great.

There’s a very reasonable argument for choosing not to expose financial information. A poorly timed disclosure can indeed create a departure spiral that can doom a game. But managing information carefully is different from keeping the people whose livelihoods are at stake in the dark until the decision has already been made and publicized.

When someone’s career and livelihood are on the line, transparency is owed. It’s just what’s right. So, what do you do when you know you’re putting a project in development on the back burner? You go talk to the team. With candor, with humility and with the most concrete plan you can put together for what comes after. It’s not easy, but it really just boils down to that.

What comes after

In most cases, a canceled game means layoffs. Unless the team is very small or the studio has reserves, holding everyone together through a pivot is rarely financially viable. That’s the difficult reality, and the people on the team deserve the truth rather than optimistic framing about pivots that aren’t actually funded.

For the studios that do survive and can start something new, the path usually involves going back to the beginning: a smaller team, protected runway and a return to brainstorming and feasibility analysis, which is hard enough as it is. So it’s even harder when people are carrying the weight of something that didn’t work, trying to find the energy to believe in the next thing.

The psychological toll tends to be underestimated by the people who aren’t experiencing it. Cancellation handled badly, with poor communication or unclear reasoning, creates a trust problem that outlasts the project itself. The next pitch, the next production, the next time leadership asks the team to commit to something uncertain, they’ll be doing it with people who remember well what happened the last time.

In closing

If the game isn’t working, and you can feel that it isn’t working, the industry’s default response is to push through. Ship something, get it out, learn from the process. There’s undeniable value in that. But that reasoning can also become a justification for spending another year or two of people’s time on something that’s already lost.

Some studios, in my view, would be better off stopping. Not because stopping is easy, or because it doesn’t cost anything (it might just cost you the studio), but because the alternative costs more than what shows up in any financial model. As mentioned, a team grinding toward a finish line on a game they’ve stopped believing in is paying in the one currency that can never be earned back: time.

Have you ever had to cancel a game? Have you been part of a dev team in a project that was canceled? Share your experience below.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

Let me start by preemptively stating that this is not a standard article. It’s a 12 thousand word field guide to live ops for video games. So I encourage you to treat it more as a reference to work with and come back to than as a singular piece that you read once. I touch on things like the decision to run a game-as-a-service, the team that you need, the tech, metrics, cadence, the content treadmill, pitfalls and how to shut it down well.

Strap in.

A premium game has a finish line. You ship it, you fix the worst of what players find in the first few weeks, and then you’re mostly free to move on to the next thing. A live game has no finish line. You ship it and the work resets to something akin to day one, except now there are players in the game expecting you to keep showing up, on a schedule, more or less in perpetuity. I spent almost four years running production for one of the largest live games in the world, and the hardest adjustment for me was not technical, but more in the lines of learning to accept that “done” was no longer a state the project would ever reach. It’s a surprisingly counterintuitive thing to have to wrap your head around.

This is a primer on running a live game on PC and console. It’s definitely not about mobile. Mobile free-to-play is a somewhat related but fundamentally different business, built on buying installs by the million and earning a few dollars from each across a huge funnel, and most of what gets written about “live ops” comes from inside that business. A fair amount of it will lead a PC or console studio straight into decisions that their audience will rightfully punish. I will point those out as we go.

The reader I have in mind for this is a relatively small indie studio (not a 300 people technically independent studio working on a $200M project) either considering a live game or already building one, trying to proactively plan that operation.

What a live game is

Let’s start with the terminology, because the words get used loosely and the looseness regularly causes confusion.

A live service game, or games as a service (GAAS), is a kind of product. It is a game built to be updated and supported for a long time after release, earning revenue on a continuing basis rather than once per copy. Live ops, short for live operations, is the practice of actually running that product day to day. Put simply: live service is what you build and live ops is how you run it. One is the thing, the other is the job. This primer is mostly about the job.

The reason the category feels slippery is that the term has two different histories that pull in slightly different directions. One history runs through the persistent online worlds: text MUDs in the late seventies, then the subscription MMOs like EverQuest and World of Warcraft, then Team Fortress 2 in 2008 funding free content updates through cosmetic items, then the MOBAs adding a new character every few weeks for a decade (the heritage is reasonably well documented). In that history the game is deep, the sessions are long, and the content is the product.

The other history runs through mobile and the Chinese free-to-play market, where the model was built to acquire enormous audiences cheaply and earn a little from each, with short sessions and reward systems engineered to bring people back daily and get them to spend compulsively and progressively more and more.

Both call themselves live service, but they are absolutely not the same business. A PC or console studio that picks up the vocabulary without noticing it was largely written for the second history will import mobile gaming’s product management practices: time-limited offers, daily login pressure, randomized purchases, progression you can pay to skip. PC and console players, on the whole, detest those things and will say so loudly and in public. So the first useful distinction here is that when I talk about a live game here, I mean the first history, adapted for a premium or fairly monetized PC and console audience, and I will treat the mobile playbook as a cautionary reference rather than a manual.

Besides mistaking mobile gaming’s live ops practices for viable PC/console gaming live ops, there is one more way the live category surprises first-time studios. A live service game tends to take much longer to build than a finite one. In a 2023 survey of more than 500 studios, a reported 95 percent were building or maintaining a live service game, and the same work found these games take upward of five years to make against two to three for a traditional title. You are not adding a few months of post-launch patching to a normal project, you are signing up for a different type of game company. More on this below.

What live ops is

To explain this, I borrow an analogy from Stewart Chisam, who used to run Hi-Rez Studios and shipped several of these. He describes a boxed game as a movie: fully formed in the creator’s head, delivered in one piece. A live service is more like a TV series: you commit to developing it season by season, alongside an audience that is watching and reacting in real time, for as long as the show stays on the air. The work of live ops is the work of running a writers’ room and a TV network operation all at the same time, indefinitely.

Concretely, the job is a handful of recurring functions and activities that never stop:

• Shipping content and changes on a schedule. New things to do, new things to earn, balance adjustments, bug fixes, events, etc. Studios look at this work and regularly overestimate how much of it they can sustain.

• Operating the service. Keeping the servers up, the logins working, the matchmaking healthy, the cheaters out. Another enormous amount of work that studios tend to underestimate.

• Watching the game through data. This is basically telemetry on what players actually do, so you can see problems and decide what to change.

• Running the community. Talking to players, absorbing feedback, managing the public conversation, especially when something breaks.

• Supporting players. Tickets, account problems, refunds, ban appeals.

These are five disciplines if you will that each need an owner, they need to work together in concert, and they don’t stop until you sunset the game.

Deciding to run one

A lot of studios end up running a live game without purposefully deciding to. They add an online mode, or a season, or a cosmetics shop, and suddenly find themselves a year later running an operation they didn’t deliberately staff for, and on a schedule the original production wasn’t quite designed for. So the first piece of advice, as painfully obvious as it may sound, is to make the decision concertedly, early, with the costs made explicit, rather than waking up one day inside the live ops maelstrom.

Perhaps the single best question to ask comes from Scott Hartsman, who helped build RIFT and ran Trion Worlds. His test is to make someone explain why the game cannot exist without the online component. If the live, online, ongoing nature of the thing is foundational to why it is fun and engaging, then you may have a real reason to have a live game. If it’s bolted on because live service is where golden geese tend to be found, you have chosen poorly. Hartsman is blunt about how this goes wrong at big studios, with that now patented reflex of “we’re selling boxes, we need some of this live service action.” That reflex is how you get a game like Concord, eight years and a reported fortune spent, shut down two weeks after launch.

A few important things to weigh while you decide, all from people who have run these games:

The market is winner-take-most. Hartsman’s take is that the top two or three titles in a genre capture somewhere around two thirds to four fifths of the activity and the revenue, and that once a game dominates a category it’s very hard to unseat. Observationally, this rings right to me.

A new entrant has to be good enough to pull players off the game they already play, not just good enough to exist. This is a very important distinction that gets lost in the enthusiasm to make an exciting new game.

Most games, by Chisam’s rule of thumb, make somewhere around thirty to fifty cents of gross revenue per hour played, and that is before the platform takes its thirty percent and before you pay for servers and salaries. At a small player count, that thin margin does not come close to covering the cost of running the operation. You only get into the black once enough people are playing enough hours, and plenty of games never reach that point. So this tends to be an all or nothing proposition, not so much a spectrum of success.

The team gets bigger after launch, not smaller. This is a cost many studios underestimate. A finite project ramps down as it ships. A live game, if it works (and that’s a big IF these days), needs more people after launch than before, because now you’re building content in perpetuity and running the service and supporting the players all at once. You are not finishing a product, you are propping up a permanent operation.

And one piece of preparation to do deliberately rather than by accident: before you commit, it’s critical to codify your strategic operation. How often you intend to ship, who owns the service when it breaks at 2am, and what the smallest sustainable version of the operation looks like. The studios that plan the operation judiciously, meticulously and intelligently give themselves a much better chance to survive, whereas the ones that improvise it risk burning out both the team and the players.

The rest of this primer is the detail of what that operation entails.

Getting ready to go live

A finite game ships a build and is done. A live game ships an operation that has to survive an engagement spike that is very hard to predict and then, hopefully, if everything goes well, run for years. This readiness work is different in kind from anything a premium-only team ever has to do.

Start with the thing every launch story teaches: you cannot predict the player engagement spike. Arrowhead built the Helldivers 2 servers to handle a quarter of a million players and got more than 450,000, with a peak of 458,709 on Steam alone. The instructive part is what the studio’s head, Johan Pilestedt, said about the fix. It was not about money or buying more servers, he explained, it was about labor, about optimizing the backend code. The thing that fell over was not raw computing power, but what engineers call the stateful path. Some requests a server can answer and immediately forget, like handing out a menu or a store page. Those are easy to scale because you just put more identical servers behind them. Other operations have to read and write data tied to a specific player, data that has to stay consistent: logging in, your account, your inventory and currency, your place in a match. All of those funnel into shared databases and session services, and that shared state is the real bottleneck, because you cannot fix it by bolting on more machines. So the lesson to take into launch is to load-test that path, the logins and the saves and the matchmaking, far harder than the parts that just hand out the same data to everyone, because the stateful path is what seemingly buckles first.

A useful readiness checklist.

Capacity planning and graceful degradation. Capacity planning means knowing your ceiling before launch night: how many logins per second the system can take, how many concurrent players one server or shard holds, how much your database can write per second. You find those numbers by load-testing, not by guessing. Graceful degradation is what the system does when it hits those ceilings anyway. A well-built service under overload sheds or slows its least important work and protects the core, so instead of the whole thing crashing, new logins wait in a queue while the players already in the game keep playing. A queue is a far better way to fail than a hard crash that throws everyone out at once, which is what turns a busy launch into a catastrophe. So design the degradation on purpose: decide ahead of time what gets queued, what gets throttled and what stays protected whatever happens.

A real load test. You cannot find your ceiling by hoping, so you simulate it. The standard approach is software-driven bots that imitate real players hitting your backend, not just connecting but doing what players actually do at launch: logging in, retrying when it fails, forming and breaking parties, writing progression to the database, hammering the store in the first hour. You start at a manageable number, around a thousand simulated players, find what breaks, fix it, then double and repeat until you reach your target, using load-testing tools like Gatling or JMeter and rented cloud machines to generate the traffic. Riot has written publicly about doing exactly this for VALORANT. And the most realistic load test you will ever get is an open beta, a real population behaving in ways your bots never quite predict, which is why you run one months before launch while there is still time to fix what it exposes.

Runbooks and an on-call rotation, written before you need them. A runbook, sometimes called a playbook, is a written step-by-step procedure for a known kind of incident. E.g.: if the login database is filling up, here are the five things to do and the order to do them in. Google’s SRE book found that a good, up-to-date playbook cuts incident response time sharply, because the engineer who gets paged at 2am should not be improvising from scratch. The on-call rotation is the schedule of who responds when, decided calmly in advance instead of thrown together when the pager goes off (the being-on-call chapter is the standard reference). Scott Hartsman uses exactly this, do you have an on-call list and a rotation, as his test for whether a studio is ready to operate at all. Big studios formalize the whole thing into a NOC, a network operations center, a staffed function watching the live service around the clock. You do not need any of that overhead. You need the function: a rotation, dashboards someone is actually watching and runbooks they can follow. Then validate the runbooks with a dry run, and confirm ahead of time that whoever is on call actually has the access and credentials they will need at 2am, because finding out they do not, mid-incident, is a small catastrophe.

A war room plan. For a serious incident you want roles assigned before the chaos, not during it. The widely-copied model, again from Google’s incident management practice, splits the work three ways: an incident commander who runs the response and makes the calls, a communications lead who talks to players and keeps everyone outside the war room informed and an operations lead who actually does the fixing. Add whoever owns the written timeline, so you can reconstruct what happened once the dust settles. At a small studio one person wears two of these hats, which is fine. What is not fine is working out who is in charge while the servers are already down.

There is also a console-specific constraint that reshapes everything else, and oftentimes catches PC-native teams off-guard: you cannot hotfix a certified console build the way you patch a server. Console certification takes days to weeks, and you book submission slots well ahead. This is the single biggest reason to design the game so that as much as possible can change on the server side, through configuration and content delivery, without shipping a new client. On console, server-authoritative design is not an architectural preference but how you stay able to fix your game at all.

The day you go live

Launch day is the operation’s first real test, and it tests a short, specific list in a fairly specific order: can people log in, can the servers hold the crowd that shows up, can you move players around once they are stuck and can you keep your head and your communication straight while you fix whatever breaks. The cheapest way to learn what that list looks like is other studios’ launches, because almost every one of them broke in an educational way. Here are four, each pinned to something that should help you prepare.

Diablo III in 2012 required Blizzard’s servers even for single-player, the servers could not handle the connection storm, and a generation of players learned the phrase “Error 37.” The fix was a simple login queue. The lesson is that the login system is commonly the first thing to fall, and serializing load behind a queue beats disappointing ALL of your players.

Final Fantasy XIV teaches two lessons in one franchise. The original 2010 release shipped broken at the foundation. Square Enix had built a studio culture that emphasized graphical fidelity over the basics of running an MMO. It went so far that a single in-game flowerpot used over a thousand polygons and a hundred and fifty lines of shader code, about as much as a player character, which forced the team to cap the number of players drawn on screen at around twenty. You can’t really patch your way out of a foundation like that. So Square Enix took the rare step of shutting the game down, replacing its leadership and rebuilding from scratch on a new engine (not that the engine was the problem). The relaunch, A Realm Reborn, then hit the other kind of launch problem, the survivable kind: too many players, servers full, character creation switched off for a while to shed load, all of it recoverable within days. So here are the two lessons: some launch problems are structural, baked into the architecture, and the only real fix is to rebuild from the ground up. Yikes. Others are more in the lines of capacity problems, and the solve is to shed load and ride it out while you scale. Being able to tell which one you are staring at on launch night, a broken foundation or a flood of players, can be the difference between a bad week and a dead game.

New World in 2021 showed the shard problem. A shard is a separate copy of the game world running on its own server with its own population, where players on one shard cannot see or play with players on another. New World capped each shard’s population, the queues to get onto the busy ones ran for hours and players who had rolled characters on a given shard were stranded there, because there was no way to move a character to a different one. Amazon had to build free character transfers in a hurry after launch. The lesson is that if your game splits players across shards, the ability to move them between shards has to exist before launch, not after.

Helldivers 2 affords a subtler, self-inflicted lesson. Arrowhead raised the player cap in careful steps rather than all at once, to avoid a full meltdown, and they offered double experience as an apology, which pulled even more players onto the overloaded servers and made things worse before it got better. The lesson in this case is that a launch-day incentive is also a load event. A reward that brings lapsed players back is a reward that floods an already-straining login system, so before you run any launch promotion, work out what it does to your concurrency and whether the servers can take the crowd it will summon.

The two threads running through all four are that preparation is king and that the first seventy-two hours are about triage and communication, not feature work. You watch the dashboards (the monitoring section below covers what those are and how to run them). You ship the smallest fix that helps. You tell players what is happening on a fixed schedule, even when the update is still “no change, investigating.” And you do not make big, hard-to-reverse decisions about the next six months while running on adrenaline and no sleep. The deeper post-launch decisions belong to a calmer week, which is the rest of this primer.

Indie scale and large scale

Live ops is fairly similar at five people or at five hundred. What changes is whether each function is a dedicated person or a hat someone wears on top of their official job.

Hartsman puts it well. A studio of five to twenty runs on individual ownership and initiative, everyone doing several jobs and deciding things directly. An organization of thousands runs on specialists and formal process and consensus across departments. Moving from a finite project to a live operation is, in miniature, the start of that journey from the first toward the second, because the live operation adds standing functions that have to be owned by someone even when the studio is tiny.

For a small studio the move that makes this more survivable is to “buy the operation” rather than build it. For instance, one senior engineer owns the backend and the on-call phone. Maybe the producer is also the live ops producer. Or community and support are one person, or are partly handed to a contractor. Analytics maybe is a managed tool, not a hire. So you effectively assemble an operation out of bought parts and worn hats, and you accept that you will run a leaner operation than a big studio runs with entire multidisciplinary teams.

The one thing that does not scale down at all is around-the-clock coverage. Five people cannot run a real 24/7 on-call rotation, because they also have to sleep and build the game. So the realistic indie model leans on two things from the readiness checklist. The first is managed, hosted infrastructure that carries its own uptime guarantees. The second is a service designed to degrade safely, so a failure at 3am queues players or drops a non-essential feature rather than corrupting accounts. You accept that some incidents wait until someone is awake, and you say so on the status page. Buying managed services here is not laziness, it is how a team that has to sleep survives nights and weekends.

But the trap cuts both ways. Some small studios ignore an entire function, usually data or support or security, until things go sideways, and then they have to scramble. Others do the opposite, trying to stand up a miniature AAA operation, a dedicated person for every box, on a budget that cannot bankroll it, and they starve the actual game to pay for an org chart that is financially too demanding.

The skill at small scale is holding every function as a clear responsibility while staffing almost none of them as full-time roles. The next two sections, on people and on technology, are about which parts to buy and which hats to insist someone wears.

The people and competencies you need

As mentioned, a finite project staffs to ship, while a live operation staffs to run forever, so that adds roles that simply did not exist on your premium game dev team. At a big studio each is a team. At a small studio each is a responsibility someone has to actually hold, even if part time.

Live ops producer. Owns the post-launch calendar: seasons, events, the patch schedule and the coordination across design, data, community and engineering that a steady release rhythm needs. Most studios discover they are missing this role right after launch, when the calendar suddenly needs an owner and nobody has the job.

Data analyst. Turns the telemetry into decisions. Concretely, this is the person who reads the retention curves, the churn, the progression funnels and the in-game economy and suggests to the team what to change and why. It is a different skill from the engineer who built the data pipeline, and treating them as the same hire is a common mistake.

Backend, DevOps and Site Reliability Engineering (SRE). These are the people who keep the service running. In plain terms, that means making sure there are enough servers for the players who show up and scaling that up and down as the numbers move (capacity), shipping new code to the live servers without breaking them (deploys), being the dedicated person who answers when something breaks at an awkward hour (on-call) and handling the outages themselves when they come (incidents). A finite project has gameplay, engine and tools engineers. A live one needs these reliability people on top.

Community manager. Two jobs in one. Outward, they are the studio’s public voice: running the official Discord, forums and social channels, posting patch notes and status updates and staying calm and present when something breaks. Inward, they are the filter that turns the flood of player reactions into the few things the team actually needs to act on, so the developers hear the real problems and not just the loudest ten posts.

Player support. Tickets, billing, ban appeals, refunds. Scales with your active player count and is frequently outsourced by small (and I’d argue also large) studios.

Economy or season designer. For any game with currencies, seasons or a recurring content loop, someone has to design that loop. Their job is to build a satisfying rhythm of goals and rewards for players, not to engineer how to siphon more money out of them. The moment that role’s goal flips to the second thing, you have started building the mobile game your audience on PC and console loathes.

Anti-cheat and security ownership. Even if you buy an anti-cheat product, someone has to run the detection tuning and the ban process. It is an ongoing job, not a one-time integration.

For a small team, the reality is that one or two people will hold several of these at once. That’s fine, and it’s normal. What is not survivable is pretending the roles don’t exist because no single person has the title.

The technology you need

For a small studio, the technical advice that saves the most pain is fairly simple: buy the commodity backend, and build only the gameplay logic that makes your game your game. Identity, matchmaking, leaderboards, player storage and a telemetry pipeline are (relatively) solved problems with mature off-the-shelf options behind them, and building your own from scratch is a multi-year engineering effort that has nothing to do with why your game is good. This is the live ops version of “we’ll make our engine”. I’ve seen teams fall horribly behind on the development of the actual video game because they focused instead on creating custom backend solution. Suffice to say that’s not good bang for buck. Rent the plumbing, and spend your scarce engineering on the systems only you can build.

What the operation needs, and the affordable way to get each:

A backend platform. This is the off-the-shelf foundation that handles accounts, matchmaking, friends, leaderboards, saved progress and the rest, so you do not have to build them. Epic Online Services is free, works across PC and the major consoles, and covers accounts, friends, lobbies, matchmaking and voice, with anti-cheat included, which makes it the sensible default for a small cross-platform game. Nakama is open source and self-hostable, for teams that want to run their own server and write their own authoritative logic. PlayFab, now part of Microsoft Azure, and AccelByte are fuller, more managed platforms aimed at bigger or perhaps better-funded teams. Steamworks gives you a capable backend for free, but only on Steam, so it rules out cross-play with consoles or other PC stores.

Dedicated servers or peer-to-peer. This is the choice of where a match actually runs. With dedicated servers, the studio runs authoritative machines that host every session and have the final say on what happened, which is what you want for competitive games, because it is much harder to cheat against a server you do not control. With peer-to-peer, one of the players’ own machines hosts the session and the others connect to it, which is far cheaper since you are not paying for those servers, and it is common for co-op and PvE games. The catch, and this is something so many studios get wrong, is that peer-to-peer does not mean serverless. Helldivers 2 hosts its actual missions peer-to-peer on a player’s machine, but still runs a central backend for matchmaking, the galactic war, purchases and progression, and that central backend is exactly what fell over at launch. Even a peer-to-peer game has an operation to run.

Live ops tooling: changing the game without shipping a new build. This is the set of tools that let you adjust a running game from your side, without players downloading a patch, which is what makes a fast live operation possible (and on console it is close to essential, because a new client build means waiting on certification). There are three pieces to it. Remote config means key values live on your server rather than baked into the client, so you can retune a weapon, change an event’s rewards or fix a bad drop rate by editing a setting, and every player gets it on their next connection. Feature flags are on-off switches wrapped around a feature, so you can turn it on for one percent of players, watch what happens and flip it off instantly if it misbehaves, without recalling anything. Content delivery lets a new season or event arrive as data the running game downloads at runtime, rather than as a fresh executable. Together these turn “we need to fix this” from a days-long client patch into a minutes-long server change.

A telemetry pipeline. Telemetry is the stream of events your game reports back as people play: this player logged in, bought this, reached level twelve, ran around in this part of the map, crashed here. A pipeline moves all of that somewhere you can use it, and it runs at two speeds. The real-time path feeds operational dashboards and alerts, the “is anything on fire right now” view. The batch path loads everything into a data warehouse for slower questions, the “are players quitting at level twelve and why” analysis. Building this yourself is a real project (the standard cloud architecture is well documented if you want to take a look), but a small studio does not have to. A managed analytics tool like GameAnalytics ingests your events and gives you retention, churn and spending dashboards out of the box, with no pipeline and no data engineer required.

Anti-cheat. If your game is competitive, you buy this, you do not build it. Easy Anti-Cheat ships free through Epic Online Services and powers a long list of big games. BattlEye is another common choice. Either way, know what you are signing up for: anti-cheat is not just client software that blocks cheats, it is also server-side detection plus a ban pipeline that someone has to operate, tune and keep updating against new cheats, indefinitely. It is an ongoing job, not a one-time integration.

Observability. Observability is your ability to see what your live system is doing from the outside, so that when players report a problem you can find it rather than guess at it. In practice it surfaces three kinds of data: metrics (numbers tracked over time, like server latency, error rate and concurrent players), logs (timestamped records of what happened) and traces (following a single request as it moves through your services). Prometheus for the metrics and Grafana for the dashboards are the free, capable standard if you have the engineering skill to run them. Datadog and tools like it cost money and bundle all of it together, and they earn their keep on the night an incident is unfolding and finding the cause fast is worth far more than the bill.

The whole point of buying all of this is that a tiny team can then run a real operation. You are spending money to avoid spending years.

Monitoring

Once the game is live, running it means watching it, continuously. Monitoring is how you learn something is wrong from your own instruments, ideally before a wave of players finds out for you and says so on Reddit. The discipline is deciding in advance what gets watched on a screen, what is urgent enough to wake someone up at night, and what needs a person to actually fix.

It works in three tiers, from passive to urgent:

A dashboard is a live screen of charts showing the health of the operation in real time, the thing someone keeps half an eye on through the day. What belongs on it: concurrent players (how many people are online right now), login success rate (the share of login attempts that work), time-to-match (how long matchmaking takes to find a game), server fleet utilization (how hard your servers are being worked, so you know when to add or remove capacity), the error rate (how many requests are failing) and latency, which is how long things take to respond. Latency is usually read at two points, the median, meaning the typical player’s experience, and the tail, meaning the unluckiest one or two percent, because an average can look healthy while a slice of players is having an awful time. A dashboard does not tell you to do anything. It is the picture you look at to know whether today is normal.

An alert is an automated message that pages a human when a number crosses a line you set, because nobody can watch a dashboard 24/7. The trick is choosing what to alert on. Alert on the things players actually feel, like the login failure rate climbing past a threshold or matchmaking times doubling, and do not alert on every twitch of an internal metric. A studio that alerts on everything trains its own people to ignore alerts, which is worse than having none, because the alert that actually means something then arrives in a pile of noise and gets dismissed with the rest.

A human on call is the person whose turn it is to answer when an alert fires, the one with the runbooks, the access and the authority to act. Most issues they handle alone. A severe one, the servers are down or the economy is corrupting, escalates into the war room from the readiness checklist, where the incident commander, the communications lead and the operations lead take over. The tiers are a funnel: the dashboard shows you most things, alerts catch the urgent few, and a human owns the rare ones that need judgment.

So how do you set the line an alert fires on? The most useful public model is from Google’s site reliability engineering practice, which publishes an example set of targets for a game service. These targets are called service-level objectives, and they turn “good enough” into an explicit number instead of a feeling. Two from that example. Availability of 97 percent means at least 97 of every 100 requests to the service succeed rather than error out. The latency targets are at the median and the tail: the typical request should finish in a few hundred milliseconds, and even the slow ones should stay under a second. Underneath the targets is another useful idea, which is the error budget. If your availability target is 97 percent, then 3 percent failure is your budget for the period, an allowance you are allowed to spend. A common rule works like this. If a single incident burns a fifth of that budget, the team owes itself a written, blameless postmortem, one that looks into what in the system failed, not who to blame. And if you blow the whole budget in a month, you stop shipping risky new features until reliability recovers. A five-person studio will not run this formally on day one, but the core move scales all the way down: pick one number that means “the game is working,” say 99 percent of logins succeed, measure yourself against it, and let it tell you when to stop shipping and start fixing.

There is one more piece of monitoring: people communication. Games almost never give players a service-level agreement, the kind of contract business software offers where downtime earns the customer a refund. What you offer players instead is communication, and it is the cheapest goodwill you will ever buy. Run a public status page that shows whether the service is up. Bungie’s Destiny help and server-status feed is a solid model to emulate. During a serious incident, post an update on a fixed schedule, every half hour or so, even when the update is “no change, still investigating.” Silence reads as incompetence. A boring, truthful, on-time update reads as a studio in control of its own outage. New World and Helldivers 2 both learned this the hard way, live and in public, in the launch meltdowns described above, and you would much rather learn it from their launches than from your own.

Metrics

Metrics are the numbers you measure about your live game over time: how many people are playing, how many came back, how many left, how the latest patch was received. Once a game is live you can no longer see it by looking, because thousands of people are playing it in ways you never tested, so these numbers become your eyes on it.

A quick note on scope first: the money metrics, lifetime value and ARPDAU and conversion, get a fuller treatment in the financial section further on. The ones below are the other half, the numbers that tell you what to change in the game itself.

A metric is only useful if it is attached to a decision you can actually make. Raph Koster, who designed Ultima Online and Star Wars Galaxies, puts it as “you become what you measure”, and notes that the early social games fixated on daily logins partly because their databases made that number cheap to query, not because it was the most important thing. Focus on the metrics that map to decisions. Ignore the ones that only make you feel busy.

These are the ones that tend to be most useful on a PC or console live game, and the decision each one drives:

Concurrent players, and peak concurrency. This is how many people are online at the same moment, and your peak is the highest that number reaches. It drives server provisioning, which is simply deciding how many servers to keep running so there is room for the crowd without paying for machines that sit idle. It also tells you, bluntly, whether the game is alive, because a multiplayer game with too few players online at once cannot fill its matches or feel populated, however good it is. The challenge is that the peak is the easiest number to wave around and the least informative on its own, since a big launch peak says nothing about whether any of those people came back the week after. Watch the shape of the line over weeks, not the headline number.

Daily and monthly active players, and the ratio between them. The ratio, daily divided by monthly, is your stickiness: how many days in a month an average player shows up. It is the difference between a game people live in and one they visit a couple of times. It’s also easy to fake, so if you just added a daily login reward and the ratio jumps, be suspicious, because you may have bribed people into a habit that disappears the moment the reward does.

Retention measured by cohort. What fraction of the players who started in a given week are still playing one, seven and thirty days later. Day one points at your onboarding, day seven at whether the core loop has legs, day thirty at whether there is any reason to keep coming back. A cohort is just the group that arrived either together or for similar reasons, tracked as a group, and the cohort view is what tells you whether a specific content update actually held the players it was built for or whether they left anyway. (One caveat to hold onto: the retention benchmarks you find online are almost all mobile and do not transfer, so build your own baseline and measure the game against itself.)

Churn. The rate at which active players leave. The thing to do with churn is not to report it but to interrogate it. Josh Bycer, who writes about design at Game-Wisdom, makes the point that studios read the number and skip the root-cause work. Churn is a question, not an answer.

Refund rate. On PC this is the fastest and most brutal truth-teller you have, because Steam’s two-hour, fourteen-day window converts a bad first impression into a refund right quick. The most-wishlisted game on Steam in its year, The Day Before, sold about 201,000 copies and refunded roughly 46 percent of them before the studio closed. Watch this hourly at launch.

Review-score trend. Koster’s observation is that sentiment moves up slowly and falls fast. Your Steam recent-reviews line turning from positive to mixed is an early warning that beats most of your internal dashboards.

Completion and progression. A completion funnel is the count of players still present at each step of a sequence, so you can see exactly where they drop off, in a tutorial, a quest chain, a progression ladder. That shows you which wall to tune instead of guessing at it. Grinding Gear Games runs Path of Exile on this principle, using each league’s data to find which mechanics underdelivered and reworking those for the next league. It is how you set difficulty and pacing from evidence rather than argument.

Balance data, by win rate and pick rate. For anything competitive, this is how you keep the game fair. Riot’s published champion balance framework is the gold standard here: they balance against different skill tiers with different thresholds, flag a champion as overpowered around a 53.5 percent win rate, and follow a simple rule, overperforming in any tier makes it a nerf candidate and underperforming in every tier makes it a buff candidate. The subtle part is the data they deliberately leave out, the early learning period, so they do not punish a character for the crime of being hard to learn.

Now here’s an important warning about all this: data can be correct and still destroy the game. Arrowhead’s first big Helldivers 2 balance patch nerfed a beloved weapon toward the role the designers intended for it. The data said it was too strong. The design intent was defensible. And it set off a revolt, because players were having fun with it. Pilestedt’s own words afterward were that it felt like every time someone found something fun, the fun got removed, and that tweaking damage numbers had been a blunt instrument. The lesson is to treat your own balance intent as a hypothesis that player fun is allowed to overrule. The dashboard serves the game and the people playing it, and it should not get to be the customer.

Finally, there is one line I will not cross here, on brand and on principle, and I can only hope you feel similarly. It’s that the metrics above are for understanding and improving the game. The moment you start using them to engineer how to extract more and more money from existing players, conversion funnels, manufactured scarcity, compulsion, the psychology of the purchase, you have crossed into the part of this business that PC and console players will smell and will not forgive. Chris Wilson of Grinding Gear Games, who runs Path of Exile, draws the line at transparency, fairness and respect, and tells other developers to think hard before reaching for retention tricks, to make sure a change is adding fun rather than manufacturing engagement. That is 100% the right instinct, and it’s also just good business on these platforms.

Setting a release cadence

The cadence is the heartbeat of the operation, and a mistake first-time studios make is setting it by ambition or by the marketing calendar instead of by what the team can credibly and sustainably produce. If you get this wrong in the fast direction, you’re going to burn out the team. If you get it wrong in the slow direction, players leave. So the cadence is a very important decision.

The rhythms that successful PC and console live games actually run, from fastest to slowest, form the following stack:

Hotfixes and balance, every few days to two weeks. League of Legends ships a balance patch on a roughly two-week schedule, constant small tuning that is cheap to make. Running alongside it is a near-relentless stream of cosmetics and events, between weekly and every fortnight. What is rare is a brand-new champion: Riot has slowed from one every two weeks to roughly three or four a year. The point is that a live game runs several cadences at once, not one. The cheap, frequent work is tuning and cosmetics. The expensive, infrequent work is new systems and characters. Promising the second on the schedule of the first is how studios commit to a pace they just cannot hold.

Seasonal content, roughly two to four months. This is the dominant beat. Path of Exile runs a roughly thirteen-week league cycle, and the co-founder Chris Wilson explained at GDC that the cadence exists to keep the team from spending years on something players turn out not to want: the schedule is a feedback mechanism, not just a marketing drumbeat. Deep Rock Galactic runs seasons every six months or so and gives all the gameplay content away free, and it keeps every past season permanently playable rather than letting it expire, which is fantastic.

Major expansions, around a year. An expansion is the big paid release that resets the top of the game: a new region, a higher level cap, fresh high-end content, the thing that pulls lapsed players back and anchors the year’s marketing and revenue. World of Warcraft and Final Fantasy XIV ship one roughly every two years (The War Within, Dawntrail), and Destiny built its whole calendar around an annual paid expansion. For a small studio this is the single heaviest thing you will build in a year, and it usually has to be built by a team that is also keeping the current game running, which is the squeeze the entire cadence question is really about.

How you set yours comes down to four inputs that are likely to pull against each other:

How long your content takes to build. A season, an event, a new mode, whatever your repeatable unit of release is, takes your team some number of weeks to produce at the quality you are willing to ship. Path of Exile’s thirteen-week league cadence is exactly its development cycle: the schedule and the build time are the same number on purpose. Your cadence cannot run faster than your team can actually finish things, and promising a pace your output cannot sustain is how a studio ends up either crunching or shipping thin, half-finished updates.

How fast players consume it. Dedicated players burn through content far faster than you make it, which determines how long each drop holds them before they go quiet. This is the content treadmill, and it has its own section below.

Marketing beats. Seasons and their battle passes create scheduled moments to win lapsed players back and to put the game in front of new ones, so the cadence is partly a marketing rhythm, not only a production one. The danger is letting the marketing calendar dictate a pace the team cannot meet.

Your team’s health. Increasingly the input that actually informs the answer, because a cadence that looks great on a roadmap and burns the team out by month eight was never truly sustainable, and burnout shows up as people quitting and quality slipping well before it shows up as a missed date.

That last input can determine more than studios expect. Some studios have deliberately slowed down to protect their people. Final Fantasy XIV’s director stretched the patch interval after years of crunch. Respawn said publicly of Apex Legends that it would not crunch the team to ship content faster, and chose a slower seasonal pace instead. These are deliberate exceptions in an industry that, bluntly, still crunches people into the ground. A sustainable pace is a choice, not the default, and a five-person studio has far less room to absorb the cost of choosing wrong than Respawn does.

When you hit the slow problem instead, a content drought between drops, there is a move smaller studios can borrow from the giants: tell players, out loud, that it is fine to leave and come back. Scary, I know. Final Fantasy XIV’s director openly encourages players to take a break and go play other games between major patches, which turns a drought into intended downtime rather than a fight you have to win every single week to keep people from leaving.

Testing a release before players see it

Once you are live, every patch goes out to an audience that already paid you, on a cadence, indefinitely. So you want ways to test a release on a small group before it reaches everyone.

The full toolkit, mostly borrowed from web engineering, is roughly the following:

A public test realm (PTR). A separate, parallel copy of the game running the next patch that players can opt into to try early. In an MMO, players can play a copy of their character on the test server, which lets them test high-end content right away instead of leveling a new character from scratch, and World of Warcraft’s PTR is the model. The studio asks for specific feedback, watches how the changes behave with thousands of real players, and gets both a balance check and a load test before the patch ships to the live game. The catch is that it needs a big enough player base to populate the test server, which is why it is mostly a big-game kind of tool.

Beta branches. Steam lets any developer put a separate build on an opt-in beta branch, public or locked behind a password, at no cost. Players who opt in run that build instead of the live one, so you can hand the next patch to a few hundred volunteers or a private testing group and watch what happens before promoting it to everyone. This is the small-studio answer to a PTR: you do not need a populated test server, just a branch your most engaged players or your closed testers switch onto.

Staged rollouts with feature flags. This uses the feature flags from the technology section to ship safely. You wrap the change in a flag and turn it on for one percent of players, watch the error rates and crash reports, then ten percent, then half, then everyone. That gradual widening is called a canary rollout, after the canary in the coal mine: a small exposure that warns you before the whole mine does. If something goes wrong, you hit the kill switch, which is simply the flag flipped back off, instantly disabling the change for everyone without shipping a patch or recalling anything. The reason this helps a small studio is that it works at any size, because you are testing on a slice of your own live players and reading real dashboards, so you get a meaningful read without a big test population. It needs backend plumbing, not a second game.

For a studio that cannot reproduce a big game’s test scale, the realistic combination is Steam beta branches plus feature-flagged percentage rollouts plus a closed Discord cohort for the qualitative read. You will still do some tuning live, through fast hotfixes, because you cannot fully de-risk balance without a large population hitting it. That is exactly why the feature flags and the kill switch should be built before you launch, not after.

A note of caution on one tool. A/B testing means showing one group of players one design and another group a different design, then measuring which does better, and the mobile world uses it aggressively, including on pricing and on how fast you are allowed to progress. On PC and console, players understandably resent being treated as lab subjects, especially when the thing being tested is what they pay or how long their grind takes. Test for quality and stability as much as you like. Think twice about secretly split-testing money or progression on this audience, because when they find out, and they will, it reads as exactly the manipulation they came to these platforms to avoid.

The financial case

The financial question behind a live game is simple but hard to answer: will the money coming in cover the cost of running this thing for years, with enough left over to make it worth doing? A premium game answers that once, at launch, to a large degree in the first week to a month, against a fixed development cost. A live game has to answer it continuously, against non-stop operational expenses. So you need a way to estimate that before you commit, and a way to keep an eye on it afterward. Both come down to two numbers: what a player is worth to you, and what a player costs you.

Start with what a player is worth, which is their lifetime value, or LTV. LTV is the total revenue you can expect from one player across their whole time with the game, and you build it from two ingredients. The first is a retention curve: of the players who start this week, what share are still playing on day one, day seven, day thirty, day ninety and so on. That curve starts high and decays, and the area under it tells you, roughly, how many days the average player sticks around. The second ingredient is how much an average active player spends per day, where “active” just means they logged in and played that day. Multiply the average lifespan by the average daily spend and you have a rough LTV. This isn’t a very nuanced approach to LTV modeling, but that’s the gist.

Let me give you an example. Say a hundred players start today. Thirty are still around after a week, twelve after a month, and a thin tail keeps a few playing for a year, which averages out to roughly forty active days per player. Say your monetization, a battle pass and some cosmetics, earns about fifteen cents per active player per day once you blend the few who spend with the many who never do. Forty days at fifteen cents is six dollars of lifetime value per player. That six dollars is the heart of the whole financial case, because every cost in the operation gets measured against it.

A few important terms:

• DAU and MAU are daily and monthly active users, the count of distinct people who played in a given day or month. Divide one by the other and you get stickiness: a DAU/MAU of 0.1 means your average player shows up about three days a month, while 0.5 means they play every other day. Higher is stickier, and stickiness feeds retention, which feeds LTV.

• ARPDAU is average revenue per daily active user, what the whole population earns you per day with payers and non-payers averaged together. It’s the fifteen cents in the example from a moment earlier.

• Conversion is the share of players who ever spend a single cent, and ARPPU is average revenue per paying user. The same ARPDAU can come from many people each paying a little or a few people paying a lot. The second is fragile, and on PC and console it is also the kind of monetization players notice and resent.

Almost no premium PC or console studio publishes its real retention or spending numbers. The day-one and day-thirty benchmarks you find online are almost all from mobile free-to-play, where the curves and the wallets behave nothing like a premium game’s. Treat any outside number as mobile until proven otherwise, and build your own model from your beta and your launch, not from someone else’s genre.

Now the other half, what a player costs. This entails four things:

• The platform’s cut. Steam, PlayStation and Xbox take roughly thirty percent of gross before you see anything. Steam steps down to 25 and then 20 percent at high revenue tiers, but plan around thirty. Every dollar of LTV is really about seventy cents in your pocket.

• Infrastructure. Servers, bandwidth and backend services, which scale with how many people are online at once. For a dedicated-server competitive game this is a meaningful monthly bill that grows with success. For a peer-to-peer co-op game it’s unsurprisingly much smaller. Don’t guess: your backend provider publishes a pricing calculator, and you model it per concurrent player against your expected peak.

• The team. Usually the largest cost, and the one studios regularly underbudget, because a live team is bigger after launch than before. You are paying producers, engineers, designers, community and support people to keep the thing running every month, indefinitely.

• Content. The cost of building each season or update, on a cadence, forever. This is the content treadmill (more on this below).

The go-or-no-go decision is whether your LTV, multiplied by the number of players you can realistically reach, clears all four of those costs with margin left over. On PC and console the difficulty is that second factor, the audience. You cannot buy your way to millions of installs the way a mobile game can, so if your model only works at a player count you have no credible path to reaching, the model does not work. Be merciless about that number, because optimism about audience size is a natural and understandable emotional response when you spend years working passionately on something. And live games get greenlit and then run out of money all the time.

There are two roads to actually earning the revenue, and only one of them suits this audience.

The first road is premium and demonstrates respect for the player. It’s the one I would point a small studio toward. Helldivers 2 sells for around forty dollars and treats the box as the main revenue, with cosmetics that cost a couple of dollars and a battle pass that never expires and can be bought with currency you earn in the game. I mentioned this before, but it bears repeating: Deep Rock Galactic is premium-priced, gives every gameplay update away free, sells only cosmetics and is explicit that its seasons exist to keep the game popular and bring in new buyers rather than to extract from existing players. Both built large, durable businesses on respect rather than pressure.

The second road is the escalating-monetization one, and it is a cautionary tale. Destiny 2 is the case study I saw most cited when researching this topic: a steady accretion of new things to buy, prices on cosmetics climbing over years, until critics described it as among the most monetized mainstream games around, and the goodwill of the core community wore through. Naavik’s breakdown of how Bungie’s live model slid toward extraction over experience lays out exactly what to avoid.

Estimating the case is the easy part. The discipline that actually protects the studio is watching it hold over the years, against the model you built. Watch the leading indicators, not the launch peak, which tells you almost nothing on its own:

• The concurrency floor, not the peak. After each content drop, does the active-player count settle to a higher baseline than before, or a lower one. A floor that rises drop over drop is a healthy game. A floor that sinks every cycle is a game bleeding out.

• The breadth of who pays. If revenue holds while the number of paying players shrinks, you are not growing, you are leaning harder on a smaller group of big spenders. That is a reliable early warning of decline, and it is the road Destiny went down.

• Cost per content drop against what it brings back. If each update costs more to make and returns fewer players and fewer dollars than the last, the unit economics have inverted, and no amount of effort fixes an inverted model.

A healthy live-service profit-and-loss statement (P&L), and a dying one look quite different, as you’d imagine. The healthy one grows its floor, keeps its paying base broad and covers content costs with room to spare. The dying one does the opposite. At the end it falls into a spiral: a thinning population makes matchmaking slower and the game feel emptier, which pushes more players out, which thins it further. That cascade is how a live game goes from struggling to dead in a couple of quarters (Naavik has a walkthrough of stalled titles).

This is also the reason a healthy operation designs for the players who never pay. While this information is probably a little outdated by now, Scott Hartsman’s number from running RIFT was that only about 7 to 20 percent of players ever spend a cent. That sounds like a problem until you ask what the other 80 to 90 percent are doing. They are filling your servers, populating your matches and making the world feel alive, which is exactly what the paying players are paying for, because almost nobody buys a cosmetic to show it off in an empty game. In a live game the free players are not freeloaders, they are the product that the paying players are buying into. If you squeeze them to juice this quarter’s revenue targets, you will starve the thing the revenue actually depends on.

The content treadmill

The content treadmill can be a structural trap. I wager it kills more live games, and studios, than any server outage ever could. In a content-driven game, the play is hand-authored, so the only way to “add more game” is to build more of it: a new level, a new enemy, a new mission. Players consume that authored content far faster than any team can make it. A mission that takes your team a month can be finished by a committed player in an evening, and you just can’t build fast enough to stay ahead of them. Success makes it worse rather than better, because the more players you have, the more of them are sitting at the front of the line, done with everything you shipped, asking what’s next.

There is a second reason the treadmill gets more challenging over time, and it’s that player expectations ratchet upward. Once you’ve shipped a big season, that becomes the new baseline expectation, and the next one has to meet or beat it, every cycle, with no ceiling. The work also pulls in the wrong direction, because content is easy to imagine and systems are not. A producer can put “three new maps” on a project plan and everyone immediately understands that. “A system that generates its own variety” is much harder to wrap your head around, harder to scope, harder to sell to the people in charge of the budget and easier to cut when the schedule slips. So instinctively, teams do what? They choose the maps, which then keeps them on the treadmill.

Before the options, one caveat, because this gets preached as gospel, especially by VCs, for reasons that elude me, and I don’t think it should be: you do not always want off the treadmill. Some games are great precisely because a caring, talented and hardworking team handcrafts every hour of them, and forcing in procedural systems or mandatory replay or any other engagement shenanigan that doesn’t necessarily make the game better, just to cut costs, would gut the thing players love. You’d basically shoot yourself in the foot. The real question is more in the lines of: for the game you are actually making, how do you carry the lightest content load that still delivers your creative promise to players. Sometimes that means designing replay value into the systems. Sometimes it means accepting a heavy authoring bill and budgeting for it on purpose. Just don’t wreck your perfectly good game to save money on the thing that actually makes it perfectly good.

These are some of the levers that you can pull, from strongest to weakest, and which ones apply depends entirely on your game:

Systemic and emergent design instead of authored content. A game whose fun comes from systems interacting generates situations nobody had to build. For instance, Hunt Showdown’s sandbox produces stories the studio never wrote. This is by far the highest-leverage choice and it has to be made before launch, because you cannot bolt emergence onto an authored game later. It’s just not what the game is.

Procedural and roguelike content. Procedural generation multiplies how far hand-made pieces go: a handful of authored enemies, weapons and rooms recombine into thousands of distinct runs. Vampire Survivors sustained tens of millions of players from a tiny team this way. The catch is that plenty of audiences specifically want crafted, bespoke content and can feel the difference instantly, and handing them procedural filler instead is how you lose them. This works when randomness is part of the creative promise, not when it’s a substitute for authorship you could not afford.

A deep competitive meta. If your content is other players, you barely have to author content at all. In a MOBA the matches are generated by humans competing, and the studio’s job is mostly to keep that contest fresh and fair: a balance patch every couple of weeks reshuffles which strategies win, and the players re-explore the game for free. Compare that to an MMO, where the studio hand-builds every raid that players then consume. Both can run for decades, but the MOBA authors an infinitesimal fraction of the content per hour played, because the players generate the rest by competing against each other. The catch is that it only works if the core game is competitive and deep enough to hold people for thousands of hours, which is a design decision you make at the very start, not a content tactic you add later.

Player-driven resets. A survival game that wipes its servers monthly, or an extraction game that resets its economy each season, refreshes the whole experience without building new assets. The reset is the event. The tradeoff is not small though. A wipe asks players to throw away their progress, which a large part of any audience hates, so it fits games where the fun is in the climb and the restart, and it actively repels the players who came to keep and build on what they earned.

An evergreen core plus seasonal content. Hold a permanent base of activities that keeps players busy between drops, so each new season adds to the game instead of having to carry it alone. Warframe pairs a deep, always-available grind with lighter seasonal challenges. Deep Rock Galactic folds every past season back into permanent rotation rather than letting it expire. The seasonal drop becomes the spike of fresh interest, and the evergreen core is what holds players when the spike fades.

Player-created content. At scale this is perhaps the strongest answer of all, because your players become your content team. Fortnite Creative and the whole Roblox economy run on it. The cost is heavy and front-loaded, since you are building and then supporting a creation toolset and a moderation operation, which is usually far beyond a first-time indie. But it’s the one lever that turns a finite team into an effectively infinite content pipeline, if you can afford to build the tools.

At the heart of all of these is timing. You have to choose the model before launch, not after. You cannot retrofit emergence, a competitive core or a procedural engine onto a game that was built to be hand-authored. This is Hartsman’s opening question seen from the production side: the self-refreshing parts of a live game only work when they are foundational to it.

Turning it off

Every live game ends. Planning the ending is part of running the operation, and studios systematically skip it, which is why so many endings go badly in both directions.

Most studios hold on far too long. Anthem limped for two years behind a promised overhaul that never shipped, with the servers up well past the point of usefulness. Marvel’s Avengers kept shipping content while its own publisher was calling the game disappointing on earnings calls. Part of that is sunk cost and the dread of the headlines that come with admitting it did not work. Part of it is simpler and uglier: a dying game still makes a little money, and a little money plus the appearance of not quitting feels better to a publisher than a refund and an admission. But it rarely is. The slow bleed usually does more damage to the studio’s name than a clean shutdown would, because players remember being strung along, and that memory is expensive on the next game.

The more natural instinct goes the exact other way. When Concord launched to almost nobody, Sony pulled it within two weeks and refunded every purchase. The refund was the right call. The mistake was to actually launch it at all, and no amount of live-service patience would have rescued a deeply mediocre forty-dollar hero shooter in a market full of really good free ones. That is the tougher lesson underneath: the place to stop a doomed live game is before launch, not fourteen days after.

The best model for ending well comes from Velan Studios and Knockout City. When they shut the servers, they shipped a free private, self-hosted build of the game so communities could keep playing on their own. Their marketing director called it the single biggest thing they did for the positive reception of the shutdown, and, importantly, a relatively light effort, because their internal dev builds already worked like private-server builds. Players ran their own tournaments for months afterward, and the press coverage of the closure was reasonably warm, which almost never happens.

There is also a reason this is becoming less optional. After Ubisoft shut down The Crew in 2024 and the game became unplayable even for solo owners because it had always been online-only, the Stop Killing Games movement gathered over a million signatures in the EU, and lawmakers started acting. California passed a bill through its assembly that would require publishers shutting down an online-dependent paid game to give sixty days notice and provide an offline build, a private-server option or a refund. As of 2026, none of this is settled law yet, so treat it as direction rather than fact. But the direction is clear, and the lesson lines up with the Knockout City one: build the offline or self-host fallback early, when it’s still cheap, rather than at the funeral when it’s not. You cannot always choose when the end comes, but how you end is a decision you make, admittedly counterintuitively, near the beginning.

What you’re signing up for

The day you ship is the day the actual job starts. That is the sentence I wish someone had told me early on, because everything in this primer stems from that: the bigger team, the permanent operation, the cadence you set by what your people can sustain, the treadmill you either design around before launch or run on forever, the ending you plan at the beginning, all of it.

Raph Koster describes the whole shift as the moment you stop making cool stuff and start gardening a user base, and he reckons it takes a studio three to five years just to learn how. So the most useful thing I can tell game studios considering this is not a tactic. It is to decide, deliberately and with the costs right in front of you, if that gardening is the job you want, before you find yourself holding the hose.

What does live ops look like at your studio? Reply or comment and tell me about it.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

Getting a publisher to fund your game is one of the murkiest things an indie, and especially a first-time studio has to do. The bar is unclear, the advice contradicts itself, and the words everyone throws around, demo, prototype, vertical slice, mean different things to different people. So teams are left with confusion and forced to guess. They build the wrong thing, send it to the wrong publisher at the wrong moment, and then burn months of effort and runway finding out.

It also doesn’t help that publishers ask for different things and describe them differently. One claims to want a video, the next wants a playable build, a third wants a deck and a call. It’s messy. But underneath the inconsistency, they tend to weigh mostly the same things and in mostly the same order. This article is about what those things are in 2026, and what actually moves you toward a term sheet.

Publishers weigh three things, in order: your demo, the team behind it and how well the game fits their business. The demo is most of the decision. The other two can sink you, but they rarely win it for you on their own.

Before any of that, though, the words.

Getting the terminology right

The terminology used in the process of pitching games is staggeringly inconsistent, and that inconsistency can sometimes confuse teams into building and presenting the wrong things.

Five terms get used as if they meant the same thing, and even publishers blur them. tinyBuild’s pitch page asks for a build with a vertical slice of gameplay, then describes something closer to a convention demo than to a vertical slice in the strict sense. Raw Fury, roughly after the same thing, simply asks for a playable build. Same target, different words, this repeats across publishers. So get precise about each one, because the term you aim at decides how much time and effort you spend.

A prototype is an internal tool. It exists to prove one idea, does the core loop work, does the hook feel like anything at all. The code is throwaway and the art is boxes, and that’s absolutely fine. A prototype might have been enough to interest a publisher 20+ years ago. That’s not the case anymore. Don’t waste your time, or theirs, pitching with a prototype.

A proof of concept is almost the same as a prototype. I’d say it’s a prototype with a coat of paint. Some representative content, a sense of how the game might look and feel, a little more scope and scale than a prototype, while everything under the hood stays disposable. Somewhat useful in development, not at all what you show a publisher.

A first playable is the next step up, and it’s based on non-throwaway work. The game runs on code you intend to keep, with bespoke art that is reasonably representative even if it isn’t final. Publishers do see these, and if a team has shipped together before and the first playable is genuinely compelling, it can sometimes be enough to start a conversation. It’s highly contextual.

A vertical slice is a term that almost everyone outside development uses incorrectly. Strictly, a vertical slice is a narrow, final-quality cross-section of the game whose only job is to set the bar, to say “this fidelity, this look, this feel.” That’s all it is. It was never meant to be every system and every feature stitched into a playable quarter of the game. That’s absurd. If you already have every system and feature at near-final quality, why in the world would you go looking for a publisher’s money? To author the last five missions? To build two more biomes? You might as well push through, finish the thing and keep the revenue a publisher would have taken.

A demo is what you actually pitch with. It’s well above a first playable and well below the whole game in miniature, that mythical “vertical slice with everything in it.” A deliberately chosen portion of the game, built with enough breadth and quality to convince a publisher that the finished product is going to be great. For an action-adventure game that might mean combat, a bit of exciting traversal, a taste of progression, some dialogue and the tone coming through in the art and audio. Enough to communicate and demonstrate the game and why it’s great. That’s it.

The practical upshot is that a demo does not need every system. It needs the systems that prove your game’s value, and it can skip the expensive plumbing that finished games require and pitches don’t, like the co-op netcode, the full cutscene pipeline, the final physics, etc. If your demo already has all of that, then you’re not pitching a demo, you are showing a nearly finished game and you should ask yourself why you’re asking a publisher to fund the home stretch.

Build what makes the case and defer what’s necessary to ship.

Two things keep all of this messy. First, publishers and developers use these words almost interchangeably, so a given submission page can mean something different by “demo” than the studio reading it does. Stick to the definitions above and read each publisher’s page through them. Second, publishers don’t want to lose a promising game to a competitor, so they will happily talk to you early, look at less than a finished demo, hand you a little feedback, keep the door open. That openness is legit, and it fools people. You can have the conversations and the handshake long before you have any money. What you almost never get is a term sheet without a compelling demo. Know that.

The demo: the primary evaluation

Nothing is more important than the demo. Not by a country mile. A genuinely exciting game that could sell well is roughly 80-90% of a publisher’s decision, so it deserves the bulk of your time and most of this article.

To put money on the table, a publisher needs the demo to show four things.

1. A genuinely good game. Obvious, and still where so many pitches somehow lose. “Good” means the game’s core proposition is visibly there: a core loop that feels great, a meta progression that pulls you forward, narrative that grips, visuals that move, whatever makes this particular game worth playing. Which one is the real engine of your game is contextual and varies dramatically from game to game. You should be very, very clear on what this is for your game.

2. Differentiation. With something like twenty thousand new games on Steam every year, yours has to stand apart somehow. A highly competent Factorio clone is neat, but Factorio already exists, and so do a hundred imitators. Your game needs the thing that makes it unmistakably yours, and it’s seldom the art alone, or the theme, or the setting. Whatever that thing is though, it’s the demo that has to show it, not the deck.

3. A hook and marketability. Steam is full of good games no one has heard of. Good is not the same as marketable. Games that are easy to grasp at a glance, that are social, that throw off their own clips and stories, that simply look arresting tend to be far more marketable than games that need a paragraph to explain. You don’t remotely have to rebuild your game around this, but you should know where you stand and shift what you reasonably can. Wishlists and an early audience come from the same place, which is something to start long before launch.

4. Craft and execution. Ideas are a dime a dozen. Executing them well is brutally hard, and publishers know it, so the demo doubles as proof that your team can pull off the full game. A build that is stable, performant and finished-feeling says you can run a production, that you can get there. A brilliant, ambitious build that crashes every two minutes telegraphs that you can imagine a great game but can’t yet ship one. This is also the bridge to the second thing publishers evaluate, the team, because the demo is the loudest evidence you can give about them.

There’s one more thing about the demo, which should change how you build it, and it’s that it will not be played the way you play it. A publisher plays it once, briefly, often distracted, and frequently looking for a reason to stop, because they have hundreds in the queue. Raw Fury are honest about this in their own pitch guidance: send the build you are proudest of, and if it runs long, add skippable intros and checkpoints, because they can’t promise to play it twice. So put the strongest reason to fund your game in the first couple of minutes, give them a level select to jump to what they need to see, and assume the person on the other end quits early.

Build for them, because this is how they play, this is their reality.

Where your game’s value lives

I touched earlier on why it’s important that you’re very clear on what makes your game good. This may seem painfully obvious but you’d be shocked how many teams struggle with this notion. It’s probably a factor of being in the trenches for too long and losing a bit of perspective, which is understandable. So before you build your demo, it’s imperative that you’re both honest and intellectually critical about where your game’s value proposition actually is, because that decides what the demo has to nail and what it can skip.

Most games fit mainly in one of a few buckets.

• Core-loop games (shooters, platformers, brawlers). The value proposition is the second-to-second feel. The publisher has to feel it, controller in hand, in the first couple of minutes, so responsiveness and feedback on your core actions need to be the most finished thing in the build. A common mistake here is burying the loop behind story or setup.

• Meta-loop games (builders, strategy, sims). The value is what grows across runs and hours: progression, systems feeding each other, one more turn. This is hard to demo, because the payoff lives well past the few minutes you’ll get, and a short slice can make the deepest game on earth look thin. Telegraph the depth: show the breadth of systems, get a late-game state into view, give them enough to extrapolate the curve.

• Novelty games. The whole pitch rests on one unfamiliar or novel idea. It can be a unique mechanic, a surprising loop, a wild genre matchup. Double down and put that innovation front and center immediately. Showcase that it can carry a full game.

• Multiplayer games. The value comes from other people, the hardest thing to show in a build sent to one person over Dropbox. You can compensate with bots, a curated session, footage of real games, anything that proves the social hook works with an actual group.

• Content-heavy games (open-world exploration, narrative, adventure). Not the most common bucket, but in this case the value is heavily-reliant on authored content. The demo has to prove the quality of the writing, the tone, the audiovisuals, and prove the thing teams forget, which is that you can produce that quality at volume. Craft your demo around the notion that you need to show as much authored content as possible, as rapidly as possible.

Most games are a blend, but one bucket tends to dominate, and teams flatter themselves about which one. The team with a thin loop tells itself it’s a novelty game. The team with a gimmick tells itself it’s a content game. The demo is where that gets discovered, usually in front of the one person you needed to convince. A Satisfactory-like demo pitched on “open strong, end on a big explosion” would read completely wrong, because a single explosive moment is the opposite of where its value proposition lives. Be very clear on which game you are actually making before you decide what the demo has to say.

The team: the secondary publisher evaluation

After the game itself, the biggest question is simple: can this specific team actually deliver on it? A publisher is handing one or two million dollars to people they barely know and trusting them to come back in two years with a finished, sellable game. Most funded games that fall do so not because the idea was bad but because the team couldn’t successfully execute that idea and make the most out of the funds.

So publishers understandably scrutinize the team. They want the critical competencies already in place. If you’re making a combat game and you don’t have a combat designer, or if you’re making a MOBA and you don’t have a network engineer, then that’s pretty much a deal breaker. A promise to find those key people is nowhere near enough. Publishers want collective experience and some genre expertise. Above all, they want a team that has shipped something together before, even something small, because a team that has crossed the finish line once has already answered the exact question the publisher is asking. A first-time team can absolutely get funded, but it has more to prove, and the demo has to do more of the convincing.

Strategic match, portfolio fit and profitability

Even a great demo from a capable team gets passed on if the fit is wrong, and fit comes down to three things.

Strategic match. You don’t pitch a racing game to Paradox, a match-3 to Microsoft, or a 200-million-dollar live-service hero shooter to 505 Games. Publishers have areas they know and areas they care about, and they open their wallets for games that fit their business strategy.

Portfolio fit. A publisher with two or three soulslikes already shipping in the next twelve to eighteen months will not want a third, because your sales and theirs would eat into each other. Sometimes the rejection is purely timing in their catalog, nothing to do with your game.

Profitability potential. You can check every box above, demo and team included, and it still won’t move the needle if the audience is too small, the genre is saturated or players are sick of the business model. We make games because we love them, but they are also products that have to sell. Publishers feel that second fact in their bones, sometimes to a fault.

What you actually send

The demo is the pitch. Everything else in the package supports it and, on its own, sells nothing. You’ll want a tight deck that frames the game and the hook, a believable budget, a project and milestone plan, and maybe a short video for the cold approach. None of these open a checkbook by themselves. They exist to facilitate the process, nothing more. If you find yourself pouring weeks into the deck while the demo sits unfinished, you have your priorities backwards.

It also helps to see how inconsistent the ask really is. Here is what a handful of publishers request on their own submission pages.

• Devolver wants a gameplay video and a deck, no build up front.

• Kepler asks for something playable, and says it is “generally unable to assess a project without a build.”

• Raw Fury lays out its full ask and process.

• tinyBuild walks you through how to pitch them.

• Team17 takes submissions through a form.

• 11 bit studios runs a structured submission page.

• Thunderful, Coffee Stain, Twin Sails and Fellow Traveller each run their own intake with their own requirements: Thunderful, Coffee Stain, Twin Sails, Fellow Traveller.

Read each one through the definitions earlier, and don’t take any single publisher’s wording as the universal standard. There isn’t one.

Becoming the 1%

Even a genuinely good demo gets a no most of the time. Raw Fury have said they receive over 1,500 pitches a year and sign fewer than one percent. That is not 1,485 bad games. Most are perfectly fundable games that didn’t get funded, and the reasons usually have little to do with the game itself. The math didn’t work, or there were no open slots this year, or the portfolio was full, or the timing was off, or the publisher was running low on funds, or something you will never be told.

So don’t read a rejection as a verdict on your game. Founders who take it that way start tearing out and rebuilding the wrong things to please a publisher who passed over slots and timing they will never see.

What you can control is what you put in front of them. And the discipline that separates the 1% from the rest is really about how you spend your effort demonstrating the things publishers actually evaluate, the demo, the team and the fit, and not the things that feel good to build. Many studios over-invest in what excites it and under-invest in what closes the deal. The polish you are proudest of is not always the proof a publisher needs.

Point the demo, and the months it costs, at the evaluation you are actually being put through. That is most of what you can do to move a 1-in-100 number in your direction.

What’s your experience navigating publisher pitches? Let me know your thoughts!

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

I’ve been in game development for a couple of decades, and in my humble opinion, almost none of the issues afflicting our industry have gotten better. Which is positively befuddling. Some of the worst behaviors have perhaps tapered off a bit. Some got dramatically worse. Some that were trending the right way pulled a clean 180 and reversed themselves. And some things that weren’t even on the radar twenty years ago are now full-blown industry-wide problems. But the bulk of what is documented below was happening 20 to 25 years ago and is still happening today.

I’m writing this article because some of you reading this will succeed, you will build solid game studios, maybe even run a large game company one day, which is why it’s imperative that you understand what bad looks like today, not after you’ve found success. The catalog of malpractices below doesn’t happen all at once. No one wakes up one day and says to themselves: “I’m going to be a greedy corporate hack, I’m going to treat people like trash and I’m going to do everything in my power to obliterate creativity.” No. It’s a surreptitious drip that grows steadily over time.

Understanding this reality, exercising self-awareness, humility and growing yourself as an effective leader of our industry is your responsibility today. Not tomorrow. Today.

Labor abuse and worker exploitation

• Dressing up mandatory crunch as a “labor of love.” Sixty- to one-hundred-hour weeks for months on either side of launch, justified by the idea that workers love the games they make. The IGDA’s 2019 Developer Satisfaction Survey found that 41% of developers reported their job involves crunch, and 42% said crunch was expected at their workplace. Long-form reporting on the consequences documents weeks and months of developers not seeing their families, deep depression and burnout normalized as part of the job, and at BioWare stress leave that turned into one-to-three-month mental health absences.

• Promising never to enforce crunch, only to pull a 180. Marcin Iwiński of CD Projekt Red publicly pledged in 2019 that the company wanted to treat people humanely (dixit) and avoid mandatory overtime on Cyberpunk 2077. In September 2020 the studio reversed that policy and ordered mandatory six-day weeks through launch. Rockstar followed a similar but inverted pattern: Dan Houser was quoted bragging about “100-hour weeks” on Red Dead Redemption 2, then walked the claim back and said it only applied to four writers for three weeks, while Kotaku’s parallel investigation found mandatory overtime running for over a year at Rockstar Lincoln, 55-to-60-hour weeks as the norm across studios, and current QA staff saying they had been told to expect 80-hour weeks.

  

• Treating unpaid overtime as a tacit agreement. A union investigation found that 85% of game workers do unpaid overtime, and only 15% are paid for it. QA, administration and localization workers earn below-average pay across the entire industry.

• Misclassifying salaried staff to dodge overtime law. Electronic Arts paid a $15.6 million settlement to graphic artists in 2005 over unpaid overtime, then a separate $14.9 million settlement to software engineers in 2006 for the same misclassification pattern. The engineer settlement is the one tied to the EA_Spouse story, broken by a LiveJournal post from the fiancée of one of the plaintiffs. (Cardozo AELJ)

• Treating QA testers as an underclass. Most QA roles, especially at large studios, are contract positions paid at or near minimum wage, with six-day weeks as the norm and turnover sky-high. QA staff in Canada report nearly 50% of paychecks going to rent. The Kotaku investigation of QA working conditions confirms that contractor testers were typically barred from speaking directly to developers, with communication routed through QA leads or bug-tracking systems. (Prism)

• Weaponizing the “dream job”. Academic research on the games industry has formally named this dynamic “passion exploitation,” the legitimization of exploiting people’s love of their work to extract overwork and accept lower pay, and has documented how it creates an oversupply of willing workers that pressures developers into silence and acceptance of conditions they would otherwise reject.

• Hiring recklessly, firing people en masse and blaming the economy. Pandemic-era engagement was assumed to be the new baseline. Venture capital invested $4.7 billion into gaming startups in 2020, a 193% jump over the year before, on the bizarre assumption that lockdown-era engagement would hold in perpetuity. Studios hired hyper-aggressively, then ended up dumping the same people as the post-pandemic correction returned the market to its pre-COVID trend, with an estimated 45,000 jobs lost from 2022 through July 2025, (Wikipedia).

• Treating burnout as a rite of passage. BioWare’s Edmonton office logged so many doctor-mandated leave cases during Mass Effect: Andromeda and Anthem that depression and anxiety became epidemic across the studio. Former staff described finding empty rooms to cry in. The phrase the studio actually used internally was “stress casualties,” like the people were a battlefield statistic rather than the team that made the game. (FandomWire, Tweaktown)

Bad leadership

• Building an auteur culture. When an entire studio exists solely to execute the vision of one person, the other 200 people on the team are reduced to limbs of that vision. The result is a Ford assembly line making a mockery of creative work. Industry writing on auteur theory in games has been raising the structural disempowerment problem for years: the auteur model presumes a large, efficient team that may not share the artist’s vision, and assumes their job is to execute, not to author. (Game Developer, Unwinnable)

• Enabling and accepting sexual harassment. This is a staple of the industry, not an outlier. Activision Blizzard’s documented “frat boy” culture included serial predatory behavior by managers, dismissal of HR complaints, and male leadership effectively running cover for misconduct over a period of years. Three former Ubisoft executives were convicted in July 2025 on workplace harassment charges in France, receiving suspended prison sentences and fines totaling tens of thousands of euros. Tommy François was additionally convicted of attempted sexual assault, with documented behaviors that included tying a staff member to a chair and forcing another to trim his toenails. The case was widely described as the first major #MeToo trial in the gaming industry.

  

• Engaging in pay discrimination and blocked promotions. Women paid less than men for identical work, denied leadership positions, and steered into lower-compensated roles. Activision Blizzard settled a California Civil Rights Department lawsuit for $54.9 million over exactly these practices. Riot Games settled a parallel discrimination and harassment suit for $100 million, with plaintiffs documenting lower pay for women, blocked promotion, assignment to lower-comp roles, retaliation against advocates for diversity, and harassment that included an internal “Riot Games Hottest Women Employees” list.

• Forcing arbitration to bury harassment claims. Riot used forced arbitration to keep complaints out of open court. Staff walked out in protest in May 2019 after the company moved to force two plaintiffs in sexual discrimination cases into arbitration the previous month. Activision Blizzard’s 2021 walkout participants explicitly listed an end to mandatory arbitration clauses in all employee contracts as one of their core demands.

• Making all decisions by committee. Anthem famously had no single director making calls. Leadership decided by panel and then leaned on “BioWare Magic” to coalesce the project at the last second. It did not. Mass Effect: Andromeda had the same problem. Concord was similar: developers reportedly were not allowed to raise negative feedback during production, with a “toxic positivity” culture and a “head in the sand” mentality crushing internal pushback. The project went out the door already broken.

• Never letting layoffs get in the way of a well-earned executive bonus. Bobby Kotick was on track for a $200 million payout from a Shareholder Value Creation Incentive while Activision-Blizzard employees were skipping meals and using free company coffee as an appetite suppressant to pay rent, with internal documents showing pay gaps where employees earned a fraction of a percent of Kotick’s compensation. Bungie CEO Pete Parsons spent at least $2,414,550 on vintage cars over the two years that included two rounds of Bungie layoffs. Nintendo’s Satoru Iwata halving his own salary to avoid layoffs is the famous exception that proves the rule.

Ineffective strategy and direction

• Chasing those juicy trends. When NFTs were hot, every other publisher piled into Web3 gaming on the assumption that owning a pixelated sword on a blockchain would change the world. It very much did not. Roughly 93% of Web3 games failed after up to $15 billion in funding, with token values down 95% from their 2022 peak. The metaverse story is about the same: Mark Zuckerberg renamed Facebook around his personal vision of it, bet a mind-boggling $46 billion on it through Meta’s Reality Labs, and saw user numbers come in shockingly low before the company surreptitiously pivoted to AI instead.

• Never missing out on that sweet live service action. Sony reportedly spent around $400 million on Concord trying to clone 2016-era Overwatch in 2024. The game shut down in under two weeks. Sony’s broader live-service push, originally planned at twelve titles by March 2026, got cut after Concord, with the CFO admitting the strategy was “not entirely going smoothly.” Executives keep seeing one breakout, commissioning ten clones at the cost of billions, and then acting surprised when the market sustains zero new entrants.

• Pivoting hard, pivoting often, rebooting the game, and rebooting it again. Anthem was rebooted at least once and only started coming together months before launch. Microsoft’s flagship studio The Initiative spent years on a Perfect Dark reboot before the project was canceled and the studio closed in July 2025, with departing devs citing a lack of creative autonomy. Ubisoft’s Skull and Bones entered development in 2013 and shipped a decade later after constant gameplay overhauls, story rewrites and repeated attempts to rebuild the game around the live-service template du jour.

• Buying and closing great studios. Microsoft’s staggering mishandling traces back to the 2016 closure of Lionhead Studios after the cancellation of Fable Legends, which Xbox leadership has since openly described as one of their “biggest missteps.” The same dysfunction reappeared in May 2024 when Microsoft closed Arkane Austin, Tango Gameworks and Alpha Dog Games only three years after acquiring them through ZeniMax, killing off Hi-Fi Rush less than a year after a critically acclaimed launch. EA has spent decades buying and dismantling storied studios: Bullfrog, Westwood, Maxis, Pandemic and Visceral all came in with strong IP and creative cultures and left as shuttered offices. Embracer bought 60+ companies between 2020 and 2022 on the assumption that money would always be cheap, then shuttered Volition (30 years of history), closed Free Radical Design just before Christmas 2023 two years after reviving it, and shed thousands of staff after a $2 billion Saudi PIF-backed deal collapsed.

  • UPDATE JUNE 2026: add to Microsoft’s tally Ninja Theory, Compulsion Games and apparently Double Fine. Yes, Double Fine.

• Forcing the wrong game on the wrong team. Arkane Austin, known for excellent single-player immersive games, was put on a live-service multiplayer shooter. Most of the studio’s Prey veterans left during Redfall’s development and those who stayed reportedly hoped Microsoft would cancel it. Microsoft closed the studio after Redfall shipped. Sony ran the same play with Bluepoint Games, a studio famous for acclaimed single-player remakes like Demon’s Souls and Shadow of the Colossus, pushing it onto a live-service God of War project the team reportedly did not want to make. The project was canceled in 2025, and Bluepoint was shut down in the broader fallout from Sony’s live-service strategy.

• Reaching record profits and firing people to pump your stock value. The global games market hit $184 billion in 2023 while shedding 10,500 jobs that year, then 14,600 in 2024 (the worst single year on record), with an estimated 45,000 jobs lost from 2022 through July 2025 against rising annual revenue. Reporting on the layoff wave points to increasing reliance on outside investors and shareholders who prioritize short-term profits over long-term sustainability as a core driver, with studios shrinking to defend margins, not because they were failing.

Communication and HR theater

• Not owning up to layoffs. The more euphemistic the message, the better. “Strategic pivot.” “Right-sizing.” “Realignment.” “Restructuring.” “We’ve made select changes within our Battlefield organization to better align our teams around what matters most to our community. Battlefield remains one of our biggest priorities, and we’re continuing to invest in the franchise, guided by player feedback and insights from Battlefield Labs.”, said Electronic Arts after a round of lay offs affecting the people who worked on Battlefield 6, 2025’s best selling game, which sold an incredible 7 million copies in three days. Embracer framed its mass cuts as a “comprehensive restructuring program” after losing its $2 billion Saudi-backed deal. Unity called its 25% workforce cut part of a “company reset”. Sony cited “the evolving economic landscape, changes in the way we develop, distribute, and launch products” when it cut 900 jobs from PlayStation. Microsoft Gaming framed the Arkane / Tango / Alpha Dog closures as “prioritizing high-impact titles”. Ubisoft’s CEO called the 2026 round of layoffs and studio closures “necessary to build a more focused, efficient and sustainable organization”.

• Leveraging return-to-office mandates as covert layoffs. Used specifically to force resignations from anyone who relocated, has caregiving responsibilities or will not tolerate a new commute. Ubisoft opened a “voluntary departure” process in early 2026 targeting around 200 staff at its Paris HQ, roughly 20% of the office. Rockstar Games issued a full return-to-office mandate for GTA 6 developers, with management threatening to “pull the plug” on remote access for anyone who refused.

• Firing people right before Christmas. Over 300 game developers lost their jobs in a single day three weeks before Christmas 2024. Embracer shut down Free Radical Design on December 11, 2023, putting just over 80 people out of work right before the holiday. The timing is fiscal year-end housekeeping, not coincidence.

• Using NDAs to chill whistleblowing. Activision Blizzard settled an SEC action in 2023 over separation agreements that effectively muzzled employees from talking to regulators. The same Fortune reporting documented the SEC’s parallel complaint against EA for using NDAs that prohibited workers from sharing confidential information with outside parties, with no explicit exception for regulators. California’s Silenced No More Act gets routed around by re-labeling settlements as concerning “general workplace grievances” rather than what they actually concern.

• Engaging in Orwellian paranoia. MindsEye reportedly installed Teramind monitoring software on developer machines, recording keystrokes, screen activity and microphone audio in workers’ homes without consent, and is now facing legal action from its own employees’ union. Studio leadership blamed the game’s poor reception on internal “saboteurs” rather than on its own demands. Activision Blizzard runs a softer-looking version of the same thing, paying employees gift cards to use third-party tracking apps for reproductive health, sleep and fitness data under the label of a wellness program.

It doesn’t have to be like this

Every item above traces back to the same three-point logic: workers are treated as fungible costs, players are treated as wallets to extract from, and craft is treated as a problem to be solved with a spreadsheet (specifically a P&L and a portfolio tracker).

Unsurprisingly, studios that operate this way produce both worse workplaces, which produce worse games, which produce worse workplaces...

Look, those of us in leadership positions, those of us with the benefit of experience, those of us getting a little older and now looking into educating the next generation of game leaders and entrepreneurs, and those of us who give a damn, we have a responsibility to the actual human beings who make great video games.

I’m talking about the wonderfully geeky tech artist who miraculously keeps the pipeline running on duct tape and raw talent; the outrageously passionate concept artist who fills a sketchbook a month; the brilliant tools engineer whose work nobody sees but whose absence everybody feels; the QA analyst with encyclopedic knowledge of the genre and an instinct for the bug everyone else missed; the quirky and fun level designer who builds the moment that ends up on every highlight reel. All of these wonderful people who chose, against considerable economic logic, to spend their working lives creating magical worlds for other people to be enthralled by.

Those people deserve that we get it together already and forge a better tomorrow with and for them. It’s time for us to do better.

What’s your sense of all this? Have you gone through some of these practices? Is your studio turning the corner? Leave a comment.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

There’s been a lot of vitriol from gamers over the past few years about games made in Unreal suffering from performance issues. This misdiagnosis irks me to no end, so I want to share a few thoughts.

Let me first start with a few examples:

• The Callisto Protocol (Dec 2022): shader compilation stutter at launch was so bad it became the quintessential example used by Digital Foundry when explaining the problem.

• Lords of the Fallen (Oct 2023): launched with frame pacing and stutter issues across PC, Xbox Series X and Series S. Hexworks spent months patching.

• Immortals of Aveum (Aug 2023): one of the earliest high-profile UE5 titles. Launched with severe shader compilation stutter and ran poorly even on high-end hardware.

• Remnant II (Jul 2023): shipped with the studio openly stating the game was designed assuming upscaling (DLSS/FSR) would be on by default.

• STALKER 2: Heart of Chornobyl (Nov 2024): launched with severe traversal stutter, CPU bottlenecking in towns and a heavy reliance on upscaling to hit playable frame rates. Steam forum threads with titles like "Unreal Engine 5 is Garbage" and "Unreal Engine 5 killed the optimization of this game" were typical of the reception.

• The Oblivion Remaster (Apr 2025): built on UE5 over the original Gamebryo engine. Criticized at launch for performance issues even on Series X.

• Borderlands 4 (Sep 2025): struggled to clear 50 fps at native 4K maxed on an RTX 5090, and the console versions had memory leaks that required full reboots. Randy Pitchford’s statements certainly did not help.

• MindsEye (Jun 2025): probably the worst-received UE5 launch of 2025. A 5090 couldn't hold native 4K 60 fps. The upper end of how bad it can get when a team leans on photorealism without the time or capability to optimize effectively.

This is absolutely wild. Unreal doesn’t make your games pretty, or not pretty, or performant, or not performant. Neither does Unity, Godot, GameMaker or any of the other engines.

A game engine is just a tool. It’s like a ballpoint pen. You can’t blame your prose on the quill.

When a graphically-rich game made in an engine with a complex renderer and a laundry list of graphical features stalls, or has performance spikes, or caps at a miserable 30 fps, the cause is rarely the engine. It’s more often than not because:

1. The team got overly excited about all the visual bells and whistles that they could cram into the game and overdid it

2. The team didn’t leverage a solid profiler and realized the game is severely GPU-bound at the 11th hour, without any time left to undo the mess

3. The team didn’t set good GPU and CPU budgets, so the game spends five gazillion milliseconds on questionable post-process and has almost nothing left for static geometry

4. The team didn’t put in place an ongoing optimization strategy to ensure that the game doesn’t spike or dip and maintains a steady frame rate

5. The team didn’t properly optimize assets, nothing is getting culled and the game is rendering all the things ever all the time

6. The team seldom tested on dev kits, relied extensively on PC results without any hardware compat passes and now the game runs terribly on consoles

7. The team was too aggressive with its target min spec

Notice the common denominator here: the team. Not the tool. The team. Are game engines perfect? Consistently not even close. Do high-fidelity games ship without major performance problems? All the time. See Avowed, Kingdom Come: Deliverance, Indiana Jones and the Great Circle, Death Stranding 2, Clair Obscur: Expedition 33, Horizon Forbidden West, Alan Wake 2, etc.

There are two reasons why Unreal 5 specifically takes so much flak from gamers. The first is that it’s the engine that devs use to make graphically-demanding games. You don’t make RTX 5090-melting games on GameSalad Creator or Roblox Studio. So when something goes wrong in a high-fidelity game, it tends to be made with Unreal. And the second reason is that gamers don’t really understand how the remarkably complex tech stack powering enormous AAA games works. Which is absolutely fine, why should they? I don’t understand aviation but that doesn’t keep me from getting awfully pissy and opinionated when my flight is late.

“Most developers begin by building for the highest-end hardware, then only in the final stages do they optimize and test for lower-spec devices,” he said. “That late-stage approach is the key reason players experience performance problems.”

I seldom agree with Tim Sweeney, but he hits the nail in the head with that statement.

If you’re a developer and you don’t want to be on the receiving end of your gamer’s ire, the 7 bullets above are worth putting on your backlog as ongoing checks. Performance, memory, streaming, and critical cert requirements need to be actively managed from preproduction all the way to the game being live.

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

Game development is, structurally, a conflict-generating environment. That’s not a criticism. It’s just the nature of the beast.

You’re putting people from radically different disciplines in a room together, like engineers and artists and designers and QA and community managers, people whose entire professional vocabulary, workflow, and definition of “good work” can be almost mutually incomprehensible, and you’re asking them to build something together that didn’t exist before. The work is creative and very often deeply personal. When someone critiques your design system or your animation or your level, it’s hard not to feel it a little, even when you know intellectually that’s not how it was meant.

The people doing this work, deep in the trenches, tend to be comparatively young, often in their first or second significant professional environment. Many are working across nationalities and time zones. And you add to that a milestone that’s slipping, a publisher breathing down your neck, a team that’s been in crunch long enough that everyone’s running on fumes, and you have a genuinely complicated human environment in which conflict isn’t a sign that something has gone wrong. It’s a near-certainty.

Conflict is inevitable. That’s okay. The question at hand is whether you’ll manage it constructively or not.

In a five to twenty person studio, there’s no organizational buffer. Conflict between two people doesn’t stay between two people. It radiates. Everyone adjusts their behavior around it, routes information differently, picks sides without realizing. At a large studio you can go around a cold war between two senior people. On a small team it’s effectively a studio-wide problem.

So let’s talk about how to actually deal with conflict in game teams.

Root-cause analysis

The instinct when something feels off on a team is to jump straight to the people. Those two hate each other. That person is difficult. This lead is impossible to work with.

Sometimes that’s true. But in my experience it’s not quite the optimal place to start, and starting there can cause more damage than the original problem because it might misdiagnose what’s actually going on. If you fix the wrong thing, the issues remain. And now you’ve also burned some trust in the process.

A framework I came across recently, developed by Molly Graham, who has spent two decades working inside companies like Google and Facebook and advising founders at Stripe, Anthropic and others, articulates this really well. She calls it the Waterline Model. This model is thoroughly explained in her excellent article on Lenny’s Newsletter, but let me give you a quick rundown in the context of game development.

The image is a boat on the surface of the water: the boat is your team, the destination is shipping the game. When things aren’t working, the question isn’t who’s rowing wrong. It’s what’s going on below the surface.

The model gives you four layers to examine, in order. And the rule of thumb that comes with it is worth tattooing somewhere: snorkel before you scuba. Start at the top, work down, and only go deeper once you’ve ruled out what’s above.

Structure is the first layer, just below the surface, and it’s where the majority of team problems actually originate. Structure is everything that helps people know what they’re doing, why they’re doing it, and how success is defined. Vision, goals, role clarity, ownership of decisions. In a game studio, this entails things like: who owns art direction? Or who can override a level design call? Or when the game director and the lead designer disagree, what happens? If those questions don’t have clear answers, you don’t have a people problem yet. You have a structure problem. Structure problems generate interpersonal challenges constantly, reliably, and they can be easily misinterpreted as personality clashes.

Dynamics is the next layer down. You can have clear roles and still have a team that doesn’t function, because dynamics are about what actually happens day-to-day, not what’s written down. The clearest way I can put it is like this: dynamics are the unspoken rules the team has learned about how things actually work here, as opposed to how they’re supposed to work on paper.

A few examples of what dynamics problems look like in a studio. A lead designer who technically owns design decisions, but whose calls keep getting surreptitiously reversed by the game director after the fact, so the team has learned to wait for the game director to weigh in before they treat anything as final, even when they don’t need to. A culture where nobody raises concerns in standups because the last few people who did got a defensive reaction, so now everyone says “all good” and saves candor for hallway conversations with trusted teammates. Or a feedback process that exists on paper but where everyone knows that critical feedback on the game director’s work doesn’t actually go well, so people have stopped giving it.

In each case the team isn’t behaving badly. They’re actually behaving quite rationally given what they’ve learned. Dynamics problems seldom get solved by adding more process (a new meeting, a new doc, a new feedback template, etc.) They get solved by changing the messages the team is receiving about what’s actually safe and what isn’t.

Interpersonal is the third layer. Real interpersonal conflict exists, it’s a thing. Two people who fundamentally don’t trust each other will slow down decisions, hoard information and fracture the team around them without any particular drama. But a lot of what looks like interpersonal conflict is actually structure. For instance, two leads who keep stepping on each other’s toes probably have overlapping ownership. If you sort out who owns what, you’ll probably see half the tension evaporate. Here’s a test you can use: if you clarified the structure tomorrow, would these two people suddenly get along fine? If yes, it’s a structure problem. If the answer is genuinely no, then you’re dealing with the relationship itself, and that requires a different kind of conversation.

Individual is the deepest layer and the one to reach only when everything above it has been examined and reasonably addressed. If the structure is clear, the dynamics are healthy, the interpersonal relationships are functional, and someone is still not performing or still generating unhealthy tension, then you’re looking at something specific to that person. It can be a skill gap, something going on outside of work, a values mismatch that went undetected in hiring or something else. At that point the work isn’t diagnostic anymore but about action.

The discipline the model asks of you is to stay at the top as long as there’s anything there to fix, because structural and dynamic problems affect everyone simultaneously and fixing them has the highest return. Only go deeper when you’ve actually cleared what’s above.

Difficult conversations

Diagnosing the layer correctly is half the work. The other half is actually addressing it, and this is where studio leaders sometimes either delay too long or handle it poorly when they finally do it.

The delay is understandable. These are uncomfortable conversations (more on this here). The team is small, everyone knows each other, and the social cost of a difficult conversation gone wrong feels disproportionately high. So people tend to wait in the hopes that things resolve themselves somehow. But they rarely do. What actually happens is the problem solidifies, the team organizes itself further around the avoidance, and by the time someone decides to address an issue, you’re not fixing a small thing anymore.

So, my obvious suggestion is of course to address things early. Before they become “a thing”. The conversation is easier at the beginning, when the behavior is recent and specific, than six months later when it’s become a pattern and everyone has strong feelings about it.

When you do have the conversation, the Center for Creative Leadership’s SBI Model is worth taking a look at (I touched on this already in a previous article). SBI stands for Situation, Behavior, Impact. It’s a structure for keeping a difficult conversation grounded and non-accusatory:

Situation: name the specific context. Not “you always do this”, but a specific moment. “In last Tuesday’s design review...”

Behavior: describe what happened, not what you think it means. “You overrode the call after the team had already moved forward with it.” Not “you undermined the team.” It’s about the observable behavior, not your interpretation of it.

Impact: describe the effect, ideally on the work. “The designers spent two days on something that’s now being scrapped and two of them have stopped proposing solutions in reviews.” This is the part needs to be delivered with the most empathy.

That structure separates the person from the behavior. It makes the conversation about a specific thing that happened and its consequences, rather than about who someone is. People can respond to that. They can change a behavior. They can’t change who they are, and conversations that imply they should or that attack someone’s identity tend to get defensive fast.

One more thing on the conversation itself: please be truthful. Not the overly-diplomatic version, not the “soft landing” that leaves the other person unsure whether there’s actually a problem, and certainly not the shit sandwich technique. Studio culture in my experience tends toward excessive politeness in exactly the moments where respectful directness would do more good. The feedback doesn’t really have an impact, the person doesn’t quite understand the gravity of it, nothing changes, and three months later you’re having a harder version of the same conversation. Say what you need to say, with the SBI structure to keep it grounded, and then actually listen to the response with kindness, curiosity, empathy and a genuine desire to make things better.

The employer challenge

If you’re a founder, employer, director or primary authority of some kind, you have an additional challenge to deal with (I touched on this before): you are simultaneously a party to the conflict and the person responsible for resolving it.

That’s not a solvable structural problem. It’s just a reality of the role, and the way through it is the same thing I described in that earlier article: the team has to believe, based on your actual behavior not your stated values, that honest feedback doesn’t carry real personal risk. If they don’t believe that, they’ll stop offering it. And then you’re in a catch-22 situation.

What good actually looks like

Some of the most commercially successful studios I’ve worked with or observed were demonstrably terrible at this. Conflict-averse, or outright conflict-disaster environments, with revolving doors of talent and years of low-grade dysfunction baked into the culture. And some of them shipped good games anyway, made money, built franchises.

So I’m not going to tell you that resolving conflict well is the thing that determines whether a studio survives. It isn’t, not always.

What I’ll say instead is this: the studios where people actively choose to stay, where they talk about the place years later with something that sounds like affection rather than relief at having escaped, where talented people line up to work rather than quietly using it as a stepping stone, those studios have figured out how to keep the honest conversations alive. They have conflict, plenty of it, and it doesn’t always get resolved cleanly. But it gets addressed rather than suppressed. People disagree face to face instead of in the hallway afterward. And when things go wrong, which they always do at some point, the team is still intact enough to navigate it together.

That’s what you’re building toward. Not a studio without disagreements but a studio where disagreements don’t get to fester.

If this was useful, you might also like:

How have you dealt with conflict at your studio? What have you learned in the process? Share your thoughts in the comments.

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

The playbook for “innovation culture” typically looks like this: you set aside 20% “creative” or “pet project” time, run quarterly hackathons, put up a poster about psychological safety and maybe schedule a TED talk about “failing often and fast” at the all-hands. But two years later, the game the studio shipped was somehow “just okay”, because originality was not really, truly fostered in the team. It was more like decoration in the shape of posters and programs that, technically, check all the right boxes.

The studios that ship original work do something different than that. What produces a Hades, or an Elden Ring, or a Cuphead is not so much a program, but a stack of interlocking practices, rolled out slowly and protected frantically.

This article, which leans heavily on scientific research and empirical evidence, is about the creativity-fostering conditions that separates studios that consistently produce original games from the ones that talk about it. Six conditions. They are mutually reinforcing, which means implementing one of them in isolation doesn’t really do all that much. They map closely to what the research actually says about how creativity works in teams.

The decoration problem

In an organization whose default behavior is not to support creativity, “Innovation Fridays” just don’t really move the needle. A team that gets one day a week to “be creative” (as if you could summon creativity on command) spends the other four days being told to hit a milestone, and the creative day produces prototypes that no one has the budget or executive sponsorship to actually build. The intention is good, but the work is done in a neat little sandbox the rest of the company just won’t really have a chance to get behind.

I’m not speculating about this. David Burkus’ The Myths of Creativity walks through the empirical record on brainstorming, idea contests, suggestion boxes and the rest of the standard interventions, and the data on most of them is frankly not encouraging. These practices do reliably produce more ideas. What they do not reliably produce is more shipped, realized originality. Teresa Amabile’s componential theory of creativity, refined over a whopping thirty years of studies, highlights the underlying reason: creativity is driven by intrinsic motivation, and most “innovation programs” are extrinsic motivators. It’s that simple. A hackathon with a prize is a contest. A 20% time policy with a manager checking in on it is, in a way, a deliverable.

What actually works is changing the organization itself.

1. Independence is a precondition

Swen Vincke at Larian has said, more than once, that the studio’s independence is what allowed it to take wild chances on Baldur’s Gate 3. He’s also said he was willing to sacrifice anything, including rewriting whole engines (which I can seldom imagine being a good idea), to ship the game in the state he wanted. Those two statements are actually connected. He could rewrite the engine because no publisher was holding him to a milestone payment schedule that required the old engine to be used or that didn’t account for that technical body of work.

This may sound a little ideological but it’s not. Studio independence is a structural precondition for being able to kill a prototype, change a major system or extend a production cycle without owing someone an explanation. The moment you’re on the hook for milestone with the publisher, every “we should try a different approach” conversation gets routed through a contract amendment. After the third or fourth amendment, the team sadly learns to stop suggesting different approaches. That’s not conducive of innovation.

You can see something similar at FromSoftware, which famously released the first couple of Souls games to somewhere between mediocre and okay commercial reception, and was protected from publisher pressure long enough to build the franchise that now defines the studio and that spawned an entire new genre. You see it at Klei, which stayed self-funded until 2021 and used that period to make Mark of the Ninja, Don’t Starve, Oxygen Not Included, all exceptional and very different games from each other. You see it at Supergiant, which has remained independent across four different IPs and has explicitly refused to run parallel projects so that one game gets the team’s full attention.

You can see the same pattern in the research. The seminal Self-Determination Theory, developed by Edward Deci and Richard Ryan over four decades, identifies autonomy as one of three psychological needs that drive intrinsic motivation.

Without autonomy you can keep people busy, but you can’t keep them creative. In a game studio autonomy is independence.

But alas, independence comes at a price. If you walk away from term sheets you genuinely need, sometimes a competitor with publisher backing reaches a market window before you do, or sometimes you just run out of money and have to fold. What you get in return though is the ability to kill a prototype that isn’t working without owing anyone an explanation, and that ability is the foundation everything else in this article depends on.

2. Clearly led small teams

Klei had eleven people in 2009, thirty-five by 2013. Supergiant has stayed small enough across four projects that “no parallel projects” is a stated policy. House House made Untitled Goose Game with four people. The studios that ship original work tend to be smaller than the work hints at, and they tend to defend that size against the natural and/or financial pressure to grow.

It comes down to coordination overhead, which rises faster than headcount. The marginal hire on a team of forty is quite possibly making the team less responsive, not more. Small teams can hold the game in their heads. Large teams have to externalize the game into documents, and in many cases, the documents become the game, which is not great.

The thing that goes with smallness, and that is equally important, is clear creative direction. Hidetaka Miyazaki at FromSoftware has said the priority on Elden Ring was “a feeling of exploration above everything else.” Jenonva Chen at thatgamecompany has said his teams “start by mapping out what the game should make the player feel,” and that mechanics derive from that target. These directors are not running design-by-committee. What they’re doing is running small teams with a strong creative spine, which is a very distinct and clearly effective structure.

Pixar is perhaps the clearest benchmark. Ed Catmull’s Braintrust, described in Creativity, Inc., is the standard version of how this combination works in a creative production. Very experienced peers review the work in progress, give brutal candor about what isn’t working, but have no authority to mandate changes. The director keeps the keys. The team stays small enough that the director can actually direct. The candor stays high because the director isn’t being threatened by it. At least in principle.

Valve is the test case for what happens when you skip the “clearly led” part of this equation. The flat-structure handbook is one of the most-circulated org documents of the last fifteen years. The reality though, as former hardware lead Jeri Ellsworth and others have described it publicly, is that Valve’s flatness inadvertently produced a hidden layer of powerful management plus chronic resource starvation of risky projects on the game development side of the company. Flatness without strong creative direction can easily degrade into politics, where the most well-connected people, and those with the loudest voices, pull resources toward sure-thing work, keeping the genuinely risky work from ever reaching the surface.

The studios that ship original work tend to hold these two lines together. Kept small enough to actually iterate and kept centered on someone who can actually provide effective, creative direction.

3. Ritualized visible failure

In 2007, Tim Schafer at Double Fine introduced what he called Amnesia Fortnight. Every employee drops their current work for two weeks and joins a small group prototyping a brand-new game. Several of those prototypes became shipped Double Fine titles. The ritual has been run repeatedly, sometimes publicly with fan voting. Schafer credits the inspiration to film director Wong Kar-Wai, who took the Ashes of Time crew off to Hong Kong mid-shoot to make Chungking Express and Fallen Angels for fun. Both of those films received better critical reviews than Ashes of Time.

Amnesia Fortnight isn’t really about the prototypes. What it does is institutionalize prototyping as a public, visible, scheduled activity that the whole team participates in. Everyone knows when it’s happening. Everyone knows the work will be shown. Everyone knows most of what gets made will not become a game, and that’s fine, because the cultural understanding is that this is how the studio makes games.

Supergiant does this through Early Access. Hades shipped in Early Access for two years, Hades II for about eighteen months. Greg Kasavin has said the team’s working principle was “not being too precious about these things when they exist in service of a cohesive whole.” The team killed and replaced systems in public, with a paying community watching. The visibility was critical for them and their process.

The most extreme form of this that I know is Supercell. They are a mobile company so they’re outside of my usual game development analyses, but I find their ritual to be pretty darn cool. When Supercell kills a project, the team that made it pops champagne. The way they frame is that it’s not failure itself that they’re celebrating, but the courage to take a swing, and to learn from it. Their CEO Ilkka Paananen said in 2023 that the studio had killed thirty-plus games against five hits over more than a decade, including Everdale, which had a real soft launch and a real player base before the team called it. The champagne ritual is the cultural mechanism that transforms the kill from a failure event into a normal step in the creative and product development process.

The Edmondson research on psychological safety, particularly her work on what she calls intelligent failure, describes what these studios are doing in academic terms. The Frazier meta-analysis confirms that psychologically safe teams produce more creativity, more information sharing, more learning behavior. Keith Sawyer’s research on group flow, summarized in Group Genius , adds that jazz ensembles almost never reach group flow during rehearsal, only during performance, because flow requires the real possibility of public failure.

A team that can’t fail visibly is less likely to reach the conditions that produce the good stuff.

A decent barometer for culture is whether a killed prototype is treated as data or talked about as wasted budget. If it’s the second, no number of Amnesia Fortnight clones will fix it.

4. Constraints

Russian composer Igor Stravinsky said you cannot create against a yielding medium. Art needs resistance. Patricia Stokes’s Creativity from Constraints builds a case from the lives of artists, designers and architects: the breakthroughs tend to come from self-imposed restrictions, not from blank canvases. Cromwell’s 2024 review in Organizational Psychology Review pulls together the empirical work and finds an inverted-U shape.

Too few constraints and the team flounders. Too many and the team can only execute. The middle band, the goldilocks zone where constraints force invention but leave room to invent, is where creativity peaks.

Studios that produce original work brag about their constraints rather than apologize for them. Studio MDHR built Cuphead under the explicit constraint of hand-drawn 1930s animation. Every visual problem became “how do we solve this in cel-style.” Think about it: most of what makes Cuphead recognizable is a consequence of that single constraint. House House made Untitled Goose Game with four people and a small scope, and the small scope is part of the appeal. Jenova Chen describes thatgamecompany’s design discipline as a Japanese garden rule: the design is right when nothing more can be removed.

Another constraint that may fly under the radar, but that many great studios use, is “no parallel projects.” I touched on this briefly already, but Supergiant has remarkably held this line for sixteen years. And it costs them. They can’t scale, they can’t run a big experimental side project, they can’t hedge. What they get though is a team where every person is working on the same thing at the same time, where decisions about that thing don’t have to negotiate with another team’s roadmap and the game gets the studio’s full creative attention. And that shows in spades in the results.

Studios that don’t hold this “no-parallelization” constraint sometimes end up having a sequel, a port, an expansion and a new IP in production all at once. The team gets split four ways, the new IP gets whatever attention is left over after the safer projects are staffed, and nobody pushes for any serious creative risk on it in review meetings because everyone is already stretched to the max.

5. Time architected so pressure and exploration alternate

Amabile and her team analyzed over 9,000 daily diary entries from people doing creative work and published the results in HBR as “Creativity Under the Gun” (also here) . The finding most relevant in this work is the four-state grid below for how creative work actually behaves under different time conditions:

• High pressure with focus is “on a mission,” and creativity holds up

• High pressure without focus is “on a treadmill,” and creativity collapses

• Low pressure with curiosity is “on an expedition,” and creativity peaks

• Low pressure without curiosity is autopilot, and nothing useful happens

Something that should make every producer take a moment and assess is the data on perception. Workers under treadmill conditions report feeling more creative on those days. But they’re actually producing less. The subjective experience flips the objective output, which is one reason the standard AAA crunch model produces so few original ideas. It generates the feeling of intensity without the actual creative work.

The studios that ship original work tend to deliberately architect time as alternating between mission states and expedition states. In principle, Larian rewriting an engine rather than ship a broken Baldur’s Gate 3 is a mission state. High pressure, sustained focus, the team knows exactly what they are trying to do and why. Supergiant’s Early Access is closer to an expedition state. The pressure is real, but the curiosity is the point, and the team is allowed to follow what’s interesting in the playtests rather than crunch toward a fixed feature list.

What you seldom see in studios that produce original work is the full-year treadmill, where the milestone keeps shifting, the priorities keep getting reshuffled and the team is continuously stuck in the high-pressure-without-focus quadrant. The studios I worked with that lived in that quadrant produced exactly zero original mechanics in the years they spent there. They shipped, and what they shipped was competent and forgettable.

The type of slack time that actually works isn’t “Innovation Friday”, but the protected expedition period, which is a stretch of weeks or months where the team doesn’t have a milestone, doesn’t have a deliverable, doesn’t have a manager checking in on what they made. They read, they play, they prototype things that have no roadmap claim. They invite curiosity and creativity to flourish. Studios that say they have this often don’t, because there’s always one more milestone. I wouldn’t be surprised if the studios that do can point to specific shipped games that came out of an expedition period.

6. Kindness in hiring with actual behavioral consequences

Tim Schafer has said, on the record, that he doesn’t hire mean people. He hires for kindness alongside talent and treats kindness as a precondition rather than a tiebreaker. This is a pretty important component of the stack that I would wager a lot of studios don’t think enough about.

Psychological safety doesn’t last without norms that protect it, which is what Edmondson’s 1999 paper and the Frazier meta-analysis both find. A team where bad behavior is tolerated as long as the results are there isn’t a psychologically safe team for everyone. It’s psychologically safe for the person behaving badly, and increasingly unsafe for everyone else. Over time, the people who could be honest about a struggling prototype stop being honest, because the loudest person in the room punishes anyone who slows them down. The candor evaporates and the Braintrust becomes theater.

I worked at a studio a while back where this was the modus operandi. Bad behavior was totally acceptable as long as the results were there. The senior people who delivered were given enormous behavioral latitude, and the people who flagged the cost of that latitude were treated as a problem. The official line, as you would expect, was that we had a “culture of excellence”. But the actual culture was defensiveness, internal politics and an inordinate exodus of senior-level talent who had options elsewhere. The games that came out of that period were technically impressive and creatively unremarkable, and the people who could have made them more interesting had either left or learned to stop trying.

This is also where the defining Project Aristotle story (which I have referenced and advocated for before) needs a little qualification. Google’s claim that psychological safety is the most important factor in team performance is famous, but, as Dennis Adsit and others have pointed out, the study has never been independently replicated, the methodology was never published, and the social-psychology field has a replication crisis that should make any single unreplicated finding suspect. What is solid though, across Edmondson, Frazier and the broader literature, is that safety reliably correlates with creative output across many studies, and that safety requires norms that exclude the people who would otherwise destroy it.

The studios that ship original work are not soft. They are kind, which is a very important distinction. They fire for behavior, not just for performance. They protect the people who would otherwise be eaten by the loudest person in the room.

The cost is that you sometimes lose a productive talent who can’t operate inside those norms. And the benefit is that the rest of the team can.

The conditions are synergistic

The six conditions don’t act independently, which might be easy to miss when reading a list like this. They’re a system. Take any one out and the rest might just start failing. Independence without small teams might give you a director who’s drowning in scope. Make failure visible in a team without intrinsic motivation and you get Braintrust theater. Pile constraints onto a treadmill schedule and the team burns out before the constraint forces invention. Tolerate bad behavior in an otherwise kind hiring policy and the safety collapses for everyone except the loudest person.

My observation from the prep work for this article is that studios that shipped original work implemented the stack as a stack. I would guess that most of them didn’t do it entirely consciously. They probably figured out one piece, then the next piece, then the next, over many years and several near-death experiences, and what they ended up with was a whole organization tuned to keep the conditions in place. The rituals everyone copies (Amnesia Fortnight, Early Access, the Braintrust, the champagne) are just the visible elements. The invisible and truly important one is the structural commitment underneath, which is what makes the rituals work.

If you are building or running a studio and you want cultivate a culture of experimentation, more than wonder which program to implement, you should think about which condition you can credibly nurture first, which one you’ll need to foster next and which one you are willing to pay the cost of maintaining when the cash gets tight or the schedule slips or the loudest person in the room starts arguing for an exception.

If you want to go deeper

A short list:

• Ed Catmull, Creativity, Inc. (2014). The operational manual. The Braintrust chapters are the most relevant.

• Amy Edmondson, The Fearless Organization (2018). The clearest book-length treatment of what psychological safety actually is, and isn’t.

• Keith Sawyer, Group Genius (2007). The empirical work on group flow, with a lovely working knowledge of jazz that informs the whole argument.

• David Burkus, The Myths of Creativity (2013). Brainstorming and innovation contests, with the actual data on how poorly they perform.

• Patricia Stokes, Creativity from Constraints (2005). The case from artists’ lives. Stravinsky’s tonality, Picasso’s blue period, Frank Lloyd Wright’s site rules.

Five books gets you most of what the literature has to offer. One way or another, the studios are doing what the books describe.

What’s your take on how to best foster creativity? What have you seen work? Leave a comment.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

Gemma 4 is running locally in the background as I write this. Claude Code has been nearly indispensable on my small Godot pet project. I make assets on Pixellab. I mocked up some images on Gemini this morning. AI is very present in my day-to-day.

And so is the dread.

More than 14,000 game industry workers lost their jobs in 2024, and the number since 2022 is somewhere around 45,000. Behind those numbers are people. Animators with a decade of incredible craft sending resumes into a market that seems to care less and less. Writers who spent twenty years learning how one line of dialog can make or break an entire game, watching their phrasing get pattern-matched and regurgitated by something that has never been able to feel anything. Junior artists who finally got to break into an industry they had dreamed about since childhood, getting cut before they could even take their first steps in game development. AI did not cause every one of those layoffs, but it’s very much present in the math behind them.

And yet, I am using these tools, every day. The rest of this article would be dishonest if I did not disclose that. They have given me hours back, I am building things I could not have built two years ago, studios I look up to are using them. solo developers are shipping commercial games on Steam they could not have shipped a year ago.

“The technology is both wreaking havoc on labor, while also opening doors that were locked yesterday.”

I think many, if not most game developers reading this are in a somewhat similar place I am in. Using it, watching it, pissed off about parts of it, weirdly grateful for other parts, and unsure what to do with the contradiction. I am unfortunately not going to resolve that for you. I strongly doubt that anyone can right now. What I can do is share what I learned through my deep dive, sort what’s credible from what’s speculation, walk through what level of AI is found in shipped games and what is still vendor hyperbole, be transparent about what we don’t know, and offer a few questions worth asking yourself about your own situation.

This article pairs with Abbas’ “The Studio × Tier Framework”. His companion article explores the more macro level of AI in our industry. He drew a really cool strategic map, the Automate Freely / Augment Carefully / Protect Fiercely categories. I am walking through what that looks like at the more tactical level. Some things we agree on, some things maybe not so much, and I’m deeply grateful for the diverse, and invigorating exchange of ideas.

Is this one different from the last four?

I don’t know if other game developers are going through the same thing or not, but I’ve definitely been asking myself for the past couple of years whether this is another “Kinect will revolutionize your living room” moment, or another “VR is going to change the world” moment, or another “blockchain is going to be the new internet” moment, or God forbid another “the metaverse is going to reshape society” moment. I had a front-row seat to each and everyone of those pseudo-existential “this is the new industrial revolution” labor moments and I still get major Captain Picard facepalm vibes when I think about them.

I’ve been very diligent about not cursing on my Substack thus far, but it would be a bit dishonest of me not to state in plain English what a colossal load of bullshit all that hype mongering has been. Countless studios had to rearchitect pipelines, fire people they didn’t want to fire, hire people they didn’t need, waste time learning about clearly not very relevant technologies, force features in where they didn’t fit (I’m looking at you, NFTs: how’s the “democratization of ownership” going?), ship games for audiences of less than 10, and ultimately watch most of these messianic technologies limp away in the middle of the night.

So yeah, I think I earned the right to be skeptical about generative AI. My trepidation doesn’t come from nowhere.

With all that said, three things about AI very clearly don’t fit the old pattern of BS.

First: AI is already being used in production. Ubisoft has used Ghostwriter for ambient NPC dialogue for years now (I’m not suggesting you like it, but it IS there). Sandfall used AI selectively during development on Clair Obscur: Expedition 33. And code assistance is undeniably pervasive across a large number of studios, as well as outside of our industry.

Second: the people who hate it, or who are really conflicted about it, like me, are using AI. A lot. The Venn diagram of “developers who think AI is bad for the industry” (52% per the GDC 2026 State of the Industry survey) and “developers who personally use AI tools” (36% in the same survey) overlaps plenty. I don’t remember that happening with past hype techs.

Third: studios and publishers started restructuring their headcount around AI's promised productivity well before AI actually delivered on that promise. The "well before" part is the salient phrase: with VR or blockchain, capital threw money AT the technologies but didn't restructure their workforces around assumptions about it. The 45,000-ish layoffs since 2022 have plenty of causes (macroeconomic and political instability, post-pandemic correction, end of cheap money, mature-market saturation and more), but the AI assumption is a sizable factor. Studios are hiring fewer juniors than they used to. Publishers and investors are pushing for smaller teams shipping bigger games. Whether that bet pays out is a separate question. But this is happening.

This one is indeed different from past tech vaporware.

Areas with credible impact

OK, let’s talk brass tacks. AI in games gets talked about at one of two altitudes: too abstract to evaluate (”OMG, it’s the future of creative work”), or too conveniently cherry-picked to trust (”this 4-second cinematic made entirely with AI. We’re going to be making Hollywood films with zero people in 6 months”). That’s not super-helpful.

Below are a series of mini-discipline-by-discipline analyses that hopefully live somewhere in the middle, where tools work in a real production pipeline, don’t, contribute some but not a lot, or we just don’t know yet.

Voice. AI is already in production today for things like ambient NPC barks, item-name speech, location callouts, voice-driven ping systems, compass directions, etc. Simple, short voice shots. Embark‘s Arc Raiders runs an internally trained text-to-speech model on its own actors’ performances, used to generate every item and location callout in the game without re-recording. They reversed some lines back to human takes after launch criticism, but the system shipped and it admittedly works. ElevenLabs is widely used for work-in-progress placeholders and it’s pretty great at that. Hero performance voice acting though? Not even close at the moment.

Concept and ideation art. This is working, but at a cost. Game studio Lost Lore claims to have generated 17 character concepts in under a week using Midjourney plus in-house refinement, against 34 business days previously. Highly contextual but a clear proof of viability. Sandfall used similar tools in pre-production for Expedition 33. The cost for these is decision fatigue: art directors can now get drowned in 200 generated options, and the bottleneck moves from drawing concept art to evaluating, selecting and providing feedback for iteration. Studios with sufficient direction capacity can probably benefit from real time savings.

3D modeling, texturing, UV layouting, skinning. Partially working. Tripo, Meshy, Rodin and Tencent’s Hunyuan3D produce meshes that are concept-quality, but not production-quality. The polycount comes in heavy, the UVs come in messy, and the skinning isn’t there at all on stylized characters. Adobe’s Substance 3D Firefly integration does decent work on materials. From the production-readiness reviews I’ve come across (the SimInsights breakdown is a good one), maybe one in ten generations comes out usable on background props without rework, and effectively zero on hero assets. At this point, I believe the best use case for these tools is as concepting and blockout aids, not with the expectation of production-ready or shippable assets.

Rigging. Working reasonably for biped humans. I think. Mixamo, AccuRIG and AutoRig Pro can take a biped human from concept to a usable rig in minutes. Manual biped rigging by an experienced rigger, in my experience and what I’ve seen from talking to peers, can run anywhere from a half-day to four days per character depending on complexity (say, not Kratos, not Wukong), so the time saving can potentially be significant. Anything stylized, anthropomorphic, multi-limbed or non-human still needs a human rigger, as far as I can tell. The “AI rigging” do-it-all magical solution is mostly biped humans only. And with caveats.

Animation. Partially working. Cascadeur seems useful for keyframe assistance and pose interpolation. Mocap cleanup tools seem to have improved a fair bit. EA claims to have expanded their run cycles in EA Sports FC 24 from 12 to 1,200 using generative blending, which is a bananas claim that is probably pointing at procedural work, but still. Hand-keyed character animation for hero work probably remains unchanged. The repair-labor role (the animator who can fix a mocap clean-up) might now be a more valuable specialization than it was three years ago.

VFX. For what I can see, which is unfortunately not much on this front, efficiency might be compressed at the technical solver level (smoke, fluids, particles, ML-driven simulations), and almost untouched at the directed-shot level. The ultimate cinematic VFX moment in your game is unlikely to be impacted by AI in the next couple of years, but I admit that I don’t say this with a high degree of certainty.

Audio and music. Work seems to be compressed at the placeholder, ambient and pre-vis stages. Adaptive scoring tools (Soundraw, Beatoven.ai) are usable for stem-layered ambient beds. Hero compositions and signature themes are still human work, and the studios trying to AI-generate the main theme of their game are either doing so because they don’t have a strong opinion about what the main theme should be or they’re just working on a shoestring.

Cutscenes. This is the area where my assessment changed as I did research for this article. The AI video generation tools are advancing very fast. Higgsfield Cinema Studio, Magnific, Veo and Kling are producing full-motion video at a quality that, even accounting for the visible glitches, continuity problems and defects, is impressive. Humbling, even (I believe the short film below is representative of where the quality bar is at the moment). Small film teams are now actively using these tools to produce work at near-Hollywood ambition without near-Hollywood budgets. For shipped game cutscenes specifically, no major title has yet used AI for a final cinematic moment as far as I can tell, and Microsoft’s Muse model is still research-stage. But the gap between “AI cutscene tools are too rough to ship” and “AI cutscene tools can ship inside a game with a clear stylistic envelope” is closing fast, and I would not bet on it being a hard no for much longer.

Code and gameplay programming. Very much working in studios across the industry, oftentimes without studio leadership being aware of how widespread it is. Cursor and Claude Code are now used to drive the Unreal Engine 5 editor. GitHub Copilot has a native plugin. The GDC 2026 numbers put code assistance at 47% of personal-use cases. The actual figure inside working studios is probably higher than that, because individual developers are not always logging or disclosing their use. The new bottleneck (more on this later) is most likely code review instead of code authoring. So how much of an impact does AI have in software engineering for games? It’s all over the place, ranging from dramatic (i.e.: non-programmers vibe-coding what they otherwise couldn’t) to minimal. But I think the pervasiveness of the code assistance tools sends a strong message.

QA and playtesting. There are some efficiencies for things like crash discovery, exploration coverage and pathing edge cases. Purpose-built tools like modl.ai (game-specific QA bots that simulate gameplay and player behavior across Android and desktop, without SDK integration), GameDriver (Unity and Unreal test automation with an AI-assisted Test Assistant) and Regression Games (AI agent testing for Unity) cover much of this territory, with Applitools handling visual UI regression. On the player-research side, PlaytestCloud and similar platforms claim to now use AI to analyze recorded sessions and surface themes within hours rather than weeks. EA’s reinforcement-learning agents have been used to autonomously playtest first-person shooter games, increasing test coverage and discovering bugs that human testers might miss. Untouched for feel bugs: the camera pop, the mistimed sound cue, the input lag at 5%. Bottom line: some automation starting to surface, but the more critical, judgment-centric efforts remain entirely in the human domain.

Game design, level design, system design. Largely untouched where design decisions get made, with one notable caveat. AI-assisted level dressing tools are there and being used. Promethean AI populates 3D environments from natural-language descriptions (”a medieval tavern with wooden furniture, dim lights, and a fireplace”) and integrates with Unreal, Unity, 3ds Max, Maya and Blender. Unity Muse generates assets, edits scripts and helps with layout decisions inside the editor itself. So while I can’t attest to the quality, at the level-dressing and asset-population end, AI is working. The more profound questions of whether the loop is engaging, whether the reward cadence works, whether the difficulty curve is fair, are not answerable by AI. Procedural generation has also gotten more responsive in specific subgenres like roguelikes and survival sandboxes (systems that adapt enemy density, weather or environmental tone in response to how the player is actually playing), but those are bounded uses inside a few specific game types, not AI-as-designer.

Narrative and writing. Workable for ambient bark generation (Ubisoft’s Ghostwriter is the production-tested example), lore-consistency checking with general-purpose LLMs, and branching-dialogue prototyping with tools like Inworld AI and Sudowrite or general-purpose chat models. The core authorial work, the writing that gives a game its heart and soul, is a very different matter. A 2025 University College Cork stylometry study found measurable structural differences between human and AI prose: AI generates polished, fluent text, but its writing follows a narrow and uniform pattern. Surprise requires perspective, and perspective requires a life, which AI models do not have.

Localization. First-pass machine translation and AI-assisted workflows can now provide significant cost savings. Tools like DeepL, Lokalise AI, Smartling and Crowdin‘s AI-assisted features can produce first-draft translations across dozens of languages at a fraction of the cost of human-only workflows. Per the IGDA’s recent guidance, the catch is that native-speaker QA is still required if you want the game to play well in non-English markets, and studios skipping that step seem to be shipping into Mandarin, Japanese and Arabic with awkward UIs and unintentionally weird text. The cost savings get spent on cleanup either way, sometimes more than would have been spent on a proper human translation in the first place, so the adoption of these tools is still far from mature.

Marketing and community management. Compressed for content scaffolding, social copy variations, multi-language post drafting, event recaps, FAQ generation and screenshot variation, with general-purpose tools (ChatGPT, Claude, Gemini) and specialized ones like Jasper and Copy.ai doing some of the day-to-day work. Perhaps useful for small marketing teams. On the community side, there’s already an AI footprint. Tools like Brandwatch, Sprinklr and Sprout Social can provide AI-powered sentiment analysis across Reddit, Discord and other platforms, surfacing common themes, sentiment changes and emerging issues automatically. The community manager job itself, where actual judgment about how to respond is required, has not been remotely automated, but the listening and triage that supports them has, in part.

That’s a lot of areas with an AI footprint, admittedly much more than I expected, but with very uneven impact across functions.

“Unsurprisingly, AI seems to help most in the unglamorous parts of many authoring pipelines, but almost never end-to-end.”

Areas where the tech falls apart in production

End-to-end 3D asset generation is not yet ship-ready, regardless of how it’s currently pitched, and the integration cost remains non-negligible in any production pipeline. AI hero voice is not replacing your principal cast in the few years. The audible gap is still there, and Beth Park, the lead performance director on Black Myth: Wukong, made the point clearly at BAFTA Breakthrough 2024: AI removes the human, chaotic emotion from a performance, and that emotion is what players are looking for. AI is also not replacing your narrative leads, and it’s not taking over as your design director, or technical director. Full-game generation from a prompt is technically viable for browser-scale solo games (the Bitmagic platform is perhaps the most polished example, having raised $4 million in seed funding for prompt-to-3D-game generation) but not for the kind of game most readers of this article are building. AI-driven QA replacing your human testers wholesale will kill your design feedback loop, and the game will suffer from it.

Where the entry barrier is lowered

Solo developers are now shipping things they could not have shipped a year ago. Pieter Levels’ fly.pieter.com (a vibe-coded multiplayer flight sim) reportedly clears around $50,000 a month.

Nicolas Zullo built a multiplayer dogfighting game in twenty hours and 500 prompts that drew 45,000 players. Catvivors, an admittedly super-simple-looking game, is in Steam Early Access, made by an AI researcher with no prior game dev background. The floor at the bottom of the market has fallen by an entire small team’s worth of capability for one person. This is pretty remarkable.

That said, the floor dropping does not mean ambitious solo work has gotten easy. Chris Corry, a 30-year veteran of the games industry, has been documenting his experience building a 2D multiplayer RPG solo with Claude Code. The closing line of his most recent post tempers the enthusiasm well: “Even with the extraordinary capabilities of the Claude at my disposal, creating a game like this is a tremendous amount of work.” Yeah. The technology clears hurdles faster and opens some doors that were perhaps closed before (e.g.: you’re a solo-developer artist who can’t code or a programmer who can’t make art), but it does not seem to change the fundamental scope/effort math. At least not that dramatically.

At the AAA tier, the bar has barely moved. The Witcher 4 is being made roughly the way Witcher games have always been made, with AI in NPC crowds and prototyping and not much else. CD Projekt’s Michał Nowakowski was honest about this: “The benefits are real, they’re meaningful, but it’s not a situation where AI could sit down and make games.” Strauss Zelnick at Take-Two went further and called the idea “laughable.” They’re both right.

I think the middle band is where the action is. My sense is that AA studios in the 50-to-100-person range are the ones running legit, scalable, documented, in-production experiments. Most are probably not winning yet, and probably not losing yet either. This is also the most precarious tier in the industry right now, because they are making decisions about AI on budgets that don’t have much room for getting this wrong, unlike a one-person, indie solo project.

What’s changing about the work itself

The headline I keep reading everywhere is that AI is replacing developers. Yes, true, but that description lacks nuance. What is actually happening inside studios is, well, all over the place. Within many disciplines, the executional tasks are being compressed by AI, while the more player visible, high-impact, technically foundational, leadership and directorial tasks are not. That uneven compression seems to hit the early-career end of a discipline well before it touches the senior end, and it hits some kinds of work much harder than others. Let me elaborate on that.

The pure-execution standardized tasks are, as I understand, the ones most likely to lose market value. As an example: generating dozens of background prop variations from a base concept, a very standard task for an associate or mid-level environment artist working on an open-world game, seems to be significantly absorbed by AI now. And frankly, that’s only likely to accelerate. This is, on some level and to slightly different degrees, also true for 2D art (concept, storyboarding, UI, pixel art), rigging, animation, narrative, audio, QA, parts of software engineering, cinematics, localization, and more. And of those, it’s the junior jobs that are likely to be the most affected first.

Let that last sentence linger for a moment because there’s a lot to unpack there.

The traditional path into a craft used to start with a job focused on executing the basics: hands-on work, real responsibility from day one even if narrowly scoped, learning what good looks like by being elbow-deep in the actual making of games. Over years, more responsibility, more autonomy and more decisions are a natural consequence of experience and improved judgment. But that whole on-ramp is being undercut very fast. If the junior tier disappears, you do not get more directors and senior artists in five years, you get fewer, because the path that produced them just got severely narrowed.

This is an extremely serious labor consequence of this new technology and it’s going to apply to white collar labor at large, not just game development. MIT’s Andrew McAfee, co-leader of the Initiative on the Digital Economy, made the same point recently: “when we put too much automation in that too quickly, we lose that apprenticeship ladder.” He also raised an angle I had missed: cutting entry-level hiring sacrifices an organization’s most AI-fluent people. Roughly 76% of Gen Z use standalone AI tools, the highest of any generation. The studios pulling back on junior hires are removing the very people most willing to push the tools they’re betting on.

So if you are a junior on one of those potentially vanishing first-rung jobs, my actual position (which pushes back on the prevailing line of “just learn to use the tools”) is that you should double down on the foundational craft. Learn fine arts, learn rigging by hand, animation by keyframe, writing by writing. Pick up the AI tools as well, by all means, but if you give up the more formal training, you risk pigeonholing yourself as someone who can clean an AI-generated character, not someone who can author one. Studios will keep hiring people who can actually do the work, so don’t end up as the person who only cleans up after the tool.

“If you give up the foundational craft, you become someone who can clean a generated character, not someone who can build one. You cannot fix what you don’t understand.”

Production planning when velocity is no longer even

Run a simple character art kanban in your head: concept, modeling, texturing and UV, rigging, animation, VFX, audio and QA. How long the work takes in each of those columns has always been wildly different. Concept art might be a day, modeling can be three weeks, animation might be a day for a pedestrian and fifty days for Geralt in The Witcher, and audio is just as elastic, walking the line between an SFX walk cycle for an NPC and two staff-years’ worth of effort for Jin Sakai in Ghost of Tsushima.

The way pipelines normally accommodate this is through WIP limits and specialist staffing balanced for the actual flow: maybe one character artist, two modelers, two texturers, half a rigger, four animators, three VFX artists, one audio designer and one dedicated QA analyst. We balance, we iterate and the goal is to get characters flowing through the pipeline as smoothly as we can.

What AI does to that picture is shift the cycle time or column durations in different directions, unevenly, and not always in ways the WIP-limit calibration anticipated. With Midjourney or Firefly in the mix, concept can theoretically compress from days to minutes. With Tripo or Meshy in front of background-prop modeling, that work can be dramatically reduced for non-hero work and barely budges for hero asset work. Texturing compresses if you accept Substance Firefly outputs and is likely unchanged if your art direction wants hand-painted. Rigging is reduced for biped, stays the same for everything else. Animation can change partially with Cascadeur. VFX barely changes. Audio is reduced for placeholder and is unchanged for hero. QA compresses for technical bug discovery and stays unchanged for design bugs.

The variance between columns balloons. You may now be generating output in some sates of your pipeline faster than your team can review it, while your slower states (e.g.: rigging on stylized characters, hero animation) are exactly where they were. The team will tell you they are moving faster, but the build will tell you they are moving the same speed. Cycle time may look better in spots, but the throughput at the end of the funnel is the same. The bottlenecks just changed. The art director still needs three days to review concepts regardless of how fast the concepts came in.

I have not personally been through a cycle of redesigning a kanban around AI-warped cycle durations. I’d wager very few people have, because the tooling is too new and most studios using AI in production are still mid-experiment. What I would consider, with a 50-person team facing this for the first time, looks something like this:

• Budget bigger review buffers, not smaller. Batched approval breaks when generation accelerates

• Split hero work and standard work into separate streams with separate cadences, instead of assuming that one workflow can handle both

• Run review sessions more frequently and in shorter blocks, instead of milestone-based review

• In planning, call out explicitly which parts of the pipeline are using AI tooling and which are not, because the velocity assumptions across them may no longer be comparable

These are working hypotheses, mind you. I would expect some of them to be wrong in practice. If you have hands-on experience refining a kanban around AI tooling, I would love to hear what actually held up.

Questions instead of a framework

As you can see, I have not fully worked out a framework for evaluating and executing on AI adoption in a small studio. What I do have is a set of questions I am asking myself, and that I would be asking with any indie studio bringing this up.

What problem am I actually trying to solve? This is the first question I would ask (about AI and about pretty much anything), before evaluating any tool or vendor. Are you struggling to find good animators in your market? Is the cost of graphics engineering eating your runway? Is preproduction taking too long? Are bugs surfacing too late and breaking your milestones? Are you trying to position your studio strategically for the next five years? AI is a class of tools, not a strategy. Each of these problems leads to a different evaluation, a different tool, a different cost-benefit and possibly the conclusion that AI is not what fixes the problem in the first place. Abbas’ earlier article on where AI belongs and where it doesn’t is a good lens for this kind of thinking.

“AI is a class of tools, not a strategy.”

Which parts of my pipeline produce what the player actually feels? Games are supposed to make you feel something. A player paying for your game is paying for an experience, for surprise, delight, fear, the sense that someone really thought about this. As of now, AI is good at producing content in volume but bad at producing the qualities that make a player feel something. So the closer the AI gets to the content and features a player is actually interacting with (the protagonist’s voice, the hero animations, the lines that the player has to feel), the more risky that is. The further from those surfaces (placeholder dialogue you will replace, ambient barks, NPC item names, internal pre-vis), the more value AI adds without giving up what your game is for.

Where is my time actually going right now? Most of the gains seem to be concentrated in menial repetition. If your week is mostly that (placeholder generation, asset variation, localization first pass, code boilerplate, exploration QA), AI will likely help. If your week is mostly judgment calls and team management, AI will help less than the pitch decks suggest, and the time you save somewhere will probably reappear somewhere else.

Am I outsourcing decisions I should be making myself? AI tools seem to amplify whatever creative direction you give them. If you have a clear vision, they might help you execute it faster. If you don’t, they will generate the average of whatever you described, and average rarely makes a player very excited. Be careful that you’re not trying to make AI fill gaps that should be filled by you, the director, the writer, the designer.

What is my exposure if I sit this cycle out? I think denialism has potential costs, and the costs depend on what you are making. If your game’s value comes very clearly from craft and authorial care, sitting out probably costs you very little. If you are making something where production volume actually constrains the design (a long campaign, an open world, a localization-heavy live game), sitting out probably does cost you, because your competitors are likely reorganizing around tools you are choosing not to use.

If I want to do this, how do I do it well? Based on some of the public studio stumbles from last year, I offer a few humble suggestions. Run any work that AI was involved in through the same review gates as commissioned work, regardless of how fast it was generated. Be transparent internally about what is AI and what is not. Put in place a good metadata system and tag everything touched by AI. Pick specific areas the AI is allowed to touch (placeholder, ambient, internal tooling) and protect others that it isn’t (hero performance, authorial writing, signature visuals). The studios that paid for getting this wrong in public, like Larian, Pearl Abyss and Frontier, seem to have skipped one or more of those practices. The smaller you are, the more personally the cost hits when you misjudge it. And, of course, be transparent with players about your use of AI. Never forget that your boss, your real boss, is the player.

As you can see, these are not a framework. They’re just sensible questions. If they help, take them.

My take on all this

I remain deeply confused, torn, grateful, worried and excited all at once. I will most likely keep using these tools on my pet project, and be very cautious with my advice with the studios I consult with. I will likely also continue to be supremely upset at the labor consequences and at the executive speeches pretending all of this is a giant win for everyone in the industry, which is not the case.

Where I push back hardest is on the maximalist takes from either direction. The “AI changes everything, embrace or die” pitch is hard for me to take seriously and is mostly being made by people selling the tools (or courses), or people on the cap tables of companies that can benefit from labor and opex reductions, or executives who don’t even know how to load a scene in Unreal. The “AI sucks, it changes nothing, refuse it on principle” pitch is mostly being made by people who haven’t tried using one of these tools well, or who tried once with bad direction and got the average back. Neither is a good basis for a game studio’s strategy.

The things that we should all put some cycles into at this point are more along the lines of what problem we’re trying to solve that this technology could potentially help with, which tool to use, in which part of the pipeline, with what oversight, with what ethical responsibility to the people whose work helped train it. And above all: with genuine care, empathy and diligence to support and empower the people most affected by this maelstrom of changes. You know: the ones that gave Breath of the Wild, Subnautica, Portal, Outer Wilds, Factorio and others. Yeah, those humans.

I struggled with this one. A lot. Curious about your take on AI in games. Leave a comment.

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

By 1982, General Motors had run out of patience with its Fremont, California assembly plant and shut it down.

The decision was probably not difficult to make. For twenty years, the plant had been a slow-motion disaster. It had the worst quality record in GM’s entire company, absenteeism was so bad that on Mondays and Fridays there sometimes weren’t enough workers on the floor to start the production line, and GM supervisors would walk across the street to the bar to recruit people to fill in. Workers drank on the job, wildcat strikes erupted regularly, and when formal discipline was attempted, it triggered all sorts of grievances, which in turn triggered more strikes, which kept the plant in a state of near-continuous chaos.

And then there was the sabotage. Workers would slip Coke bottles inside door panels before they were sealed, so future owners would hear the rattling for as long as they owned the car. It was petty, deliberate, and, in retrospect, a completely legible message from a workforce that had concluded nothing else would be heard.

GM looked at the plant and saw a workforce problem. Twenty years of evidence, they figured, was twenty years of evidence.

Yet, they were wrong about what the evidence showed.

How it got that bad

The roots of what happened at Fremont go deeper than a single factory. They go to a specific set of beliefs about what workers are for.

GM in the postwar decades operated on what you might call the Henry Ford model of human beings: people are inputs. You divide the work into the smallest possible tasks, you assign those tasks to the cheapest available hands, and you extract the maximum output per unit of labor cost. Management thinks. Workers do. The line between those two functions is clear, deliberate, and crossing it in either direction is a problem.

The logic is coherent, in a very, very narrow sense. It optimizes for a specific kind of efficiency. What it doesn’t account for is what happens to people who are treated that way on an ongoing basis, over a certain period of time.

At Fremont, the answer was simply to stop caring. And later to actively push back. The absenteeism, the sabotage, the strikes, the Coke bottles in the door panels, none of that came from nowhere. It came from a workforce that had spent years being told, in every practical way, that their judgment didn’t matter, that their problems weren’t worth solving, that they were interchangeable parts in a system that saw them as costs to be minimized.

The United Auto Workers, the workers’ own union, later described the Fremont workforce as “the worst in the automobile industry in the United States.” What that description skips is the part where you ask: worst compared to what? The same workers, two years later, would be producing some of the highest-quality vehicles in North America. The workers were still the same people.

An unlikely deal

Toyota had its own reasons for wanting to be in the United States. Trade tensions between Japan and Washington were escalating through the early 1980s, Congress was openly discussing import restrictions, and Honda and Nissan had already established American manufacturing operations. Toyota needed a foothold, and they needed to learn how to operate inside American labor law, American union culture and the texture of American factory floors.

GM needed something else. They were losing the small car market to Japanese manufacturers and couldn’t figure out why. The oil crises of the 1970s had permanently shifted what American consumers wanted, and Detroit had no credible answer. Somewhere inside Toyota’s production system, GM sensed, was the thing they were missing.

The deal they struck in 1984 was, on paper, symmetrical: a 50/50 joint venture, Toyota managing the plant, GM getting a window into the Toyota Production System. In practice though, the symmetry was a polite fiction. GM handed Toyota the keys to their worst plant, staffed by the same workers who had made it their worst plant, and said: show us what you’ve got.

What Toyota did next is give us a lesson that transcends industry and time.

Three weeks that changed a factory

Toyota’s training manager at NUMMI was Isao Yoshino, and the challenge in front of him was genuine. He had to take a workforce that had spent years in open warfare with its employer and somehow create the conditions for an entirely different kind of work. He had no authority to replace the workforce. He had the same union contract GM had signed. He had the same building, the same equipment, largely the same management structure.

What he had, that GM didn’t, was a different set of beliefs about what people are capable of when they’re treated with dignity.

His solution was immersion. Before the plant opened, Toyota sent the frontline leaders, group leaders and team leaders, to the Takaoka facility in Japan in groups of around thirty. Three weeks each. They weren’t there to study manuals or sit through presentations about the Toyota Production System. They were there to work, side by side with Toyota employees, on an actual production line, inside an actual functioning plant.

The details of what they experienced have gravitas. At Takaoka, any worker could pull a cord to stop the entire production line the moment they spotted a defect. In the American automotive world, stopping the line was a firing offense. At Toyota, it was an expectation. The logic was simple and radical at the same time: the person closest to the problem is the best person to catch it, and catching it early is worth infinitely more than passing it downstream. So the worker who pulls the cord isn’t causing a problem. They’re doing their job at its highest level.

For the Fremont workers standing on that Japanese factory floor, watching this happen in real time, something changed dramatically and at a fundamental level. One American worker, interviewed years later, described the moment he saw someone stop the line over a single misaligned bolt. His entire framework for what a workplace could be was reorganized around that image.

When the Fremont workers came back from Japan, Mr. Yoshino described what he saw: “They just understand that Toyota management style is good. They’re not saying that GM style is bad, but Toyota style is more comfortable and makes us feel good.”

Makes us feel good. From a production efficiency standpoint, that might sound like a soft outcome. From a results standpoint, it produced one of the most dramatic quality turnarounds in automotive history, accomplished with the same people who had been quietly sabotaging the previous regime.

But Mr. Yoshino didn’t stop at the Japan trip. Back at Fremont, Toyota embedded experienced coordinators alongside the American workers, not as supervisors, but as partners. Problems that arose on the line were treated as information rather than failures. Workers were encouraged to suggest improvements. When they did, those suggestions were taken seriously. The relationship between management and labor, which at the old GM plant had been adversarial by design, was rebuilt from a different premise entirely: that the people doing the work are the people who understand it best, and that their knowledge is an asset, not a threat.

Within a year of opening, the plant’s quality metrics matched Toyota’s Takaoka facility. The same workforce that had been described by its own union as the worst in American automotive manufacturing. Mr. Yoshino’s explanation was characteristically plain: “We didn’t do anything else. We just offered the opportunity for them to learn, and they voluntarily decided to change themselves.”

That is not a small claim. It says that the workers at Fremont were never the problem. The system that treated them as the problem was the problem. Change the system, and the people change with it, not because they were fixed, but because they finally had somewhere to put the capability they had always had.

What game studios miss

GM had front row seats and saw all of it. Toyota kept almost nothing secret. They showed GM managers the production system, explained the philosophy, embedded Japanese coordinators on the floor for years. GM sent observers to NUMMI continuously. Some of them left describing it as transformational. A number went back to Detroit and tried to explain what they had seen.

GM began implementing lean principles more seriously, by most accounts, around the late 1990s, fifteen years after NUMMI opened. By then the market had moved, the debt had piled up, and the story ended in 2009 with the largest manufacturing bankruptcy in American history.

Access to the information was never the problem. GM looked at NUMMI and saw a set of techniques. But Toyota knew it was much more than that. It was a set of beliefs.

Copying a process is easy. You can write a rule that says workers must stop the line when they see a defect. What you cannot write is a rule that makes managers genuinely glad when they do, or that makes the person on the floor trust that raising a problem will be received as useful rather than punished as disruption. That trust is the foundation the whole thing runs on, not a feature of a production system.

The games industry, and especially its larger studios, have spent the last 10 to 15 years demonstrating a fairly comprehensive understanding of the GM position. Layoffs glacially announced through euphemistic corporate speak. Crunch normalized to the point that it stopped being discussed as a problem and became, somehow, “evidence of passion”. People hired for a specific project, discarded when the project ended or the direction changed, with all the ceremony of a cancelled vendor contract. The accumulated craft they carry, the instincts from shipping games, the understanding of what actually works, all walking out the door with them. Every single time.

This doesn’t usually come from malice. It comes in no small reason from an inability to see the people in front of you as the actual mechanism of production rather than a cost sitting between the idea and the output. The spreadsheet and the reduced operational expenses indicate that everything is fine, but the reality of game development at the actual studios that get decimated by the GM way is a peg different.

If you’re building or running a studio

You’re perhaps not running a hundred-person studio. Maybe you’re running something smaller, more distributed, built out of people who took a chance on an idea that isn’t a sure thing. Which means the dynamics are more immediate and, in some ways, more forgiving. You don’t have fifteen years of institutional habits to undo.

But the same logic applies at five people that applied at Fremont. Maybe more so, because at five people there’s nowhere to hide from culture. If someone on your team doesn’t feel like their judgment matters, you’ll feel that in every conversation you have together. If someone thinks raising a problem is more likely to damage the relationship than solve anything, they’ll stop raising problems, and you’ll only realize how important that was when you’re picking up the pieces.

You can’t afford not to care about this.

What Mr. Yoshino understood, and what Toyota built into everything about how NUMMI was run, is that the conditions for great work are not mysterious. People want to contribute to something meaningful. They want to grow. They want to be trusted with real responsibility and know that when they exercise judgment, that judgment is respected. They want to be treated with basic human dignity. These are not exotic or outlandish requirements. They are the minimum conditions for any human being to do their best work, in any field, in country, in any century.

Your team is not sitting there waiting for you to magically inspire them with rousing speeches and genre-defining game ideas. What they’re really waiting for is to be trusted.

The output, the quality of the game you’re making, your ability to attract people worth working with, the studio culture that either exists or doesn’t by the time you’re two years in, all of it flows from whether the people around you feel like this is a place that believes in them. A great milestone structure or a solid burn rate won’t save you from it. You can have a beautifully documented production plan and still ship a game with a team that burned down behind it.

Process serves people. Not the other way around.

I want to kindly encourage you to start from the same premise Mr. Yoshino did: that the people around you are capable of great things, and that your job is to create the conditions where those things can happen.

The rest, in my experience, tends to take care of itself. Not always, not immediately, but more reliably than you’d think.

If this was useful, you might also like:

Two articles in this series have already covered the legal and financial infrastructure of running a studio. This is the third: the people operations layer. How to pay your team legally, how to stay compliant across jurisdictions, what HR infrastructure a small studio actually needs, and which tools you should consider when you don’t have a dedicated HR manager. With all three pieces in hand, you should have enough working knowledge to run a studio as a functioning business, not just as a group of people making a game.

This guide is written from a US perspective. If you’re outside the US, the categories of things you need and the general principles are largely consistent across markets. The specific requirements, tax treatments, compliance obligations, and available tools are probably not. Please find local equivalents and verify them with someone who knows your jurisdiction.

The legal dimensions of employment (contractor agreements, misclassification risk, IP assignment, offer letters, employee handbooks) are covered in the legal primer. The staffing decision itself (full-time vs. contractors, when and why) is covered in the staffing strategy article. This article covers the operational mechanics: how you actually pay people, what compliance looks like in practice, and what services absorb the complexity when you’re doing this without an HR team.

Part 1: what kind of worker are you paying?

Before anything else, you need to be clear on the classification of every person you’re paying. This isn’t a bureaucratic nuance. It determines which rules apply, which tools you use, and what happens if you get it wrong.

US-based W-2 employees are the employees on your payroll. You withhold taxes, pay employer contributions (Social Security, Medicare), handle workers’ compensation, and in most states, follow a suite of employment laws covering everything from minimum wage to family leave to anti-discrimination. You’re responsible for benefits administration if you’re offering benefits.

US-based 1099 contractors are paid for services rendered. No withholding, no employer taxes, no workers’ comp in most cases. But the classification carries legal risk: if a contractor is functionally operating as an employee (set hours, supervised work, exclusive engagement, company equipment), the IRS and state agencies can reclassify them, with penalties applied retroactively. The legal primer covers misclassification risk in detail. The short version though is that you should not let a contractor relationship slide into something that looks like employment without cleaning up the classification first.

International workers are the most complicated category, and the one that tends to catch companies off guard. Paying someone in Germany, Brazil, or Canada as a US contractor might feel simple, but it isn’t. Many countries have strict rules about who constitutes an employee under local law, regardless of how you’ve classified the relationship. Getting this wrong can mean back taxes, fines, and in some jurisdictions, mandatory benefits or severance obligations. More on this in Part 3.

Once you’re clear on what kind of worker you’re dealing with, you know which track you’re on.

Part 2: payroll

What payroll actually is

“Payroll” refers to the process of compensating your employees on a regular schedule while correctly handling all associated tax obligations. If you’ve only ever been paid as a contractor or student, you may not have thought about what’s happening on the employer side of that transaction. It’s more than just transferring money.

When you run payroll for a W-2 employee, you’re doing several things at once: calculating their gross pay (salary or hourly wages), withholding the correct amount of federal and state income tax based on their W-4 elections, withholding their share of Social Security (6.2%) and Medicare (1.45%), paying your matching share of Social Security and Medicare as the employer, remitting all of those withheld and employer-paid taxes to the IRS and relevant state agencies on a defined schedule, and issuing pay stubs so employees can see the breakdown. At year end, you generate W-2 forms showing each employee’s total earnings and withholdings for the year.

That’s payroll. It’s a recurring administrative process with legal deadlines, not a one-time task. Do it wrong or late, and the penalties add up fast.

For 1099 contractors, it’s simpler: you pay the invoice amount in full, collect a W-9 from them at the start of the engagement, track payments throughout the year, and issue a 1099-NEC form to any contractor you paid $600 or more in a calendar year. No withholding, no employer taxes.

How often to run payroll

There’s no universal requirement for payroll frequency in the US, but most states have rules about minimum pay periods. The two most common schedules for small studios are:

Bi-weekly (every two weeks, 26 pay periods per year) is the most common for salaried teams. It’s predictable for both employer and employee, maps cleanly to most payroll software defaults, and tends to simplify overtime calculations if you have any hourly workers.

Semi-monthly (twice a month, 24 pay periods per year) is also common, typically the 1st and 15th or 15th and last day of the month. Slightly simpler for salary math since each period is exactly half a monthly salary, but marginally more complex if you have hourly workers.

Weekly payroll exists but carries more administrative overhead than most small studios need. Monthly payroll is permitted in some states but unusual for knowledge workers and can create cash flow pressure for employees.

Whatever you choose: pick it before your first hire, document it in your offer letters, and be consistent. Changing payroll frequency after the fact requires notice and creates unnecessary confusion.

How to run payroll

In practice, running payroll on a modern platform takes about twenty minutes once everything is set up (if everything goes well, at least). Here’s what the process looks like:

Setup (one-time, before first payroll run):

• Register for a Federal Employer Identification Number (EIN) at irs.gov if you don’t have one yet

• Register for state payroll taxes in every state where you have employees (your payroll platform (more on this below) will flag which states and walk you through registration)

• Collect a completed W-4 from each employee (federal withholding elections)

• Collect state equivalent withholding forms where required

• Set up direct deposit authorization for each employee

• Connect your business bank account to the platform

Each payroll run:

• Confirm hours if you have any hourly employees

• Review for any one-time items: bonuses, reimbursements, deductions

• Review the platform’s calculated amounts for each employee

• Approve and submit. The platform handles direct deposit, tax remittances, and filing

Quarterly and annually:

• Form 941 (Employer’s Quarterly Federal Tax Return) is filed every quarter, reporting wages paid and taxes withheld. Your payroll platform files this automatically.

• W-2s go to employees by January 31 and are filed with the IRS shortly after. Again, automated by your platform.

• 1099-NEC forms go to contractors you paid $600 or more by January 31. I suggest you set a reminder on your calendar for the first week of January to get this done on time.

Payroll tax deposit schedules

This is a part of payroll that most people don’t know about until they get a penalty notice. Federal payroll taxes (income tax withheld plus employer and employee FICA) have to be deposited to the IRS on a schedule, not just paid when you file your quarterly return.

For new employers, you start on a monthly deposit schedule: taxes accumulated in a given month are due by the 15th of the following month. As your payroll grows, you may move to a semi-weekly schedule, where deposits are due within days of each payroll run. The IRS determines your schedule based on your total payroll tax liability during a prior twelve-month lookback period: under $50,000 in that period keeps you monthly, over $50,000 moves you to semi-weekly.

Your payroll platform handles this automatically for the vast majority of small studios. It’s valuable to know that the rule exists, because if you’re ever running payroll manually or dealing with a platform failure, late deposits carry escalating penalties starting at 2% and reaching 15% for deposits more than ten days late.

All federal tax deposits must be made electronically, through EFTPS (the Electronic Federal Tax Payment System at eftps.gov), IRS Direct Pay, or your payroll platform’s built-in remittance.

Common payroll problems and how to avoid them

Not registering in new states before the first paycheck. If you hire a remote employee in a state where your studio has no previous presence, you may need to register as a foreign entity in that state and register for state payroll taxes before their first pay date. Most payroll platforms flag this during onboarding, but you don’t want this to catch you off guard. Sort it before day one, not after.

Mishandling contractor-to-employee transitions. When a long-term contractor converts to a full-time employee (which happens more than you’d think), there’s a temptation to just change the payment method and move on. Please don’t do that. The conversion requires proper onboarding documentation (W-4, I-9, offer letter, handbook acknowledgment), a change in how taxes are handled, and often a conversation about benefits enrollment. Run it like a proper new hire, because legally that’s what it is.

Missing payroll during a banking or platform issue. Employees have legal protections around pay timing. If your payroll platform goes down or a bank transfer fails, you’re still obligated to pay on time. Keep enough runway in your payroll account that you could fund one full payroll cycle manually if needed, and know how to initiate a manual wire if the platform is unavailable.

Not tracking reimbursements correctly. Expense reimbursements (software subscriptions, equipment, conference travel) are not taxable income if handled through an accountable plan (meaning the employee submits receipts and the company reimburses actual expenses). If you just add a flat amount to payroll without documentation, it becomes taxable wages. Set up a simple expense reimbursement process from day one and keep it separate from payroll.

Payroll platforms

For any US-based studio with W-2 employees, you need payroll software. Not a spreadsheet. Actual payroll software that handles withholding calculations, tax remittances, filings, and year-end documents.

Gusto is the default recommendation for small studios. It handles payroll in all 50 states, automates federal and state tax filings, manages contractor payments alongside W-2 employees, and has an interface that doesn’t require an HR background to navigate. It’s been around long enough that the product is stable and the support is generally responsive. Pricing starts at $49/month base plus $6 per employee per month on the Simple plan, but it only covers single-state payroll; the Plus plan at $80/month plus $12 per employee adds multi-state support and more HR tools. There’s also a contractor-only plan at $35/month plus $6 per contractor for studios that haven’t yet brought on full-time employees. Verify current pricing at gusto.com before committing.

Rippling positions itself as an all-in-one platform: HR, payroll, IT, and finance in a single system. It’s like the Jira of payrolls: immensely capable, feature-rich, and probably more than a small studio needs or wants to configure early on. The modular pricing means the cost climbs quickly as you enable more features, and there’s a learning curve that takes time. Worth considering once you’re past 20-25 people or if you have complex IT management needs. For most studios in early to mid-production, it’s perhaps more platform than the problem warrants. Pricing is not transparently listed on the website, so you have to call and get a quote.

Justworks occupies a middle ground between payroll software and PEO (more on PEOs in Part 3). Their Payroll plan runs $50/month base plus $8 per employee per month and covers core payroll, tax filings, and basic HR tools. Their PEO plans (discussed below) start at $79 per employee per month and add benefits access and compliance support. Justworks’ pricing is unusually transparent, and it’s a solid choice if you anticipate wanting PEO services as you scale.

QuickBooks Payroll is worth considering if you’re already using QuickBooks for accounting, since the integration reduces manual reconciliation. Less intuitive than Gusto for a first-time user but might be worth checking out.

If you’re a studio with only contractors and no W-2 employees yet, Gusto’s contractor-only plan or a simple tool like Deel for contractor management is sufficient. Don’t pay for a full payroll platform before you need it.

Part 3: PEOs and EORs

What they are and what they do

A Professional Employer Organization (PEO) and an Employer of Record (EOR) both outsource significant HR and compliance work, but they solve different problems. Understanding the difference is one of the things that consistently separates founders who set up their people operations correctly from those who figure it out late and expensively.

PEO: co-employment for US teams

What a PEO does is enter into a co-employment arrangement with your studio. Your company remains the legal employer of your team, but the PEO becomes a co-employer for HR and compliance purposes. In practice, this means the PEO handles payroll processing, tax filings, benefits administration, workers’ compensation, and HR compliance on your behalf, using their pooled scale to give you access to better benefits rates than you could negotiate as a ten-person company.

What changes the math is this: because your employees technically appear on the PEO’s payroll, they gain access to group health insurance rates, 401(k) plans, and other benefits that would be inaccessible or prohibitively expensive for a small studio buying independently. A PEO can often get you health insurance at rates significantly lower than what you’d pay on the open market for a small group. For a founder trying to offer solid benefits without a dedicated HR team, that access changes the financials quite a bit.

A PEO also provides a layer of HR expertise you don’t have in-house: employment law updates, compliance monitoring, HR documentation support, and in many cases access to an HR consultant when a situation requires it.

What a PEO costs. PEOs typically charge either a percentage of total payroll (usually 2-12%, with most small business arrangements landing between 4-8%) or a flat per-employee monthly fee. For the flat-fee model, expect $50-$150 per employee per month depending on the service tier and what’s included.

What a PEO is good for. A PEO makes most sense when you have a US-based team and want to offload compliance complexity, access better benefits, and not hire an HR manager. For a studio of five to twenty-five US employees, it’s often the right operational choice.

What a PEO requires and doesn’t do. A PEO requires that you already have a legal entity in the US. It doesn’t solve international hiring. If you need to bring someone on in another country, a PEO doesn’t give you a path to legal employment there. That’s what an EOR is for.

EOR: legal employment across borders

An Employer of Record is a third-party company that becomes the legal employer of your worker in their country of residence. You direct the work, set the compensation, and manage the day-to-day relationship. The EOR handles the legal entity, the employment contract, payroll in local currency, local taxes, statutory benefits, and compliance with local labor law.

For a distributed indie studio with team members in different countries, this is frequently the most practical solution available. The alternative is establishing your own legal entity in every country where you have employees, a process that typically takes two to four months, requires local legal and accounting support, and is prohibitively expensive and operationally not realistic for a small studio with one or two people in a given country. An EOR lets you hire someone in Poland, Colombia, or Canada within a few weeks, with full legal compliance, without incorporating there.

What an EOR costs. EOR services are meaningfully more expensive than domestic payroll software or PEOs. Expect roughly $400-$700 per employee per month depending on the provider and country. That’s not cheap. But compared to the cost and timeline of setting up and maintaining foreign entities, it’s usually the right trade-off for a small studio testing whether an international team structure works before committing to a permanent presence.

The core distinction

If your team is US-based and you want to offload compliance and access better benefits: PEO. If you need to hire internationally and don’t have a legal entity there: EOR. Some platforms now offer both, which simplifies things if you have a mixed domestic and international team.

How to evaluate a PEO

Not all PEOs are equivalent. A few things worth assessing are:

• Benefits quality and carrier access. Ask which health insurance carriers they work with and what plan options are available in your employees’ locations. A PEO operating primarily in major metros may have thin coverage in smaller markets.

• Compliance depth. Ask how they handle multi-state employment law changes and what their process is for notifying you of relevant legal updates. Employment law changes frequently; you want a partner that monitors it actively.

• HR support model. Understand whether HR consulting is included or an add-on, and whether you get a dedicated contact or a support queue.

• Contract terms. Some PEOs require annual commitments with early termination fees. Understand what offboarding looks like before you sign.

• Pricing transparency. Some PEOs are notably opaque about total cost. Justworks and Gusto are an exception in publishing clear pricing. For others, push for a fully loaded cost estimate that includes all fees.

PEO comparison

These are just some of the most common ones. There may be others.

• Gusto

• Rippling

• ADP TotalSource

• TriNet

• Justworks

*Gusto’s PEO offering operates through a partner network rather than as a direct PEO. This means Gusto itself doesn’t become the co-employer; instead, it connects you with a third-party PEO, which introduces an additional layer of relationship management and may limit the seamlessness you’d get from a platform like Justworks where payroll and PEO services are native. For studios primarily wanting payroll software with some HR tools, Gusto standalone is excellent. For full co-employment benefits, a dedicated PEO might be the cleaner option.

For small studios (five to fifteen people, primarily US-based), Justworks seems like the most straightforward PEO entry point: transparent pricing, reasonable onboarding, and service quality that holds up at small scale.

How to evaluate an EOR

Some evaluation criteria specifically for EORs:

• Entity model. Some EORs own their own legal entities in every country they operate in. Others use local partners. Owned entities generally mean stronger compliance guarantees, more consistent service quality, and clearer accountability when something goes wrong. Remote is the most prominent EOR emphasizing the owned-entity model.

• Country-specific compliance depth. Ask for a detailed breakdown of statutory employer costs and obligations in the specific country you’re hiring in, not just a general description of their service. Labor law complexity varies enormously by country.

• Onboarding timeline. Ranges from a few days in some markets to several weeks in others. If you have a hire waiting, this is relevant.

• Offboarding and termination. Termination rules vary dramatically by country. Some markets have significant mandatory notice periods, severance obligations, or works council requirements. Understand the process and cost before you hire, not when you need to end the relationship.

• Contractor management. Most EOR platforms also offer contractor management products at lower cost ($29-$49 per contractor per month), which is often a smart starting point before a relationship becomes a full employment engagement.

EOR comparison

These are just some of the most common ones. There are others.

• Remofirst

• Multiplier

• Oyster HR

• Remote

• Deel

All pricing should be verified directly with providers before committing. EOR rates vary by country and adjust regularly. The EOR market is also evolving quickly. Providers that were thin on features two years ago have built out significantly.

Part 4: benefits

What benefits are and what they typically include

“Benefits” is the umbrella term for everything you provide to employees beyond their base salary: health insurance, retirement savings, paid leave, financial protection in the event of illness or injury, and the various programs and allowances that support their overall wellbeing. In the US, benefits are a substantial part of total compensation and a meaningful indicator of what kind of employer you intend to be.

Before we get into the mechanics, let me clear about this: your goal should NOT be to do the absolute minimum that is legally required. If you’re reading this on the Game Studio Unlocked Substack, odds are that you’re an independent studio, asking people to trust you with their livelihoods, often at lower stability than a large studio would offer, already in a very unstable industry. The least that earns in return is a genuine attempt to cover their health, their financial security, and their ability to rest. The financial constraints on an indie studio are real. You should certainly work within them. But please approach benefits as a question of what your people actually need, not what you can get away with offering.

With that said, here’s what the landscape looks like.

Mandated benefits: what you’re required to provide

Before you get to choices, some things are already decided for you by law. Understanding the mandatory floor is important because it changes depending on how many employees you have.

Workers’ compensation is required in virtually every state from your first employee. Covered in Part 7.

Social Security and Medicare (FICA) contributions are employer obligations from day one. You match your employees’ contributions: 6.2% for Social Security on wages up to the annual wage base ($176,100 in 2026) and 1.45% for Medicare with no cap.

Unemployment insurance (FUTA/SUTA) is an employer-paid federal and state tax that funds unemployment benefits. The federal rate is 6% on the first $7,000 of each employee’s wages, reduced to 0.6% if you pay state unemployment taxes on time.

Family and Medical Leave Act (FMLA) applies once you have 50 or more employees within 75 miles of a worksite. It entitles eligible employees to up to 12 weeks of unpaid, job-protected leave per year for qualifying family and medical reasons, with continuation of group health benefits during the leave. Most early-stage studios won’t hit the 50-employee threshold for a while, but it’s good knowing the trigger.

COBRA (Consolidated Omnibus Budget Reconciliation Act) applies once you have 20 or more employees and offer group health insurance. It requires you to offer employees and their dependents the option to continue health coverage for up to 18-36 months after a qualifying event (termination, reduction in hours, divorce, and others). The employee pays the full premium plus up to 2% administrative fee. COBRA administration has specific notice requirements and deadlines; your PEO or benefits administrator typically handles this, but you need to understand the obligation.

State-mandated paid sick leave now applies in 20 states and Washington D.C., including California, New York, Colorado, Washington, Massachusetts, New Jersey, Connecticut, Oregon, and others. Requirements vary: accrual rates, annual usage caps, eligible reasons, and minimum employer size thresholds all differ by state. As of 2025, more states are adding or expanding these laws each year. If you hire in any of these states, your handbook policy needs to meet or exceed the state minimum. The GovDocs state leave tracker is a reliable reference.

State paid family and medical leave (PFML) programs now exist in California, New York, New Jersey, Washington, Massachusetts, Connecticut, Oregon, Colorado, Maryland, Delaware, and a growing number of other states. These are typically funded by employee (and sometimes employer) payroll contributions and provide partial wage replacement during qualifying leaves. If you have employees in these states, you’re likely already required to participate. Your payroll platform should flag and handle the contribution withholdings, but verify.

Short-term disability insurance (SDI) is required by law in California, Hawaii, New Jersey, New York, and Rhode Island, as well as Puerto Rico. In these states, employers must either participate in the state program or maintain a private plan meeting the state minimums.

Health insurance

Offering medical coverage to your team isn’t legally required for employers with fewer than 50 full-time employees under the ACA. You should offer it anyway, because your team members are human beings who need healthcare. It’s that simple. If you can’t afford this, you should reevaluate whether you’re in a position to have employees.

Plan types. Health insurance in the US comes in several structural forms, and the right choice for a distributed indie studio isn’t always obvious.

HMO (Health Maintenance Organization) plans use a defined network of providers. Employees must choose a primary care physician who coordinates their care and provides referrals to specialists. HMOs generally have lower premiums and out-of-pocket costs, but limited flexibility. The network restriction is a real problem for distributed teams: HMO networks are often regional, so an employee in Austin and an employee in Portland may not both have access to a good HMO option under the same plan. If your team is in one location, HMOs can be cost-effective. If your team is distributed across states, HMOs can get complicated fast.

PPO (Preferred Provider Organization) plans allow employees to see any provider, in-network or out, without referrals. Out-of-network care costs more, but it’s covered. PPOs carry higher premiums than HMOs but are the most flexible option for distributed teams. For a remote game studio with people across multiple states, a PPO is typically the practical choice.

POS (Point of Service) plans are a hybrid: employees have a primary care physician and need referrals for specialists (like an HMO), but can go out of network at higher cost (like a PPO). Generally less common than HMOs and PPOs, but worth comparing if a broker surfaces one that makes sense for your team’s profile.

HDHP (High Deductible Health Plan) plans carry lower premiums but require employees to meet a higher deductible before most coverage kicks in. The 2025 IRS minimum deductible for an HDHP is $1,650 for individual coverage. HDHPs pair with Health Savings Accounts (HSAs), which are employer and/or employee-funded accounts where contributions are made pre-tax, grow tax-free, and can be withdrawn tax-free for qualified medical expenses. Unused HSA funds roll over year to year and can be invested, making them a long-term financial planning tool as well as a healthcare tool. HDHPs work well for generally healthy employees who want lower monthly costs; they can create real financial stress for employees with families or ongoing medical needs. In 2025, employees can contribute up to $4,300 (individual) or $8,550 (family) to an HSA annually.

How to obtain coverage. If you’re using a PEO, group health insurance is typically one of the primary benefits. The PEO’s pooled workforce gives you access to large-group pricing even as a small company, which often means meaningfully better plans at lower cost than you’d find on the small-group market independently.

Outside of a PEO, your main options are:

Small group plans through carriers like Anthem, BCBS, UnitedHealthcare, or Kaiser. Purchased through a broker or the SHOP marketplace (healthcare.gov). Small group plans require minimum participation (typically 70% of eligible employees must enroll), which can be tricky for distributed teams where some employees are already covered through a spouse’s plan. A benefits broker can help you navigate this though as they’re typically compensated by the carrier, not by you.

Individual Coverage HRA (ICHRA) lets you give employees a defined monthly allowance to purchase their own coverage on the ACA marketplace. No minimum participation requirement, which makes it flexible for distributed teams. Each employee chooses a plan that works for their location and health situation. Platforms like Take Command Health and PeopleKeep specialize in ICHRA administration. ICHRA contributions are tax-deductible for the employer and tax-free for employees.

QSEHRA (Qualified Small Employer HRA) is a similar model for employers with fewer than 50 employees, with lower annual contribution limits ($6,350 for individual coverage, $12,800 for family in 2025). Worth comparing if your team is small and concentrated in one market.

Cost benchmarks. According to the KFF 2025 Employer Health Benefits Survey, the average annual employer-sponsored premium in 2025 is $9,325 for single coverage and $26,993 for family coverage. Employers cover roughly 84% of single premiums on average. For a small studio, plan conservatively on $600-$800 per employee per month for employer contribution to a reasonable single-coverage PPO or HMO in most markets, more in high-cost regions like California or New York. Premiums have been rising at 5-9% annually. Budget for that trajectory.

Dental and vision

Health plans don’t include dental or vision by default. I don’t know why. They’re typically purchased as separate ancillary coverages. They’re an employee expectation and they’re relatively affordable.

Group dental plans typically cost the employer $18-$35 per employee per month for individual coverage, with family coverage averaging around $60-$124 per month depending on the plan. Standard dental plans cover preventive care (cleanings, exams, x-rays) at or near 100%, basic restorative work (fillings) at around 80%, and major work (crowns, root canals) at 50%, subject to an annual maximum, typically $1,000-$2,000. Major carriers include Delta Dental, MetLife, Cigna, and Humana.

Vision plans are among the most cost-effective benefits you can offer. Group rates frequently fall below $10 per employee per month for individual coverage. Standard plans cover one annual eye exam, an allowance toward frames or contact lenses, and discounts on corrective procedures. Major carriers include VSP, EyeMed, and Davis Vision.

If budget is tight, dental and vision can be offered as voluntary benefits (employee-paid through payroll deduction at group rates), which still gives employees better pricing than they’d find on the individual market.

Retirement: 401(k)

A 401(k) plan allows employees to contribute pre-tax earnings toward retirement, reducing their taxable income in the year of contribution. Employer matching contributions are one of the most valued components of a compensation package for knowledge workers, and the presence or absence of a retirement plan is frequently a deciding factor in offers for experienced candidates.

For a small studio, the most accessible platforms are Guideline and Human Interest. Both are designed for small companies, integrate cleanly with Gusto and other major payroll providers, handle IRS filings and compliance reporting, and make setup manageable without a dedicated HR team. Annual administration costs are typically a few hundred dollars plus a small monthly per-employee fee.

Employer match. You’re not required to offer a match, but even a modest one (3-4% with immediate full vesting) is a meaningful retention tool. Budget it as a compensation line item, not a surprise at year end. Safe harbor 401(k) plans require a specific employer contribution formula but eliminate certain annual non-discrimination testing requirements. Ask a plan administrator about this if your founder team has significantly higher salaries than the rest of the team.

2025/2026 contribution limits. Employees can contribute up to $23,500 in 2025, with a $7,500 catch-up contribution for those 50 and older. These limits increase in 2026 to $24,000 and $8,000 for catch-up.

Disability insurance

Disability insurance replaces a portion of an employee’s income if they’re unable to work due to illness or injury unrelated to their job (workers’ comp covers on-the-job incidents). There are two types.

Short-term disability (STD) typically covers 60-70% of an employee’s salary for a period of three to six months after a brief elimination period (typically 7-14 days). It bridges the gap between a medical event and either recovery or qualification for long-term coverage. In California, Hawaii, New Jersey, New York, Rhode Island, and Puerto Rico, short-term disability coverage is state-mandated; employers in those states must either participate in the state program or maintain a qualifying private plan.

Long-term disability (LTD) kicks in after short-term benefits end, typically after 90-180 days of disability. LTD plans generally pay 60-70% of pre-disability salary and can run for two years, five years, ten years, or until retirement age depending on the policy. Group LTD is substantially more affordable through an employer than on the individual market.

Disability insurance is one of the least expensive and most underappreciated benefits you can offer. The Bureau of Labor Statistics data consistently shows that more than one in four workers will experience a disabling event before retirement. Group LTD employer costs for a basic plan typically run $10-$20 per employee per month. Offering it signals that you take your team’s financial security seriously.

Life insurance

Group term life insurance provides a death benefit to an employee’s beneficiaries, typically at a multiple of annual salary (1x-2x is standard for employer-paid coverage, with optional voluntary buy-up). It’s one of the cheapest benefits to offer as a group plan: $5-$15 per employee per month for basic $50,000-$100,000 coverage is typical for a small company. The IRS allows up to $50,000 of employer-provided group life insurance to be excluded from an employee’s taxable income; coverage above that threshold creates a taxable benefit.

Many, if not most small studios offer basic group life insurance as part of an ancillary benefits package alongside dental and vision, often bundled through the same carrier.

Pre-tax benefit accounts

These are employer-administered accounts that let employees set aside pre-tax dollars for specific expenses. They cost employers very little to offer (in many cases nothing beyond administration) and can meaningfully increase employees’ take-home value.

Health FSA (Flexible Spending Account) allows employees to set aside up to $3,300 (2025 limit) in pre-tax dollars for eligible medical, dental, and vision expenses. Unused balances are typically subject to a “use it or lose it” rule, though plans can allow up to $660 in rollover. FSAs are available to employees on any health plan type. You don’t need to offer an HDHP.

HSA (Health Savings Account) pairs exclusively with HDHP plans. Contributions are pre-tax, growth is tax-free, and withdrawals for qualified medical expenses are tax-free. Unlike FSAs, HSA balances roll over indefinitely and can be invested. Employers can make contributions to employees’ HSAs, which are also tax-deductible. If you offer an HDHP, offering an HSA alongside it is essentially required to make the plan competitive.

Dependent Care FSA (DCFSA) allows employees to set aside pre-tax dollars for childcare, preschool, after-school programs, and adult daycare for dependents. The 2025 limit is $5,000 per household, rising to $7,500 in 2026 following a legislative change. For employees with young children or elder care responsibilities, this can be worth several thousand dollars a year in tax savings. It costs the employer nothing to offer beyond payroll administration.

Commuter benefits allow employees to pay for qualified transit and parking costs with pre-tax dollars, up to $325 per month per category in 2025. For studio employees in cities with public transit, this is a no-cost benefit that meaningfully reduces their effective commuting costs. Administration is typically handled by your payroll platform or a dedicated commuter benefits provider.

Employee assistance programs (EAPs)

An EAP provides employees and their immediate family members with confidential access to counseling, mental health support, legal consultation, financial guidance, and referrals for substance use treatment. Services are free to employees. The employer pays for the program. Usage is confidential.

EAPs are inexpensive: typical employer costs run $10-$100 per employee per year depending on the scope of services. For a studio of ten people, you’re looking at $100-$1,000 annually. Given the sustained pressure of game development production, the creative risk inherent in the work, and the reality that many indie team members are relatively young and may be navigating significant personal and financial stress, an EAP is one of the highest-value low-cost benefits you can offer.

A few platforms you may want to evaluate are: Spring Health, Modern Health, Lyra Health, and Ulliance. Some PEOs include basic EAP access in their standard plan.

Time off

The US has no federal mandate for paid vacation. Seventeen states and Washington D.C. do have mandatory paid sick leave laws, covering California, New York, Colorado, Washington, Massachusetts, New Jersey, Connecticut, and others. If you have employees in any of these states, your policy must meet the state minimum regardless of what you choose to offer above it.

The operational question for a small studio is whether to implement a tracked PTO system or an unlimited PTO policy. Unlimited PTO sounds generous. In practice it often results in people taking less time than they need, because there’s no clear norm and production pressure creates implicit judgment around taking leave. A tracked system of 15-20 days per year with clear accrual rules can be healthier in practice. Whatever you choose, document it, apply it consistently, and actually encourage people to use it.

Parental leave. Federal law (FMLA) provides up to 12 weeks of unpaid parental leave for qualifying employees at qualifying employers. It sets a floor, not a standard. Several states (California, New York, New Jersey, Washington, Massachusetts, and others) have paid family leave programs that supplement FMLA with partial wage replacement. For studios in those states, you’re required to participate. Separate from the legal requirements, offering paid parental leave beyond the minimum is one of the clearest messages you can send about what kind of studio you’re building. Even a modest policy (4-8 weeks fully paid) matters significantly to employees with or planning families.

Other benefits worth knowing about

Relocation assistance. If you’re hiring someone who needs to relocate, reimbursing moving costs is a reasonable practice and a common expectation for senior hires. There’s no required amount; $2,000-$5,000 is a typical range for domestic relocations at independent studios. Relocation reimbursements are generally taxable as income to the employee unless structured carefully.

Equipment and home office stipends. For distributed teams, providing employees with the equipment they need to do their work (or a stipend to set up a home office) is increasingly standard. A laptop, monitor, and peripherals can run $1,500-$5,000 per person. Some studios offer a recurring monthly stipend ($50-$200) for internet and equipment maintenance.

Professional development. A modest annual budget for conferences, courses, or books ($500-$2,000 per employee) telegraphs investment in your team’s growth. GDC passes, Udemy courses, Unity certification programs, and game dev communities like Develop: Brighton or DevGAMM are all reasonable targets.

Wellness stipends. Some studios offer a monthly allowance ($50-$100) that employees can apply toward gym memberships, mental health apps, ergonomic equipment, or other wellness expenses. Relatively inexpensive and valued.

Benefits for international employees

If you have international employees through an EOR, the EOR handles statutory benefits in the employee’s country. Every country has different requirements: mandatory paid leave minimums, pension or social security contributions, parental leave mandates (typically far more generous than the US in most of Europe, Canada, and Australia), supplemental health coverage, and in some countries (Brazil, Mexico, and others) a statutory 13th-month pay obligation. These statutory employer costs are typically incorporated into the EOR fee as employer burden on top of base salary. Ask any EOR you’re evaluating for a specific cost breakdown per country before hiring, because total employer cost is often 20-40% above base salary once statutory obligations are included, and in some markets, significantly more.

Part 5: hiring domestically vs. internationally

Hiring in the US

For a US-based full-time hire, here’s an operational checklist before their first day:

Documentation:

• Signed offer letter and employment agreement (with IP assignment clause)

• I-9 verification (Employment Eligibility Verification): federally required, must be completed within three business days of start date. Can be done in person or remotely using E-Verify.

• W-4 (federal withholding elections)

• State withholding form where applicable

• Direct deposit authorization

• Employee handbook signed acknowledgment

• Benefits enrollment paperwork (if applicable, subject to waiting period)

State registration: If you’re hiring someone in a state where your studio has no previous presence, you may need to register as a foreign entity and register for state payroll taxes before their first paycheck. Your payroll platform flags this during onboarding but the registration itself requires action on your end. Sort it before their start date.

Workers’ compensation: Required in almost every state from the first employee. If you’re using a PEO, it’s typically bundled in. If you’re running standalone payroll, you need to purchase it separately (more on this in Part 7).

New hire reporting: Federal law requires employers to report all new hires to the state’s new hire registry within 20 days of hire. Most payroll platforms handle this automatically. Worth confirming yours does.

Hiring internationally

Through an EOR, the process is considerably simpler on your end, because the complexity is handled by the EOR. Your operational checklist should look more or less like this:

Before selecting an EOR:

• Confirm the EOR has genuine presence in the specific country (owned entity preferred, especially for higher-complexity labor markets like Germany, France, or Brazil)

• Request a full cost breakdown for that country including employer burden (statutory benefits, social security, pension contributions). The EOR fee sits on top of these costs.

• Ask about typical onboarding timeline for that country

• Understand offboarding mechanics and termination obligations before hiring

Once you’ve selected an EOR:

• Complete their onboarding workflow (company information, payment details, employee details)

• The EOR issues an employment contract compliant with local law

• You fund the EOR. They handle local payroll, tax remittance, and statutory benefits

• The employee is paid in local currency. You receive consolidated reporting

For international contractors: EOR platforms all offer dedicated contractor management products, typically at $29-$49 per contractor per month. These handle compliant contract generation, invoicing, and payment in local currency. If you’re not sure yet whether an international relationship will become long-term employment, start here.

The misclassification risk internationally. Many countries are stricter about employment classification than the US. Spain, Germany, France, and others have clear thresholds at which contractor relationships are reclassified as employment by law, with retroactive obligations. An EOR eliminates this risk for employment relationships, but a contractor arrangement does not.

Part 6: labor-related documents

The full document set is covered in the legal primer. The short version most relevant to the HR and payroll workflow:

For US full-time hires, before their start date:

• Employment agreement (with IP assignment, confidentiality, and at-will language where applicable)

• Offer letter

• I-9 (Employment Eligibility Verification): federal requirement

• W-4 (federal withholding)

• State tax withholding form (varies by state)

• Direct deposit authorization

• Employee handbook acknowledgment

For US contractors:

• Independent Contractor Agreement (with IP assignment clause)

• W-9 (used to issue 1099-NEC at year end for payments of $600 or more)

For international employees through an EOR:

• The EOR generates the employment contract. You provide the role description, compensation, start date, and any specific terms.

For international contractors:

• The contractor management platform generates a compliant agreement for the contractor’s jurisdiction.

Part 7: insurance

Workers’ compensation is required in almost every state once you have your first employee. It covers medical expenses and lost wages for work-related injuries. For a game studio (desk workers, low physical risk), premiums are relatively low: roughly $50-$150 per month for a small team, depending on payroll size and state. If you’re using a PEO, it’s bundled. If you’re not, get a policy in place before your first hire’s start date. Carriers like The Hartford, Travelers, and Next Insurance all serve small businesses; aggregators like Insureon and Simply Business let you compare quotes in one application.

Employment Practices Liability Insurance (EPLI) covers your company if an employee sues for wrongful termination, discrimination, harassment, or other employment-related claims. Average annual cost for a small studio (five to twenty employees) runs roughly $800-$3,000 per year. Get it once you have employees. Employment claims are more common than first-time founders expect, and defending one costs multiples of the annual premium even when the claim has no merit. EPLI is often available as an add-on to a general liability policy. Ask your carrier.

Directors and Officers (D&O) insurance protects the company’s leadership from personal liability related to management decisions. Less critical before your first funding round, but something to understand before an investor conversation.

Cyber liability insurance is worth considering earlier than most studios think if your game involves any online functionality, user data, or payment processing. Premiums for small companies run roughly $100-$300 per month.

Part 8: compliance

Compliance is less about memorizing every rule and more about having systems that catch the things that change. A few areas that catch small studios more often than others:

Multi-state employment law. US employment law isn’t uniform. State laws vary significantly on minimum wage, paid leave requirements, non-compete enforceability, and termination procedures. Hiring a remote employee in California, New York, or Washington introduces meaningfully more employee-protective requirements than most other states. If you’re hiring in a new state, understand the key differences before the hire. Your payroll platform or PEO will flag many of these, but not all.

FLSA classification. The Fair Labor Standards Act governs overtime eligibility. Non-exempt employees must receive overtime pay (1.5x) for hours over 40 per week. Many game development roles qualify for exempt status under the executive, administrative, or professional exemptions, but the classification requires meeting both a salary threshold and a duties test. As of late 2024, the current minimum salary threshold for exempt status is $684 per week ($35,568 annually), following a federal court decision vacating a 2024 DOL rule that would have raised it significantly. This area is in active legal flux, so verify the current threshold at dol.gov before classifying any employee as exempt. Misclassification exposes you to retroactive overtime liability.

New hire reporting. Federal law requires reporting all new hires to the relevant state registry within 20 days of hire. Most payroll platforms automate this. Worth confirming yours does.

Annual filings. W-2s and 1099-NECs are due to employees and contractors by January 31 and filed with the IRS shortly after. Your payroll platform handles these. For international workers through an EOR, the EOR handles local year-end obligations.

International compliance. If you have workers in other countries, stay current on changes in those jurisdictions. A good EOR provider should alert you to significant legal changes affecting your workers. If yours doesn’t, that’s a gap.

Part 9: managing this beast without a dedicated HR manager

At the stage most game studio founders reading this are at, you probably are the HR department. That’s the reality for a studio of five to ten people, and it’s fine. You don’t need a full-time HR manager at this scale. What you need is a clear operating model so the absence of dedicated HR doesn’t mean the absence of HR function.

The operating model

Systematize the basics. All recurring HR tasks (payroll runs, tax filings, new hire onboarding, benefits enrollment) should run through your payroll platform or PEO, not manually. If you’re doing any of these things by hand, that’s incredibly inefficient and probably the first thing to fix. The point of paying for Gusto or Justworks is that these tasks run without much human intervention.

Document policies once. An employee handbook at five to ten people doesn’t need to be long. It needs to cover: work hours and schedule expectations, PTO policy and process, communication norms, conduct and anti-harassment policy, and offboarding procedure. Free templates are available through SHRM, Workable, and similar HR resources. Get it done, get everyone to sign it, and update it when something changes.

Designate one owner. HR tasks fall between the gaps when nobody explicitly owns them. In a small studio that might be founder 1, founder 2, the studio director, the COO, or whoever is most operationally oriented. It doesn’t have to be the founder, but it should be explicit, and that person should have the authority to escalate when something exceeds their expertise.

Know when to escalate. Some situations require outside expertise: a performance situation that’s heading toward termination, a harassment complaint of any kind, an employment dispute with any legal dimension, or the first time you’re setting up a benefits package. A couple of hours with a labor attorney and/or an HR consultant at these moments is worth considerably more than an ongoing retainer would be. Most labor attorneys offer initial consultations at hourly rates. Many PEOs include HR consulting access in their plans.

When to bring in external HR support

A part-time or fractional HR consultant makes sense at specific inflection points:

• Before your first termination with any complexity or documentation gaps

• When scaling from five to fifteen people (compliance complexity tends to increase at this stage)

• Before establishing your first benefits package

• Before hiring internationally for the first time in a new country

• When any conduct or harassment situation requires formal documentation

Other useful HR tools

BambooHR is an HRIS (Human Resources Information System) for people data: employee records, onboarding workflows, performance reviews, and time-off tracking. Not a payroll tool, but a clean central record system. Potentially useful once you’re past about fifteen employees and managing multiple HR workflows simultaneously.

Lattice / 15Five are performance management platforms: structured check-ins, goal tracking, and review cycles. Not necessary in the earliest stages, but worth knowing about when you’re ready for more formal people management structure.

Quick reference: tool by scenario

The three playbooks in this series (legal, financial, HR and payroll) aren’t meant to make you an expert in any of these fields. They’re meant to give you enough working knowledge to ask the right questions, make informed decisions, and know when you need to bring in someone who does this for a living. The operational layer isn’t glamorous. But a studio that has it sorted can focus on making the game, while one that doesn’t will eventually find itself far too distracted by entirely avoidable operational problems.

If this was useful, you might also like:

You get good at something while you’re in school. You ship a student project, land a job at a game studio that happened to be hiring when you graduated, in whatever city, for whatever role they had open. And then you spend the next few years getting better at what you were already doing. Each of those early decisions carries more weight than it feels like it does in the moment. The studio type you join shapes what you learn. The genre you work in shapes what you get hired to do next. The skills you develop, or don’t, open some doors and close others, sometimes years before you realize it.

Game development makes this more complicated than other industries industries, because the field is genuinely fragmented: mobile, console, PC and VR are not just different platforms, they’re different industries with different cultures, different pipelines and different expectations of the people who work in them. Indie, AA and AAA are not rungs on a ladder, they’re legitimately different environments that develop people differently. Action RPGs, management sims, narrative adventures and live service shooters require very different skills, and moving between them is harder than it looks from the outside. A career built at a mid-tier studio making free-to-play mobile games is not the same career as one built at an indie team of eight making narrative adventures, even if the job titles match.

That’s a lot to process. It’s a lot of interlocking and synergistic variables influencing your career in ways that are hard to wrap your head around. So it’s not easy to be intentional when making micro-decisions that can have decades-worth of repercussions for your career.

Hence this article. I personally haven’t seen a comprehensive map that helps developers hold all of these variables in front of them at once and ask: does this help me build the career I want? Is this taking me somewhere deliberately, or am I letting the industry decide for me?

So what I’m going to propose here is an adaptation of an old Japanese concept that I think aligns well with making a concerted effort to find fulfillment.

The Ikigai adaptation

Ikigai is a Japanese concept usually translated as “a reason for being.” The model most people have encountered, which is actually a Western adaptation of the original concept, is represented as four overlapping circles: what you love, what you’re good at, what you can be paid for, and what the world needs. The center, where all four overlap, is ikigai. A life with purpose, sustainability and meaning.

The spirit of the model, holding multiple axes in tension simultaneously rather than optimizing one and hoping the others sort themselves out, is exactly what’s missing from how most developers think about their careers. But the circles themselves need adapting for game development, where the variables are specific and the traps are specific.

So I’m keeping the four-circle structure and rewriting what the circles are.

Circle one: what you’re drawn to make

There’s a corner of the internet dedicated entirely to the idea that you should follow your passion, that if you love what you do you’ll never work a day in your life, and so on. The game industry runs the same line, where passion is treated almost as a substitute for other things: a reason to accept low pay, long hours and poor working conditions, because “ you’re lucky to be doing something you love”. I find that framing somewhere between naive and actively harmful.

Cal Newport makes a more useful argument in So Good They Can’t Ignore You (2012). His case is that passion is not the starting point of a good career. It’s frequently the result of one. People who become deeply engaged in their work tend to have developed genuine skill and autonomy in it first. The passion followed the mastery, not the other way around. Which means “follow your passion” is not only vague advice, it may have the causality exactly backwards.

What I’d replace it with is something closer to what Mihály Csíkszentmihályi described in his work on flow: the kind of work you find genuinely absorbing, not just interesting. Not games in general. The particular type of problem that makes time move differently when you’re working on it. The kind of work you’re drawn back to even when it’s hard, that you find yourself thinking about outside of work hours, that doesn’t feel like it requires the same kind of willpower to start as other tasks do.

For some developers that’s the physical feel of an interaction: the weight of a jump, the timing of a parry, the way a camera can be tuned until movement feels alive. For others it’s systems thinking: building economic models, tuning balancing variables until emergent player behavior starts doing interesting things. For others still it’s narrative craft, world-building, the architecture of a space that guides a player without telling them where to go. These are very different types of engagement. Developers who confuse “I love games” with clarity about what they’re drawn to make risk ending up being frustrated that the job doesn’t match what they imagined.

And there’s a sub-dimension here that trips people up. What you’re drawn to make has two components that don’t always point in the same direction: the craft you love practicing and the creative context you want to bring that craft to. The craft is the specific type of work, the discipline, the daily problem-solving. The context is the genre, the tone, the kind of experience you want to help create for players.

A character artist who loves the craft of sculpting but whose real passion is dark, atmospheric horror games is a different person from one who’s equally skilled at sculpting and wants to spend their career on stylized platformers with bright, expressive aesthetics. Their skills look identical on paper, but if you put either of them in the wrong studio, you'll know within a year.

Taking stock of both dimensions, the craft and the context, gives you a clearer picture of what you’re actually chasing than simply “I love games”.

Circle two: what you’re genuinely building toward

Early in a career, this circle is partly unknown. You know what you’re good at relative to your student cohort, relative to other junior developers in your team. What you don’t yet know is what you’re good at relative to the industry, and that gap takes a few years to close.

So this circle is less about current competence and more about direction. A useful question to ask yourself isn’t just “what am I good at right now?” but “what am I developing into being good at, and is that the thing I actually want to be excellent at?” You can be developing the wrong thing for years before you notice.

Imagine this: someone gets hired for a skill they have, turns out to be good at it, gets assigned more of it, and a few years later has become a specialist in something they find… unrewarding. Nobody made a bad decision at any single point. The studio needed what the developer could provide and the developer kept delivering. That type of work just wasn’t what they wanted to spend a career on though. This happens across every discipline, in every kind of studio. It’s surreptitious and ordinary and it’s one of the main ways people end up somewhere they didn’t quite intend to be.

The generalist/specialist question

The generalist versus specialist question lives in this circle, and being intentional about this is important.

Spending your first three years at a small indie studio, wearing multiple hats, working across disciplines because the team is too small for anyone to stay in their lane, will develop you very differently than spending those years at a large AAA studio going deep on one narrow discipline. The first path gives you breadth, contextual awareness and a working understanding of how all the pieces fit together. The second gives you craft depth, real expertise in a specific area of the stack, and some additional credibility from having done one thing really, really well.

Neither path is wrong. But they do lead to different places, and they can open and close different doors.

A relevant model is what Tim Brown at IDEO called the T-shaped person: someone with broad general knowledge across disciplines and deep expertise in one area. The vertical bar is where you can contribute, where you’ve earned legit craft credibility. The horizontal bar is what makes you effective as a collaborator, a communicator across disciplines, someone who can understand the work of people around them even when it isn’t their specialty. Brown argued that people who are “so inquisitive about the world that they’re willing to try to do what you do” are what builds genuinely effective creative teams.

The T-shape is a useful target. But it’s a shape you end up with through deliberate choices, not one that appears on its own. If you spend your first five years going wide without ever committing to depth, you can end up as a generalist by accident rather than by design. That feels different and serves you differently in a hiring market.

Career capital and future value

Newport’s career capital concept is also relevant here. By developing rare and valuable skills, you gain leverage that allows you to shape your career in meaningful ways. Newport also argues that skills which are neither rare nor valuable accumulate into a kind of career debt rather than career capital.

It’s not a bad idea to think about this in concrete terms. Every job you take makes some things easier and some things harder for the next job. Sometimes those are skills. Sometimes they’re relationships, reputation, or the type of work you get associated with. If you spend five years getting excellent at a niche proprietary engine at a studio that then closes, you’ve built some things that transfer and some things that don’t. If you spend your early years getting typecast as “the live service person” or “the mobile person” in a part of the industry you don’t actually want to stay in, the lateral move you want to make in year six is going to cost time and often a step back in seniority that colleagues who started in a different context don’t have to pay.

Thinking about your skills as something that accumulates or depletes, rather than just as the requirements for your current job, is a more useful frame.

Mentorship

Access to experienced developers who can give you honest, specific feedback can accelerate your development in ways that are hard to replicate otherwise. Not because they tell you things you couldn’t theoretically figure out, but because they compress the timeline. A year of watching someone senior navigate a difficult decision, seeing how they think, understanding what they optimize for, is worth considerably more than several years of making the same decisions in isolation. And that kind of access is not equally distributed.

At a large studio, mentorship tends to be structural: you have a lead, you have a manager, there are processes for feedback and development. It can sometimes be less personal but more consistent. At a small indie studio, formal mentorship is rarer, but you may work directly alongside people who are much more senior and experienced than you’d encounter as a junior at a large studio, because the team is flat and everyone is doing everything. So you might find yourself next to the CEO in a pitch meeting with a publisher as a mid-level game designer. That’s a unique experience.

Both environments have valuable things to offer. What matters is whether you’re actively extracting the value available to you in whichever one you’re in, and in many cases that means being proactive about seeking it out rather than waiting for it to be structured around you.

Circle three: what the industry will actually pay for

The implicit assumption early in a career is that good work gets noticed and rewarded, that the market is roughly meritocratic, and that if you’re skilled enough the opportunities will find you. Sometimes that's true. More often than not though, what the market does is reward the right skills in the right context, specifically, and if you're in the wrong one context, then talent alone just isn’t enough.

This circle has at least three components that I want to highlight separately.

Genre and platform economics. Some types of games, and the skills associated with making them, have durable commercial demand. Others are cyclical, trend-dependent, or concentrated in a small number of studios that can absorb only so many specialists. A developer who is deeply skilled in a genre that is contracting, or that is dominated by a handful of large studios that rarely hire externally, is likely to struggle to find work regardless of how good they are. That’s not a statement about the value of the work. It’s just the market reality. Which means it's worth asking, before you go deep on a specialization, whether the market for it is growing, stable or contracting. Not to chase trends, but to know what you're getting into.

Studio health. Early in a career, developers tend to evaluate jobs primarily on the game and the role. The financial health and trajectory of the studio is an afterthought, if it’s a thought at all. This is understandable, because you often don’t have easy access to that information and you don’t yet have the context to read what you’re seeing. But a studio that’s burning through its runway, that has been through multiple rounds of layoffs, that has a public history of employee scandals, or that is dependent on a single publishing deal that hasn’t been confirmed, is a different career environment from one that’s stable and growing. Spending two years at a studio that then closes sets you back in ways that go beyond just finding a new job. You lose the reference, the project disappears from your portfolio or ships in a compromised state, and the skills you built are tied to a game nobody can see. So try to do your homework. Check Glassdoor (or equivalent), look at the studio's release history, ask in the interview how the project is funded. You won't always get straight answers, but the more clarity you can get, the better.

Future value of your skillset. Every skill has a shelf life and a market. The question isn't just whether you're good at something, but whether the specific combination of things you're getting good at is one the industry will pay for in five years, not just today. A developer who spent the 2000s getting excellent at something like ActionScript and Flash game development had genuinely rare skills, until Adobe discontinued Flash Player in 2020 and those skills became somewhat worthless overnight. The underlying programming instincts transferred. The specific expertise didn't. So thinking about your skillset as a portfolio, and asking periodically whether each job is building or depleting it, tends to make career transitions considerably less painful than finding out the hard way.

None of this is an argument against taking the job in front of you. Early in a career, you take what’s available. That’s not a compromise. It’s how most careers actually start. The point is to take it with some awareness of what it’s building toward, and whether the direction is one you can lean into or correct from.

Circle four: what you want to have contributed

This is the circle without a clean equivalent in the original ikigai model. “What the world needs” doesn’t quite fit game development, because it either sounds too abstract or it collapses into circle three.

What I mean by this one is something more personal and with a longer view. At some point in anyone’s career, the question stops being only “what am I good at and can I get paid for it?” and starts to include “what do I actually want to leave behind?”

Partly this is about reputation: what do other developers, studios, collaborators associate with your name? Not in a self-promotional sense, but in the simpler sense of what you’re known for, what kind of work finds you rather than you having to chase it. Reputation is built slowly through an accumulation of choices, and it’s worth having some intention about it, even early, even when you’re not yet sure exactly what you want it to be.

But there’s something smaller and harder to quantify underneath that. Games are experiences that matter to people. Players spend hundreds of hours in worlds that developers built. Some of those worlds leave a mark: many games helped people go through a hard period, others made them feel understood, and others people still think about a decade later. That’s not something you can entirely control, but it’s something you can at least orient toward.

Developers who never ask themselves what they want to have contributed risk ending up in a particular place in the middle of their careers, which is: technically excellent, reasonably well-compensated, and genuinely unsure about why any of it matters. That’s not exactly a crisis, but it means one of the circles might have been neglected for a long time.

This is also the circle that is most resistant to external disruption. Markets shift, technologies ride the hype and die out, studios close, genres that seemed permanent turn out to be cycles. The question of what you want to have contributed doesn’t really care about any of that. This is yours.

The spaces between the circles

The spaces between the circles are where most developers actually live, at least for stretches of their career. Full overlap across all four is rare, and probably temporary even when you have it. What's more useful than chasing the center is understanding what the partial overlaps actually feel like, because they're specific situations with well-defined costs, and knowing which one you're in is the first step to doing something about it.

Passion without a path is where you’re engaged by your craft and actively developing it, but you haven’t connected it to a sustainable market yet. The portfolio full of carefully made, almost-zero-revenue games on itch.io could be an example of this scenario. There’s nothing wrong with this per se. For some developers it’s a deliberate choice: they have income from elsewhere, or they’re early enough in their career that market viability is secondary while they build their craft. For others, it’s a situation they ended up in without quite planning to, and the financial reality catches up. Understanding that is important.

Skills without a market is more common than people realize, and my sense it that it tends to go unnoticed precisely because the skills are there and improving. Everything feels like it's going in the right direction. Think of developers who built expertise in blockchain integration and smart contract development during the play-to-earn wave of 2021 and 2022 were working on genuinely in-demand skills, at studios that were hiring aggressively and paying well. When that whole Web2 market collapsed, most of those studios shut down or pivoted entirely, and the specific expertise didn't travel well back into mainstream game development. Getting better doesn't guarantee the market will still be there when you arrive.

Money without meaning tends to be fine in year two and genuinely difficult by year seven. Technically capable, reasonably well-paid, and starting to increasingly dread Monday mornings. Observationally, I’d argue that this is far from unusual. The financial stability was never the wrong objective. What’s missing is a connection between the daily work and either of the other circles, and the problem only gets worse the longer it’s ignored.

Purpose without foundation is another common early-career situation. You have a clear sense of what you want to contribute, a strong orientation toward the creative or technical context you want to be part of, but you haven’t built the skills or found the market position to get there yet. In some sense this is just being early in a career: there’s a clear gap but it’s closeable. What might keep it from closing is when someone isn’t deliberate enough about doing exactly that, just waiting for the right opportunity rather than building toward it.

Tradeoffs aplenty

The classic ikigai diagram puts the prize in the center. But the zones outside the center aren’t failures at all. They’re just tradeoffs, and some of them are legitimate, even good, depending on what you actually need from your career.

A developer who is deeply engaged by their craft and building great skills in an area they care about, but who hasn’t found a financially sustainable path yet, isn’t in a crisis. They may be in an early-stage career that may need course correction, or they may have made a deliberate choice: economic stability matters less to them than creative alignment, and they’ve structured their life accordingly. That’s all perfectly fine.

A developer who is well-paid, in a stable part of the industry, building skills that the market values, but who isn’t particularly passionate about the work, isn’t doing anything wrong either. Maybe meaning comes from outside work, from family or creative projects or community. Maybe they went through a period of financial hardship that makes stability feel valuable in a way that’s hard to explain to someone who hasn’t. Their career is not broken because one circle is lighter than the others.

Self-determination theory, developed by Ryan and Deci, identifies three basic psychological needs behind motivated, fulfilling work: autonomy, competence and relatedness. A career can satisfy some of those more fully than others and still be a good one. This framework is a tool for reflection. It’s useful for making tradeoffs visible, so they can be chosen rather than stumbled into.

The early years matter more than they seem

The choices you make in the first three to five years of a game development career shape what choices you have available later in a more dramatic way than they feel in the moment. Early choices determine what you’re good at. What you’re good at determines what you get hired to do. What you get hired to do determines what you’re good at next. So the career you end up with is the accumulated result of dozens of decisions that each felt small at the time.

This is especially true of the generalist/specialist question, of which genre and platform you build your skills in, and of which studios you associate your early work with. Moving between contexts later, from mobile to PC, from free-to-play to premium, from live service to single-player, is definitely possible but it’s not free. It costs time, often money in the form of a step back in seniority or compensation, and sometimes a fair amount of self-awareness and patience.

None of which means the first job has to be perfect. It rarely is, actually. The question isn’t whether you landed in an ideal situation straight out of school, but whether you have any sense of where you’re trying to go, and whether the decisions you’re making are building toward that or away from it.

The difference between “I took this job because it was available, and it’s not perfectly aligned with what I want, but I know what I want and I’m going to be intentional about the next move” and “I took this job and I haven’t really thought about the next move yet” can prove remarkably important a few years later.

Putting it to work

If you’re just starting out

Before you’ve accumulated much career history, the most useful thing this framework gives you is a set of questions to hold as you evaluate early opportunities.

When you’re looking at your first or second job, ask yourself: does this studio work in the creative territory I’m drawn to? Even if the specific role isn’t my ideal entry point, will I be surrounded by the kind of work I want to get better at? Is this a studio with enough stability that I’ll have a year or two to actually develop, or is there a real chance this disappears before I’ve built anything? And is there someone here I can learn from, or will I be developing in relative isolation?

None of these questions have clean answers when you’re just starting, and you rarely have the information you’d need to answer them fully. But asking them, even imperfectly, is a different posture than taking the first offer and figuring it out later.

The annual check-in

Once a year, maybe when a contract is ending, or a job is starting to feel wrong, or you’re at a crossroads, take the time to go through the four circles candidly. Not once to fill them in and be done, but as a recurring review.

Below is a simple rubric to structure that review. Score yourself 1 to 5 on each question. A 1 means this is a genuine gap or problem right now. A 5 means you’re in a genuinely strong position on this dimension.

Circle one: what you’re drawn to make

• Do I know specifically what kind of work I find engaging, as distinct from “games in general”? (1 = not really / 5 = very clearly)

• Am I currently doing work that connects to that, or building toward it? (1 = not at all / 5 = directly)

• Does my current role connect to the creative context I want to be part of? (1 = not at all / 5 = yes, this is exactly the territory)

Circle two: what you’re genuinely building toward

• Do I have a clear sense of the skills I’m trying to develop and why? (1 = I’m just doing my job / 5 = I have a specific development direction)

• Is my current role actually building toward that, or am I getting good at something else? (1 = something else / 5 = directly)

• Am I getting the breadth and depth I need for where I want to be in five years? (1 = neither / 5 = both, deliberately)

• Do I have access to meaningful mentorship or senior guidance? (1 = none / 5 = strong and active)

Circle three: what the industry will actually pay for

• Is the genre, platform and studio type I’m in economically healthy? (1 = contracting / 5 = growing)

• Is the studio I’m at financially stable? (1 = significant uncertainty / 5 = stable and growing)

• Are the skills I’m developing ones the industry will value in five years, not just today? (1 = specialized and narrow / 5 = durable and transferable)

Circle four: what you want to have contributed

• Do I have a sense of what I want to be known for, even a rough one? (1 = not really / 5 = quite clearly)

• Does my current work connect to that? (1 = not at all / 5 = directly)

• Am I working on the kind of experiences I’d be glad to have helped create? (1 = not particularly / 5 = yes)

Any score of 1 or 2 in an area you care about merits taking a moment and thinking through. Not as a crisis, but as a genuine question: is this a deliberate tradeoff I’ve made, or is it a gap I’ve let develop without choosing it?

A note for mentors, managers and leads

This framework isn’t only for developers figuring out their own careers. It’s a useful lens for anyone who is developing other people.

If you’re a lead, a manager, or in any position where you have influence over someone’s development, running through these questions with your direct reports in a 1:1 can open conversations that wouldn’t happen otherwise. Where are they drawn creatively? What skills are they trying to build, and are the assignments you’re giving them actually building those skills or just meeting the team’s short-term needs? Do they have a sense of what they want their career to stand for?

The developers who got deliberate early usually had someone in their corner who helped them get that way. It’s one of the most useful things a senior person can do for someone junior: help them see the whole picture before the early decisions have already been made.

You spent two, maybe three years of your life developing a video game. You put in every ounce of your energy, passion, intelligence, tenacity, collaborative skills, patience, and every other conceivable competency required to make and ship your opera prima. You and the rest of the team can speak in great detail to the innovations in the combat system, the clever animation blending solution you created in-house, the emotional resonance elicited by the exquisite work done by the narrative and audio designers. Yet, when it comes to valuing all this, when it’s finally time to put a price tag on all this creative effort, you go: “I don’t know, I think, maybe… twenty bucks?”.

It’s not commensurate with the work that the studio put into the game and it’s not exactly optimal. When it comes to pricing, taking a methodical, data-informed approach is simply a superior choice than going with a light touch.

This article is for studios that are midway through or approaching the end of production. You should be thinking about this now, not a month before launch. Pricing decisions have downstream consequences for your Early Access strategy, your discount calendar, your publisher pitch, and how you position the game publicly. Getting it right requires a process, and that process takes time.

I designed this as a five-step framework, built from the data that actually exists on this topic, not intuition and not what worked for someone else’s game in a different genre in a different market cycle. The framework comes with an accompanying spreadsheet, which you can find here. I encourage you to get a copy and work through it alongside each step.

Step 1: build your comp set

The most common pricing research mistake isn’t looking at comparable games, but looking at the wrong comparable games. Or looking at the right ones through the wrong lens.

Your comp set should include games released in the last three to four years with similar genre, content length, visual polish, and target audience. Not just the games you know and love, not just the breakout hit your game gets compared to in Discord conversations. You want the full picture: some well-known titles, some games that did okay, and some that may have underperformed. The failures are as informative as the successes, sometimes more so.

Here’s how to find them: if your game already has a Steam page, go there, find the “More Like This” section at the bottom, click on “See All”. That’s your fastest starting point. Take note of the relevant games that shows up.

If you don’t have a Steam page yet, go to SteamDB, search by your primary genre tags and filter to games released in the last three years. VG Insights is worth having open too.

Between Steam’s More Like This and SteamDB’s same tag results, what you’re looking for here is at least ten to twelve games with enough review count to be meaningful (I’d suggest no fewer than a couple of hundred), not just the most obvious names.

For each game, record the launch price, current price, your honest assessment of quality relative to yours, community reception (specifically: are players complaining about the price in reviews?) and approximate content length. That last one is important. A $20 roguelike with infinite replayability is typically a different pricing message than a $20 narrative game that runs six hours and doesn’t change on a second playthrough.

To make this concrete, let’s run an example. Say you're building a deckbuilding roguelike. Your obvious comp is Slay the Spire ($24.99 launch, overwhelmingly positive, genre-defining). You'd also look at Balatro ($14.99, 2024 breakout), Monster Train ($24.99, strong critical reception) and Inscryption ($19.99, smaller but highly distinctive), and Insider Trading ($12.89, intentionally cheaper, “Mostly Positive” as of the writing of this article, reasonably well-received). What that set tells you immediately is that the genre has a fairly wide range ($12.89–$24.99), that the higher-priced titles are either genre-defining or backed by real polish and reputation, and that pricing toward the lower end correlates with volume-first strategies and replayability-driven design (although in this specific example with roguelikes, all games are made with high-replayability in mind). Your position in that range should reflect where your game actually sits relative to that field, not where you wish it sat.

What you’re building is a reference range, not a formula. The comp set tells you what the market has been willing to pay for games like yours, who pushed the upper bound of that range and whether it worked for them, and where the price complaints started appearing in reviews.

Open the companion spreadsheet and fill in Sheet 1 (Comp Analysis) before moving to Step 2. The summary outputs at the bottom calculate your comp range automatically. That range is what you take into the next step.

Step 2: score the four pricing variables

OK, now you have a reference range from your comp set. To find your number within that range, you need to work through four variables that shape where your game sits.

Genre norms.

Every genre has an implicit price range in the minds of the players who buy it. Roguelikes tend to cluster between $14.99 and $24.99: Slay the Spire, Dead Cells, Risk of Rain 2 and Monster Train all launched at $24.99; Balatro and Enter the Gungeon at $14.99. Survival games can run a little higher than that. Valheim launched at $19.99, but Sons of the Forest, Enshrouded and Voidtrain all launched at $29.99, and Rust sits at $39.99. Narrative games and straightforward walking simulators (What Remains of Edith Finch, Gone Home) tend to price a touch lower ($10–$19.99) because their audiences are more sensitive to the ratio of price to content length, although this is also dependent on “production values”. Deep strategy and grand strategy (Dwarf Fortress, Manor Lords) can push toward $30–$40 because the audience expects and accepts extended playtimes and higher complexity. If your game crosses genre lines, you need to think about which genre's price norms will dominate in the player's mind when they see your store page.

Perceived scope and polish.

Does your game look and feel like a $10 game or a $40 game? Judge this from the outside, the way a player who has never heard of you would. Your trailer, your capsule art, your screenshots, your UI, the content volume implied by your store description. This is uncomfortable to assess honestly, but it matters. Blind surveys with friends and industry colleagues who don’t know much about your game can be a decent barometer. A game with rough placeholder-feeling UI and three hours of content cannot hold a $20 price in the market as it is right now. Not because it isn’t worth it, but because the value signal doesn’t match the number.

Audience price sensitivity.

How price-sensitive is the specific audience your game targets? Casual and mass-market audiences are highly sensitive; small price differences meaningfully affect conversion rates. Hardcore niche audiences (grand strategy, simulation, certain RPG subgenres) tend to be less sensitive because they’re enthusiasts who have self-selected into the category. This matters for both your launch price and how aggressively you can hold it before discounting.

Positioning intent.

Are you trying to maximize the number of players who come into your game (accessible entry point, high volume, lower margin per unit), or are you signaling quality and premium value to a specific audience (higher margin, narrower initial funnel, stronger brand positioning)? This is a genuine strategic choice, not a wrong or right answer.

Lethal Company launched at $9.99. That price was a deliberate accessibility call for a co-op game that needed groups of players to buy simultaneously and tell their friends. The low barrier is part of the product’s viral logic. Disco Elysium launched at $39.99 in 2019 with no franchise behind it, no recognizable studio name, and no multiplayer hook. That price was a signal: this is a serious, authored experience and it demands to be taken seriously. Both decisions were correct for what those games were trying to do.

A game designed to spread virally through the co-op social graph has different pricing logic than a tight, authored solo experience targeting enthusiast players. Both can work. But they pull in different directions, and you need to decide which one you’re doing before you open a spreadsheet.

Score each of the four variables on a 1–5 scale using the criteria in Sheet 2 of the spreadsheet (Four Variables). The Total Weighted Score maps to a recommended price tier. Fill it in and see where you land before reading the market context below.

A note on what the data says about the current market: GameDiscoverCo’s analysis of the top 50 Steam launches by monthly copies sold shows the median launch price fell from $23.70 in early 2023 to $20.35 by late 2025, a 14% decline. The average barely moved (down roughly 2%), which means cheaper games are winning on unit volume even when higher-priced games can still perform. The practical conclusion, in Carless’s own words: for a new IP from a non-pedigreed team that isn’t a deep strategy game, “charging above $25 is getting trickier, as players compare value to $10–$15 indie titles.”1 That’s not a ceiling. More like a warning about where the burden of proof increases.

The market is polarizing. Strong performance under $20, strong performance at the $60–70 AAA tier, and a harder middle. If you’re planning to sit between $25 and $55 with an unknown studio and an unknown IP, the data says you need a clear reason why.

Step 3: set your launch price with the discount buffer built in

Steam’s algorithm is built around discounting. A discount of 20% or more triggers wishlist notification emails, which is Valve’s primary re-engagement mechanism. Everyone who wishlisted your game gets an email. If your discount is 15%, no emails go out. The difference between 15% and 20% is not five percentage points of margin. It’s the difference between silence and thousands of direct notifications delivered by Valve’s infrastructure on your behalf.2

The practical consequence is that you will probably discount your game. Not because it’s ideologically the right thing to do, but because the platform’s discovery mechanics are structured around it. Games that hold firm on full price and never discount do exist (e.g.: Factorio), but they are the exception, and they typically have an existing audience large enough to sustain them through word of mouth alone. If you’re launching your first commercial game, you’re probably not in that position.

Which means the question isn’t whether to discount or not, but how to set your launch price so that when you do discount to trigger those wishlist emails, the discounted price is still the number you actually want to sell at.

The math is quite simple. If you want to sell the game at $14.99 during discount events and you want at least a 25% discount to do it, your launch price needs to be around $19.99. Sheet 3 of the spreadsheet (Price & Discount Model) calculates this automatically from your target sale price and desired discount depth.

You also have to think about the discount staircase. A discount staircase is a planned sequence of discount depths over the game's lifetime, starting modest and deepening over time. The logic is that your most enthusiastic audience will buy early and close to full price, with each subsequent sale tier capturing the next layer of price-sensitive buyers. Here's how it typically looks in practice for an indie title: an optional launch discount of say, 10–15% if you have a strong wishlist count and want early momentum (noting again that below 20% fires no wishlist emails). Then 20% at the first seasonal sale, the minimum to activate Valve's notification system. Then 25–33% six months out. Then 40–50% at the one-year mark. Then 50–75% in year two and beyond, when you're monetizing the long tail. This varies and it’s contextual, but that’s the gist.

Steam has four major seasonal sales per year: Summer, Autumn, Winter, and Spring. These are exempt from the 30-day cooldown between discounts that applies to custom discount events. You need to plan your calendar around those four first, then schedule any custom discounts around them. Running a custom discount that ends less than 30 days before a seasonal sale is safe. Running one that overlaps with or immediately precedes the window creates complications.

One more thing worth understanding about the revenue math is the following. When your $19.99 game sells at a 30% discount, you’re getting $13.99 per unit before Steam’s 30% platform cut, which leaves you with roughly $9.79 net. At $19.99 full price, you net about $14. The volume difference during sale events is substantial enough that total revenue during major sales often exceeds what you’d make selling the same number of units at full price over a longer period, but you should know the per-unit economics going in rather than finding them out after the fact.

Step 4: determine your Early Access strategy (if applicable)

Early Access is a financing and community-building tool with important pricing implications. Treating it as just “launching early” is a mistake.

GameDiscoverCo’s analysis of Steam games that exited Early Access in 2025 found that only 20% of them generated more revenue in their first 30 days after 1.0 release than they did in their first month of Early Access. The median 1.0 release revenue was 40% of the first EA month’s revenue.3 Carless put it simply: “the concept that a slow launch can be ‘redeemed by a 1.0 release’ is increasingly out of step with reality.”

What this means practically is that your Early Access launch is likely your biggest commercial moment, not your 1.0. Plan your pricing, your marketing and your community investment around that reality, not around the assumption that there’s a larger second peak waiting at full release.

On the pricing decision itself: the right EA price depends on where you are in development. If your EA build contains more than say, 60% of your final content and the experience is substantively complete, pricing close to your 1.0 target with a modest 10–15% early adopter discount makes sense. You’re rewarding early buyers without cannibalizing 1.0 revenue. If your EA build is genuinely early, say 40% of planned content, price it lower and communicate clearly that the price will rise at 1.0. That communication needs to be explicit on the store page; players who feel surprised by a price increase after they recommended the game to friends are not gracious about it.

EA pricing has no single norm anymore. In 2021, $9.99 and $19.99 dominated; by 2024 to 2025, the range had widened considerably, with successful EA launches like Enshrouded at $29.99 and No Rest for the Wicked at $39.99 sitting alongside cheaper entries and the perennial $19.99 anchor. The long and the short of it is that your EA price should be a considered discount off your 1.0 target, not a round number chosen because others chose it.

Outliers exist in both directions. Peglin launched EA at $19.99 when its direct competitors (deckbuilding roguelikes like Slay the Spire and Monster Train, both at $24.99) were priced higher, and the developer made a deliberate calculation to use the slight underpricing as development runway while building toward full release.4 That worked. But it required a clear strategic rationale and honest self-assessment of the game’s completion state.

Work through Sheet 4 of the spreadsheet (Early Access Pricing) before locking in your EA price. The calculator pulls your 1.0 target price from Step 3 and shows you the per-unit revenue trade-off at whatever EA discount you set.

Step 5: set your regional pricing

A meaningful share of your Steam revenue will come from outside the United States and Western Europe. If you’re only thinking about your USD price, you’re leaving players and revenue on the table.

The good news is that this is the simplest step in the framework. In April 2026, Valve updated its regional pricing tools to offer three conversion methods: a simple exchange rate, a purchasing power parity model, and a combined/blended approach.5 The combined method most closely matches Steam’s prior behavior and is seemingly the safe default for most indie studios.

For almost every region, consider accepting Steam’s suggested regional prices. The system is calibrated on purchasing power parity and decades of transaction data. You are unlikely to outperform it with manual adjustments.

There is one active exception. Poland. The Polish zloty has shifted significantly against Steam’s 2022 baseline, and roughly half of indie titles released on Steam in late 2025 were manually pricing the Polish version 20–25% below Steam’s recommendation. GameDiscoverCo flags this explicitly and recommends the manual adjustment.6 It’s worth the five minutes.

For Brazil, Argentina, LATAM, and MENA, also consider accepting Steam’s defaults but monitor your review sections for price complaints from those regions. A few vocal players telling their local community your game is overpriced relative to local wages can damage your review score in ways that affect discovery. Valve’s new tools make it easier to address this quickly if it comes up.

One thing to watch for with regional pricing is that it affects your discount math. Steam’s average global discount from your USD price works out to roughly 22% when regional prices are factored in. Your actual per-unit net revenue across a global player base is lower than the USD-only calculation suggests. Sheet 5 of the spreadsheet (Regional Pricing) lays out the key regions, the current (status of Steam’s recommendations for each (as of April 2026), and flags where manual adjustments are worth making.

Putting it together

I suggest you run through the five steps in order. Don’t skip the comp analysis to go straight to the scorecard and don’t finalize a launch price without running the discount buffer calculation. Each step builds on the previous one.

What you’re producing at the end of this process is a reasonably defensible rationale, not just a number. If a publisher asks why you’ve priced the game at $19.99, you should be able to explain it in terms of your comp set, your four variable scores, your target sale price, and the discount cadence you’re planning to support it.

And if there is no publisher in the mix, then it’s good for you and your studio to know that you took a smart, methodical, data-informed approach to pricing that honors all the work you’ve put into your game and maximizes your revenue potential.

I hope you find the framework useful! If you have any suggestions for improvements, please do let me know.

Again, you can find the GSU Game Pricing Spreadsheet here. It’s read-only, so you need to download it or make a copy to edit it.

Early in my career, I thought good teams were something that just happened. Serendipitously. You hired the right people, pointed them at a goal, and if everyone was talented enough and professional enough, the team would just automagically figure itself out. The project would shape them, things would gel and good things would ensue.

There’s a kernel of truth in that, but alas, reality is a wee bit more nuanced than that.

What I found over time and across studios is that talented and capable people can be shockingly misaligned on seemingly the simplest things. Like an engineer who assumes decisions are made by consensus working shoulder to shoulder with a game director who believes the team is there to execute on their vision without question; or a producer happy to be able to share an opinion on character art, working with a character artist who interprets those opinions as must-do direction.

The cost from unspoken assumptions can be genuinely expensive. Not just in hours lost to conflict or rework but in the more intangible costs, like the important conversations that don’t happen, the ideas people don’t raise, the tacit decisions to just get along rather than push for the right answer, and so on. Over a two, three, four year production, these costs can seriously add up.

A team charter is, in a way, an attempt to get ahead of all that. Not to eliminate all friction (which is impossible and honestly not even desirable), but to make explicit the things most teams leave implicit until they become problems.

What a team charter actually is

The term gets used loosely in project management circles, so let me clarify how I use it.

A team charter is a collaboratively produced document that captures how a team agrees to work together and why. Put differently, it’s a working agreement between people in the team, covering things like the values the team commits to, the norms or idiosyncrasies that govern how they interact, the clarity around who owns what and how decisions get made, what behaviors are celebrated and what are big no-nos.

That’s it. It’s really not complicated. But the potential value of chartering the team is enormous.

Why it matters more in game development than most people expect

Game development is an amalgamation of creative and technical work (which is challenging) done by people with strong opinions (challenging too), under sustained pressure (also challenging), often without enough information (even more challenges) over what can be or feel like a very long time. That combination creates specific, and yes, challenging interpersonal dynamics that don’t exist in many other industries.

The creative dimension alone produces disagreements that are hard to resolve through normal professional reasoning. When you’re debating whether a feature belongs in the game, you’re oftentimes debating something that can’t be settled by logic or data. You’re negotiating between competing visions, competing values, competing intuitions about what makes the game good. Those negotiations can be generative and healthy, or they can be corrosive and grinding, and a lot of what determines which one you get is whether the team has built enough trust and enough shared process to have those conversations in a healthy manner, without leaving a bunch of burnt bridges behind.

In a previous article on building a team, I wrote about psychological safety and what the research says about it. Specifically Google’s Project Aristotle, which found that the single most predictive factor of team effectiveness was whether people felt safe to take interpersonal risks: to speak up, disagree, admit uncertainty, propose ideas that might be bad. The team charter is not a magic wand that creates psychological safety. But it is one of the most practical mechanisms I know for building the conditions that make that safety possible.

When the team has explicitly agreed, together, that disagreement is expected and welcome, that feedback is given directly and received openly, that nobody has to pretend to know things they don’t know, etc., those agreements create a kind of permission structure. People know what the team stands for because they helped define it. That knowledge is empowering.

There’s also a more prosaic benefit that I undervalued early on: onboarding. When a new person joins a team that has a charter, they get to read how this particular team operates, not teams in general, not agile teams theoretically, but this specific team. How they communicate, what they value, how they make decisions, what the norms are around feedback and conflict. That is legitimately useful. It compresses the amount of time a new person spends figuring out the implicit social rules, which is time they spend making mistakes or holding back rather than contributing.

The charter workshop

Depending on the team, size and complexity, plan for two to four hours. You can do a lean version in two hours if the team is small and the conversations stay focused. Don’t compress it into less than that, or you’ll end up with something too shallow to be useful.

The session should be facilitated. If you’re the founder or the studio director, I encourage you to either participate as a team member and find someone else to facilitate, or don’t participate at all. This is contextual, of course, but you need to understand that the fact that you pay other people’s salaries puts an enormous amount of pressure on them, consciously or unconsciously. You want to draw out what’s really important to the team in the most unbiased way possible, so be mindful of that throughout this process.

Do this before the unhealthy disagreement starts. The best time is during the early weeks of a new project or a newly formed team. The worst time is when there’s already a conflict the charter is implicitly being used to adjudicate. By then, the session risks becoming political.

Over the years I’ve run this workshop in various forms, with parts borrowed from different facilitation frameworks. What I’ve landed on now is roughly built around Simon Kneafsey’s Scrum Team Charter Canvas from scrum.org. It’s a great little tool: it covers the right territory, keeps you from going too deep too early, and produces something tangible that you can act on. The underlying methodology stays consistent regardless of what you fill it with: individual reflection on post-its first, then share one by one, then cluster and discuss. The clusters become the agreements. The canvas gives you the buckets.

Here’s how I run it.

Who are we and what do we do (~30 minutes)

Start here, not because it’s the most important section, but because it’s the warmest entry point. Each person takes five minutes and writes a few post-its answering: who am I on this team, what do I bring, what do I care about in how I work?

Then share one by one. Go around the room (or the call). No debate yet, just listening. The goal is for the team to actually listen to each other’s motivations and self-perceptions, which are often different from the assumed ones and sometimes surprising. Maybe the senior engineer who seems like a technical purist actually cares most about mentoring junior developers. Maybe the artist who seems low-key is deeply invested in the aesthetic vision and gets anxious when it feels like it’s slipping.

This is not filler. It’s context that makes every subsequent conversation easier, because you’ve established that there are actual humans at the table with actual reasons for being here.

Our purpose, mission and goals (~30 minutes)

Same pattern: post-its first, then share, then cluster. The question is: why does this team exist, what are we trying to make, and what does success look like for each of us personally, not just for the game?

The personal angle is important. Teams can align on a game concept while having different ideas about what winning looks like. The designer who wants to make something critically acclaimed and the producer who wants to hit commercial targets and get to the next project are not automatically in conflict, but they might be if neither of them ever makes that explicit.

Work toward a shared purpose statement: a couple of sentences, concrete enough that you’d know if you were departing from it. Not a mission statement in the corporate sense. More like: if someone asked the whole team in six months why they’re making this game, they should be able to give roughly the same answer.

Our values and principles (~30 minutes)

Post-its. Share. Cluster.

Each person writes down the three to five principles they personally believe make a team function well. Not abstract values, actual behaviors. Things like “feedback is given directly and privately before it’s raised in a group setting” or “we don’t revisit decisions in the hallway after they’ve been made in the room. If we have disagreements, we talk about them together.”

After sharing, look for themes and look for tensions. The themes become candidates for the charter. The tensions are equally important, because they reveal places where the team has genuinely different instincts. Those differences, if you don’t put a name to them, will likely produce friction throughout production. Named and negotiated, they become agreements you can actually operate from.

This is also a good moment to have the studio’s existing values in your pocket, if you have them. You don’t need to mimic them in the charter, but awareness of them helps the team understand how their working agreements sit within the broader organizational context.

Keep it to three to five values. Specific enough to be actionable. “We respect each other” is not a value, it’s an aspiration. “We give feedback on the work, not the person, and we separate critique from judgment” is a value. There’s a behavior implied in it.

Our norms and rules (~45 minutes)

This is where I believe the canvas really earns its keep, and where many teams do the least preparation. It has four sub-sections and they’re all important.

Things we always do and things we never do. These are the behavioral norms that define how this team actually operates. How do we communicate between meetings? What’s the expected response time on messages? How do we run design reviews? Do we show up on time, do we have cameras on, do we take notes? They feel small, but they’re absolutely not.

How do we make decisions? Who makes which kinds of decisions? Are there categories that require full team consensus, versus ones that belong to a specific role? What happens when there’s genuine disagreement that can’t be resolved? Having an explicit answer to that last question, even if the answer is “the game director makes the final call after hearing all perspectives,” is infinitely better than leaving it implicit.

When and how do we raise issues or ask for help? This question sounds obvious until a junior team member sits on a problem for two weeks because they didn’t know whether to bring it to the producer or the game director, or whether raising it would make them look incompetent. Make the path explicit. And model it humbly for others.

What do we do when the rules are broken? Not as a disciplinary framework, but as a mechanism to repair the norm. When someone violates an agreement, how does the team address it? Who says something and how? Teams that don’t have an answer to this question tend to either let violations accumulate slowly or escalate straight to conflict. Neither is optimal.

How we work (optional, ~30 minutes)

This section is optional in the sense that it depends on how your team runs its process. If you’re using Scrum, the canvas has specific questions for it: how will you keep the sprint backlog updated, how do you ensure an increment gets completed each sprint, what are the boundaries of your self-management? Those are worth answering explicitly if Scrum is your methodology.

If you’re running Kanban, a hybrid, or something more bespoke (which is common in indie game development), adapt the questions: how do we run our standups? What does a review or playtest look like for us? How do we handle retrospectives, and how often? Who owns the board or the backlog? The specifics vary. The point is to make your actual process legible to everyone on the team, not just the people who set it up.

I encourage you not to skip this entirely. Process assumptions left implicit are a fairly reliable source of confusion, especially for new team members and especially in distributed teams where you can’t just watch how things work from across the room.

Agree and commit (~15 minutes)

Read the whole thing back together. Give everyone a moment to flag anything that doesn’t feel right or that they don’t genuinely commit to. This is not a rubber-stamp exercise. If someone has a real objection, this is the time to hear it. Then ask for explicit agreement. Not enthusiasm, just genuine yes, this represents how we’ve agreed to work.

Sign it if you want. Some teams do, some don’t. The ritual matters less than the actual agreement.

Making it live and evolve

The biggest mistake of the charter workshop is generating a beautiful document that nobody ever looks at again. I remember a studio where there was a charter framed on the wall and, no joke, a good half of the team, I’m talking about people who had participated in the chartering exercise, had no idea what thing on the wall was. It goes to show that chartering is just the first step. This is a process, not a one-time activity.

Let me share a few things I’ve seen work for keeping the charter alive.

Put it somewhere visible and accessible. Not buried in the deepest, darkest link of your studio’s Wiki. If you’re in a shared physical space, print it and put it up on a wall. If you’re distributed, make it the opening page of your team wiki and reference it by link regularly. New hire joins? Walk them through it in their first week. Not as a corporate onboarding checklist but as an actual conversation about how this team works.

Reference it when it’s relevant. When a decision is being made about process, you can ask “does this align with what we said we’d do?” When there’s a conflict about how feedback was given, the charter provides a neutral reference point. Not “you did it wrong” but “here’s what we agreed.” That wording is significantly less charged.

Revisit it at relevant syncs, like retrospectives)=. Not every retrospective or team meeting, but with some degree of regularity. Every quarter is a reasonable cadence for a studio in active production. The question isn’t “is our charter still nice?”, but: “are we actually living this and is it still the right thing to be living?” Sometimes a norm that made sense at the start of production doesn’t make sense nine months in when the team has grown and the dynamics have changed. Inspect and adapt. It’s a living document, so do update it as needed.

I’ll also say this: the charter works best when leaders model it, not just enforce it. If the game director says the team values direct feedback and then gets defensive when they receive it, the charter is dead. The implicit message is louder than the explicit agreement. What the people with the most status in the room actually do is what sets the ceiling for everyone else. I’ve written about this before, again in the context of psychological safety, and it applies here in exactly the same way.

What I’ve learned through the process of getting team chartering wrong before getting it right, is that the human infrastructure is the real work. The studios that shipped solid games, with teams that stayed intact and proud of what they built, they almost all had strong human working agreements underneath them, whether or not anyone called it a charter. And the ones that didn’t ship, or shipped badly, or left people burnt out or resentful... the human infrastructure was usually where things started coming apart.

A half day at the beginning of a project and a little bit of discipline to stay on top of this at a sensible cadence. That’s the ask. It’s worth it.

If this was useful, you might also like:

I'm Sebastian. Twenty years across AAA studios (Riot, Crytek, EA), indie and founding roles. I write at Game Studio Unlocked because I want to help the next generation of indie game studios do great. I also work directly with a few studios at a time as a fractional COO and executive producer. More at gamestudiounlocked.com or on LinkedIn.

This is a financial management playbook for game studios. Admittedly not for everyone. I write primarily with studio founders and directors in mind, but I do hope anyone in game development can gain a few insights and calibrate expectations around the financials of game studio management.

Financial topics put most developers to sleep even faster than legal ones. But here’s the thing: money doesn’t quite wait for you to get interested in it. Studios ignore their financial management at their own peril. The studio founder who’s never looked at a cash flow statement is usually the same person calling investors at month sixteen telling them the runway has “suddenly disappeared” and that they need a cash injection.

I’m neither an accountant nor a financial advisor. This guide is not a substitute for professional financial advice and you should work with qualified professionals before making major financial decisions. What I am though is a COO who has seen a fair share of studios make the same avoidable money mistakes over and over, and who has spent two decades learning, sometimes the hard way, what you actually need to understand to keep a studio alive and building.

This article is the financial counterpart to my legal primer for game studios. It’s the same idea: I want to give you enough working knowledge to understand what you need, when you need it and when you can handle it yourself versus when you need to call someone.

A note on scope. This is a US-focused article. Banking, taxes and accounting practices vary a lot by country. If you’re outside the US, the categories are largely universal: you need a bank, you need accounting software, you need to track burn and runway, you need to file taxes. But the specific instruments, rates, deadlines and institutions are not. Find your local equivalents.

Part 1: opening a business bank account

Before anything else, you need a business bank account that’s separate from your personal account. Don’t indulge in “I’ll keep track of what’s business and what’s personal” in your personal account. Please get an actual separate business account.

I cannot overstate how much simpler this makes everything that follows. Your accounting is cleaner, your tax filing is cleaner, your burn rate tracking is accurate and if you ever take on investors or get acquired, the financial hygiene of having clean separation is something people will actually check.

What you need to open one

At a minimum: your EIN (Employer Identification Number, issued by the IRS. You apply for one free at irs.gov), your entity formation documents (Articles of Incorporation or Articles of Organization. See how to incorporate here) and a government-issued ID. Some banks also want an operating agreement or bylaws and some require a minimum opening deposit. Check the specific bank’s requirements in advance.

Getting an EIN is free and takes about ten minutes on the IRS website. There is no reason to pay a service to do this for you.

Traditional banks vs. fintech platforms

This used to be a simpler question. You walked into a bank, you opened an account, that was it. Now there’s a real choice to make and the right answer depends on your situation.

Traditional brick-and-mortar banks. Chase, Bank of America, Wells Fargo, US Bank and similar, have the advantage of physical presence (if you ever need to deposit a check or deal with something in person), established track records and FDIC insurance coverage. Their business accounts often come with fees (monthly maintenance fees, transaction fees, minimum balance requirements) and the online experience is generally worse than the fintech alternatives. They can also be slower to open accounts and more bureaucratic to deal with. That said, for studios that have investors or are raising money, some investors and accelerators specifically want to see accounts at recognizable institutions.

Fintech banking platforms. Mercury, Brex, Ramp, Rho and similar, have built products specifically for startups and it shows. The onboarding is faster, the interfaces are significantly better, they typically have no minimum balance requirements or monthly fees for early-stage companies, and they offer features that traditional banks don’t, like virtual cards, spend controls, real-time notifications, integrations with accounting software and expense management built in, etc. Mercury and Brex in particular have become a default recommendation in startup circles for early-stage companies and honestly for good reason: they’re free to start, clean and designed for exactly the kind of company you’re building.

A few things you should know about the fintech options: your deposits are still FDIC-insured (they partner with FDIC-member banks to hold deposits), but these are not banks themselves, they’re banking service providers. That distinction matters in the rare event of a platform failure, which did cause real problems for some Mercury customers during the SVB crisis in 2023. Worth being aware of. Most fintech platforms now maintain deposit sweeps across multiple partner banks to reduce concentration risk.

What I’d suggest for most early-stage indie studios: start with something like Mercury. It’s free, it’s fast to open, it has everything you need for basic operations and it integrates cleanly with accounting tools. If you raise a meaningful round (say, above a million dollars), reconsider whether you want to diversify across platforms or add a traditional bank relationship. Don’t overthink this at the bootstrapped stage.

What to look for when choosing

Whether you go traditional or fintech, this is roughly the comparison criteria:

• Monthly fees and minimum balance requirements

• Transaction limits and fees (ACH transfers, wire transfers, checks)

• FDIC insurance and how it’s structured

• Integration with accounting software (QuickBooks, Xero, etc.)

• Quality of the online/mobile experience

• Credit card or corporate card options

• Customer support responsiveness - when something goes wrong, can you reach a human?

And if you’re unsure what to pick, I encourage you to reach out to other game entrepreneurs and ask them about their experience with their financial institutions. Nothing like some first-hand recommendations or words of caution.

Corporate cards

Separate from your bank account, you’ll probably want a corporate card or a business credit card fairly quickly. This is how you pay for software subscriptions, contractor invoices, cloud hosting, conference fees and all the miscellaneous operational spend that happens constantly.

The fintech platforms (Brex, Ramp, Rho) have built their corporate card products to be genuinely useful: spend controls per employee or per category, receipt capture via mobile, automatic categorization, direct sync to accounting software, etc. If you’re using Mercury for banking, their card product is reasonable. If you want more sophisticated spend management, Ramp or Brex are worth looking at. Ramp in particular has become popular for its spend analytics and the way it flags unusual charges automatically.

For a studio of five people, this is probably more infrastructure than you need immediately. But as soon as you have more than one or two people making purchases on behalf of the company, having a corporate card system with some structure around it can save you a lot of accounting pain later.

Part 2: accounting basics (aka: tracking what’s coming in and going out)

Accounting is not conceptually complicated. It’s the discipline of recording every financial event, every dollar that enters and every dollar that leaves, accurately, consistently and in a way that lets you understand the state of your business at any moment.

In practice, most founders treat accounting as a thing that happens at tax time. You collect receipts throughout the year, hand them to someone in January and hope for the best. This is how you end up with a distorted view of your own finances for most of the year, surprised by tax bills and unable to answer basic questions about where your money is going.

The better approach is real-time bookkeeping, which sounds harder than it is if you have the right tools set up.

Accounting software

You need accounting software. Not a spreadsheet. Actual software that connects to your bank account, categorizes transactions, tracks income and expenses and generates the financial reports you (and eventually your accountant) will need.

The three most commonly used options for small studios and startups (that I know of) are these:

QuickBooks Online is the most widely used small business accounting software in the US. Your accountant almost certainly knows it and may prefer it. It connects to most banks, handles invoicing, payroll integration, expense tracking and generates all the standard financial reports. It is also more expensive than the alternatives - plans run from about $35 to $100+ per month depending on features, and the interface can be clunky. Very clunky, if you ask me. If your accountant has a strong preference, follow it. If not, it’s a solid choice with the widest professional support.

Xero is the main competitor to QuickBooks. Slightly cleaner interface in my experience, comparable features, a bit cheaper. Strong integrations with other tools. More popular outside the US than within it, but gaining ground. If you’re working with international contractors or plan to have team members in other countries, Xero’s multi-currency support is better than QuickBooks by default.

Wave is free and perfectly adequate for a very early-stage studio with simple finances: no payroll, no complex expense management, just basic income and expense tracking. The catch? Wave’s free product is genuinely limited and Wave’s support is essentially nonexistent unless you pay. When your finances get even slightly complex, you’ll outgrow it quickly.

My general recommendation for an early-stage indie studio: start with QuickBooks Online Simple Start or Xero’s starter plan. Connect it to your bank account the day you open the account. Do not wait until tax time to set this up.

The basics of what you’re tracking

Every financial event falls into one of two buckets: money coming in (revenue and other income) or money going out (expenses). Within expenses, some things are operating costs (salaries, software, rent, equipment) and some are cost of goods sold (royalties paid out, revenue share, platform fees on your game revenue). The difference matters for how your finances are reported, though for a very early-stage studio the distinction is somewhat academic.

These are the most common categories of expense you’ll want to track separately from day one:

• Salaries and contractor payments

• Software and tools (Unity, Adobe, productivity tools, accounting software itself)

• Hardware and equipment (computers, servers, Wacom tablets)

• Cloud services and hosting (Azure, AWS…)

• Marketing and advertising (marketing agency, campaign)

• Travel and conference costs (GDC, Gamescom)

• Legal and professional fees (accountant, legal counsel)

• Insurance (worker’s comp, disability)

• Office costs if applicable (lease, furniture, electrical)

The reason you track categories rather than just total spend is that you want to see where the money actually goes. “We spent $80,000 last quarter” tells you almost nothing. “We spent $80,000 last quarter: $55,000 in salaries, $8,000 in contractors, $5,000 in software, $4,000 in travel and $8,000 in one-time legal fees” tells you something you can potentially act on, if needed.

Invoicing and accounts receivable

If you have revenue coming in, like milestone payments from a publisher, grant disbursements, consulting work, you’ll need to invoice for it and track when those invoices are paid. QuickBooks and Xero both have invoicing built in. The important habit here is to send invoices promptly when work is delivered or a milestone is hit, follow up on unpaid invoices before they age past 30 days and reconcile received payments against invoices in your accounting software. Outstanding invoices (money owed to you that hasn’t arrived yet) are not cash. Don’t treat them as cash.

Accounts payable

The other side: money you owe. Contractor invoices, vendor bills, subscription renewals. Log these when they arrive, not when you pay them. The gap between when you owe money and when you actually pay it affects your cash flow, especially if you’re managing against a budget.

Reconciliation

Once a month, reconcile your bank accounts: compare your accounting software’s record of transactions to your actual bank statement and resolve any discrepancies. This takes thirty minutes if you’re current and a full miserable afternoon if you let it go for three months. Stay current.

Part 3: burn rate and runway (the two numbers that matter most)

Every other financial concept in this article is important. But these two are the ones that determine whether your studio survives.

Burn rate is simply how much money you’re spending per month, net of any revenue. If you’re spending $40,000 per month and bringing in $5,000, your net burn is $35,000 per month.

Runway is how long your current cash reserves will last at your current burn rate. If you have $350,000 in the bank and your net burn is $35,000 per month, you have ten months of runway.

That’s it. Those are the definitions. They’re not complicated.

What is complicated (or at least consistently underestimated) is what it takes to actually know these numbers accurately in real time. Most founders I’ve worked with have a rough sense of their burn. Almost none of them have a number they’ve calculated rigorously and updated recently. And the consequences of that gap tend to surface at the worst possible moments.

Calculating burn rate

Your gross burn is total monthly outflows: salaries, contractor payments, software subscriptions, all of it. Your net burn subtracts any monthly income from that. For a studio pre-launch with no revenue, gross and net burn are the same.

The trap is one-time expenses. A legal bill, a conference trip, a piece of equipment - these inflate a single month’s burn in a way that can be misleading if you’re not distinguishing between recurring and non-recurring costs. Know both numbers: your recurring monthly burn (the baseline you’ll hit every month regardless) and your total burn including one-time items.

Calculating runway

Cash in the bank, divided by monthly net burn. If your burn fluctuates, use a three-month rolling average rather than the most recent month.

The uncomfortable thing about runway is that it should be recalculated monthly, not quarterly, and definitely not once when you raise money and never again. The number changes every month. Sometimes it changes faster than you expect, because expenses that seemed fixed turned out not to be, or because a revenue event you were counting on was delayed.

The runway danger zone

In my experience, twelve months of runway is the point where you should be actively working on the next funding source or revenue event, not the point where you start thinking about it. Six months is the danger zone, you’re in conversations that are actively constrained by time pressure, which weakens your negotiating position. Three months is absolute crisis mode.

Most studios hit these thresholds later than they should have started preparing for them. The reason is that when runway is eighteen months, it “feels” far away. When it’s six months, it’s suddenly very present. The founders who manage this best are the ones who maintain a running model of their finances and treat the runway number as a live metric rather than a one-time calculation.

A simple runway model

You don’t need sophisticated financial modeling software for this. A spreadsheet with the following columns is enough:

Month, Starting Cash, Revenue (by type), Total Revenue, Expenses (by category), Total Expenses, Net Burn, Ending Cash.

Build out twelve to eighteen months of projections. Update the actuals column each month when your accounting software has the real numbers. The projected future months are your best current estimate of what’s coming, and those estimates should be based on real contracts, real headcount plans and real known expenses, not optimism.

When the actuals start diverging significantly from the projections, that’s the moment to act: either cut expenses, accelerate revenue or start fundraising conversations earlier than you planned.

If you don’t want to make your own spreadsheet, you can find a template here.

Part 4: bookkeepers vs. accountants

This is a common question and the confusion is understandable because the two roles sound similar and people use the terms interchangeably, which they shouldn’t.

A bookkeeper handles the day-to-day recording of financial transactions. They make sure expenses are categorized correctly, invoices are logged, reconciliation happens on schedule and your books are accurate and current. Bookkeeping is tactical, it’s operational.

An accountant (specifically a CPA - Certified Public Accountant) handles the higher-level financial work: tax planning and filing, financial statement preparation, strategic financial advice, audit support and complex situations requiring professional judgment. Accounting is more interpretive. It’s what you do with the clean books the bookkeeper produced.

When you need a bookkeeper

Sooner than you think. Honestly, from the moment you have regular business transactions happening (a few contractor invoices per month, software subscriptions, any payroll) having someone keep the books current is worth the cost. A part-time freelance bookkeeper runs anywhere from $300 to $800 per month for an early-stage studio depending on volume and location. That is cheap relative to the cost of a tax filing that takes four times as long because the books are a mess, or a financial decision made on bad information.

You can do your own bookkeeping early on, and for a solo founder with very simple finances, it’s entirely reasonable to do so for the first six months or year. But as soon as you have employees or multiple contractors, I want to kindly poke you to delegate this. Your time is worth more than this cost.

Finding a bookkeeper: ask other founders for referrals, look for bookkeepers who specifically have startup or creative industry experience and verify that they’re familiar with your accounting software (QuickBooks or Xero). The Bench Accounting platform pairs you with a dedicated bookkeeper and uses their own software. It’s more expensive than a freelance bookkeeper but more structured and some founders find it easier to manage.

When you need an accountant

At minimum, once a year for tax filing. As a business, you are filing a business return separate from your personal return, and the complexity of that filing (depreciation, contractor payments (1099s), payroll taxes if you have employees, state filings) is enough to warrant a CPA unless your finances are exceptionally simple.

More than just tax season, a good CPA should be someone you talk to two or three times a year: when you’re about to make a major financial decision (taking on investment, issuing equity, signing a significant contract), at mid-year to check whether your tax position is what you expected and during any major structural change to the business.

The specific things a CPA adds value on for a game studio: tax elections at formation (S-corp election timing, for example), R&D tax credits (more on this below), multistate tax obligations if you have employees in multiple states, international contractor withholding questions and audit support if you’re ever flagged.

Finding a CPA: ask founders you respect, look specifically for CPAs with startup or creative industry experience. A CPA who primarily serves retail businesses or individuals may not know the specific considerations that apply to game studios. The difference matters.

Part 5: basics of taxes in the US

I want to demystify this as much as possible, because the combination of complexity, unfamiliarity and anachronistic government websites makes taxes feel more opaque than they need to be. The US tax system is genuinely complicated in places, but the foundational obligations for a small studio are manageable if you understand what they are and stay ahead of them.

Disclaimer: tax law changes, your specific situation has details that matter, and this section is orientation, not advice. Work with a CPA before filing anything.

Your business return

The form your business files depends on your entity type.

If you’re an LLC taxed as a sole proprietor or single-member LLC: your business income and expenses flow to your personal return on Schedule C. There’s no separate business return.

If you’re a multi-member LLC: the LLC files a Form 1065 (partnership return) and issues each member a K-1 showing their share of income, losses and deductions. Each member reports their K-1 on their personal return.

If you’re a C-corp: the corporation files Form 1120. Corporate income is taxed at the corporate rate (currently 21% federally). This is separate from your personal return. If the corporation pays you a salary, that salary is a deductible business expense for the corp and taxable income for you personally.

If you’re an S-corp: the corporation files Form 1120-S and issues K-1s, similar to a partnership. Pass-through taxation means the income is taxed at the individual level, not the corporate level.

Estimated quarterly taxes

This is the one that surprises founders most often in their first year. If you expect to owe more than $1,000 in federal taxes for the year (which is most founders drawing any compensation from their business), you are required to pay estimated taxes quarterly rather than one lump sum at filing time. The due dates are approximately: April 15, June 15, September 15 and January 15.

Missing estimated tax payments doesn’t automatically mean you get a huge penalty. You pay underpayment interest on what you should have paid. But the bigger issue is the cash flow surprise: founders who haven’t set aside money for quarterly taxes routinely find themselves scrambling for cash in April. The simplest approach: every time money comes into the business, set aside 25-30% in a separate savings account earmarked for taxes. It’s a rough estimate but it prevents the worst surprises.

Payroll taxes

If you have W-2 employees (including yourself if you’re on payroll as a C-corp or S-corp officer), you have payroll tax obligations. These include federal income tax withholding, Social Security and Medicare (FICA) taxes and any applicable state income tax withholding. Payroll taxes are paid to the IRS on a semi-weekly or monthly schedule depending on your payroll size, not at year end.

Running payroll manually is not something I’d recommend. Use a payroll service. Gusto is the most commonly used for small startups and honestly it’s well-designed for exactly this context: it handles withholding, deposits, year-end W-2s and 1099s, and integrates with QuickBooks and Xero. At the scale you’re at, it costs around $40-$80 per month depending on the number of employees. Worth every dollar compared to the risk of getting payroll taxes wrong, which the IRS is not forgiving about.

1099s for contractors

If you pay any contractor (individual or unincorporated entity) more than $600 in a calendar year, you are required to issue them a Form 1099-NEC by January 31 of the following year. To do this, you need each contractor’s information on file, specifically their name, address and EIN or Social Security number, which is collected via Form W-9 before you pay them.

Get into the habit of collecting a W-9 from every new contractor before you pay their first invoice. Not after. Before. Chasing W-9s from contractors in January is unpleasant. Having them on file already is not.

R&D Tax Credits

Arguably most indie studios don’t know about these credits and they really should. The federal R&D tax credit (Section 41 of the Internal Revenue Code) allows businesses to claim a credit against their tax liability for qualifying research and development expenses. Game development, specifically the work of developing new game mechanics, systems, engine technology and interactive software, can qualify.

For startups and small companies that have little or no tax liability yet, there’s a provision that allows the R&D credit to offset payroll taxes (specifically the employer’s share of Social Security taxes) up to $500,000 per year. Which means even if you’re not yet profitable and paying income tax, you may be able to reduce your payroll tax burden through this credit.

The credit is calculated on qualifying research expenses: wages paid to employees doing qualifying R&D work, contractor payments for qualifying work (with some limitations) and supplies used in R&D. The calculation is more involved than I’ll walk through here, but the potential value is significant enough to be worth a dedicated conversation with a CPA who knows this credit. Many don’t raise it proactively, so you should.

State taxes

You will owe state income tax (in states that have it) and potentially state sales tax and franchise tax depending on where you’re incorporated and where you operate. State tax obligations multiply when you have employees in multiple states: each state where you have a nexus (typically an employee) creates filing obligations in that state.

California in particular is worth drawing attention to because so many studios are based here and its tax obligations are substantial: California has a minimum franchise tax of $800 per year even for companies with no income, a relatively high corporate tax rate and aggressive enforcement of employment classification rules.

Multistate taxes are genuinely complex. If you have employees in more than one state, this is not a DIY situation. Get CPA guidance.

Part 6: the most common and most important financial statements

These documents sound intimidating but they’re really not that complicated. They’re each just answering one specific question about your business’s finances.

Profit and Loss Statement (P&L)

(also called Income Statement)

The question it answers: did we earn or lose money over a specific period?

The P&L shows revenue, cost of goods sold (direct costs of generating that revenue), gross profit (revenue minus cost of goods sold), operating expenses (everything else, salaries, software, rent, marketing) and net profit or net loss (what’s left after everything). It covers a period of time: a month, a quarter, a year.

For a pre-revenue indie studio, the P&L is mostly a summary of your expenses with zero revenue at the top. It still matters because it tells you where your money is going and at what rate. Once you have revenue - a publishing advance, early access sales, anything - the P&L starts answering the real question: is the business economically viable?

The P&L is probably the financial statement you’ll look at most often and the one you’ll share most frequently with investors, publishers and potential partners.

You can find multiple templates here.

Cash Flow Statement

The question it answers: did cash reach or leave our bank account?

This one confuses people because it sounds like it should be the same as the P&L, but it isn’t. The difference is this: the P&L records revenue when it’s earned and expenses when they’re incurred, regardless of when cash actually changes hands. The cash flow statement only records cash when it actually moves.

Let me give you a concrete example: you sign a publishing deal that gives you a $200,000 advance paid in four $50,000 milestone installments. The first milestone payment arrives in January. On your P&L, you might recognize different amounts in different periods: this month’s $50,000 payment, next month’s $50,000 payment, etc., even though none of that money has reached your bank account yet. But on your cash flow statement, January shows $50,000 incoming, because that’s when the cash actually arrived. The cash flow only cares about bank balances. It tracks the physical movement of dollars in and out of your accounts, not “earned money” that still hasn’t materialized in your bank account.

For a pre-revenue bootstrapped studio, the cash flow statement is the most honest picture of your survival. It tells you exactly how your bank balance is moving. The basic format: operating cash flows (cash from or used in running the business), investing cash flows (cash spent on or received from long-term assets like equipment) and financing cash flows (cash from fundraising, loans or equity).

The cash flow statement is where you see whether you’re actually generating or consuming cash, regardless of what the P&L says about profitability.

You can find multiple templates here.

Balance Sheet

The question it answers: what does the company own, what does it owe and what’s left over for the owners?

The balance sheet is a snapshot at a single point in time, not a period. It has three sections:

Assets: what the company owns. Cash, accounts receivable (invoices that haven’t been paid yet), equipment any IP the company has recorded as an asset.

Liabilities: what the company owes. Accounts payable (bills that haven’t been paid yet), loans, deferred revenue (money received for services not yet delivered).

Equity: the residual. Assets minus liabilities equals equity, which represents the owners’ stake in the business. For a startup, equity often includes founder capital contributions, accumulated net income or losses and any outside investment.

The balance sheet is primarily useful for understanding the overall financial health of the business: how much cash do we have, what are we owed, what do we owe and what’s the net position? Investors and acquirers look at balance sheets closely. Publishers doing due diligence may conceivably want to look at them too.

This will make any CPA reading this cringe, but I’ll be honest: I’ve yet to find real, applicable value in maintaining a balance sheet. Your mileage may vary.

You can find multiple templates here.

The relationship between the three

They’re connected. Net profit from the P&L flows into equity on the balance sheet. Cash changes on the cash flow statement change the cash line on the balance sheet. If you have clean books and they’re all generated from the same accounting software, they’ll reconcile automatically. If they don’t reconcile, something is recorded incorrectly.

Budget vs. actuals

This is less a standalone document and more a practice: comparing what you planned to spend (your budget) against what you actually spent (your actuals). It’s one of the most practically useful financial habits for a small studio because it tells you where your assumptions were wrong and forces you to make explicit decisions about variances rather than just absorbing them silently.

In its simplest form it’s this: a spreadsheet with budgeted amounts by category per month, actual amounts from your accounting software and the variance between them. When actual spending runs significantly above budget in a category, you investigate why and decide whether to adjust the budget (if the spend is justified and recurring) or change behavior (if it’s not).

Several templates here.

Part 7: a few best practices

Open your business account before you spend a single business dollar. Every purchase you make on your personal card for business purposes that you then have to reimburse is extra work with a meaningful risk of things falling through the cracks. Set up the business account first.

Keep personal and business finances completely separate. Even if you’re a sole proprietor or single-member LLC. The commingling of personal and business funds is one of the primary ways courts pierce the corporate veil, meaning your personal assets lose their liability protection. Beyond the legal risk, it just makes everything harder to track accurately.

Understand your payroll obligations before your first hire. The employer’s share of FICA taxes is 7.65% of each employee’s wages. Add to that federal and state unemployment taxes, workers’ compensation insurance and the cost of the payroll service itself. The fully loaded cost of an employee is meaningfully higher than their salary. Know the real number before you make the offer.

Sales tax is a surprisingly live issue for game companies. Digital goods and game sales are subject to sales tax in a growing number of US states. The rules vary by state and have been evolving since the Supreme Court’s 2018 South Dakota v. Wayfair decision, which expanded states’ ability to require out-of-state sellers to collect sales tax. Most platforms (Steam, Epic, Apple App Store) handle sales tax collection on your behalf in most jurisdictions, but if you’re selling direct, this is a question worth getting answered.

Revenue recognition can be complicated. When exactly do you recognize revenue? For a publisher advance, is it all at signing? As milestones are hit? Over the game’s commercial life? Revenue recognition rules (particularly for contracts with performance obligations) have specific GAAP guidance that matters when you’re producing audited financials. For early-stage studios with simple revenue streams, this rarely becomes an issue. When it does, it’s a CPA conversation.

Build a financial model early. Not because investors want to see it, they do, but that’s not the main reason. It’s because the process of building a model forces you to think rigorously about where revenue is coming from, what it depends on and what happens to your runway under different scenarios. A simple model with optimistic, base and pessimistic scenarios for revenue and expenses will tell you more about the health of your plan than almost any other exercise you can do.

Quick reference: financial setup by stage

At founding:

• EIN from IRS (free, irs.gov)

• Business bank account (Mercury is a fine starting point)

• Accounting software (QuickBooks Online or Xero)

• Connect bank to accounting software

• W-9 collection process for every contractor before first payment

Before first contractor payment:

• Corporate card or business debit card

• Expense tracking process established

• Invoice and payment workflow in accounting software

Before first full-time employee:

• Payroll service (Gusto is the common choice)

• Workers’ compensation insurance

• Understand payroll tax deposit schedule

• State employer registration in employee’s state

Before end of first calendar year:

• 1099-NEC forms issued to all qualifying contractors by January 31

• Estimated quarterly taxes paid (if applicable)

• Books reconciled and clean for accountant

• CPA identified and engaged for tax filing

Ongoing:

• Monthly bank reconciliation

• Quarterly estimated tax payments (if applicable)

• Monthly P&L and burn rate review

• Runway model updated monthly

• Annual tax filing (business return and personal return)

Before taking outside investment:

• Clean, audited or at least CPA-reviewed financials

• Cap table current and accurate

• Financial model with projections

• R&D credit analysis with CPA

If this was useful, you might also like: