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:

One of he hardest parts of making (and with a little luck: shipping) a video game is actually knowing when to stop building. It’s remarkably counterintuitive.

Studios get stuck for months and sometimes even years trying to wrap things up. What should be a focused, disciplined sprint to the finish line becomes an absolute quagmire. Work continues, builds are generated, bugs are fixed, all good stuff. The team is definitely busy but the game is just not getting closer to shipping. It feels like one step forward, two steps back.

This happens a lot. And I mean a LOT. And the reason is typically the same: the team never fully switched gears. They kept the mindset of a team in production when what was needed was the mindset of a team closing. Those are genuinely different things, and treating them as if they’re interchangeable is, in my humble experience, one of the biggest reasons games get stuck so close to the finish line.

So this guide is about how to make that switch deliberately. How to get into closing mode. And how to ship.

What “closing” actually means

Closing, or “finaling” as it’s sometimes called, is the phase that starts after your core game is functionally complete and ends when you submit to platform certification (if you’re shipping on consoles) and release. It sounds straightforward but it’s not.

The confusion starts with what the word “complete” means. Most teams have a very loose intuition: the game works, the content is in, the major systems are stable. But “it works” and “it’s shippable” are two very different bars, and the distance between them is where closing lives.

Closing is the systematic process of getting a game from functional to “releasable”: locking content and features, stabilizing performance and memory, hunting and triaging bugs by severity, generating and evaluating release candidates, and eventually submitting a gold master that meets certification requirements across every target platform.

What makes this genuinely difficult isn’t the work itself. It’s the change in how you work. Up until this point, your team has been in creation mode: exploring, iterating, saying yes to ideas, building new things. As it should. The closing phase asks them to stop all of that. No new features. No new content. No creative exploration. From here on out, the work is driven by checklists, bug trackers, certification requirements and a fairly rigid set of criteria that determine when the game is done. For people who got into this industry because they love building things, that’s harder than it sounds.

The psychological cost of that transition is tough, and it’s underestimated. I’ll come back to it.

Wait, I never heard of the “closing phase”

Indeed. That’s because a lot of people in charge of projects don’t talk about it as a distinct phase. There’s a tendency, especially in studios without a strong production infrastructure, to assume that production will just... glide into a gold master. That the team will naturally shift gears as the game gets closer to done. That the checklist mindset will emerge organically as the feature list shrinks.

On occasion it does. If you have a very experienced producer who has shipped before and knows what this transition feels like, they might manage it intuitively, nudging the team in the right direction without ever formally labeling what they’re doing. Or if you’re working in a studio with a well-defined production structure that explicitly accounts for closing, the scaffolding is already there and you step into it.

But most indie studios don’t have either of those things. And when they don’t, what happens is that production just... keeps going. Things drag on, the deadline doesn’t move, but the project is not really getting closer to shipping, teammates get stressed… and boom: now you’re crunching. This is not the number one reason why teams crunch, but it’s a contributing factor.

So I hope you see the correlation between how much crunch there is in the industry and how this development phase gets thoroughly glossed over. It’s not causality, but I’m just saying…

When to start

The short answer is: earlier than you think. The longer answer requires a bit of math.

Here’s a (very) rough model, keeping in mind this is highly variable depending on the scope, complexity of your game, your target platforms, business model and whether your team has done this before.

Work backward from your target release date. If you’re releasing on console, you’ll need to account for first-party certification, which can take anywhere from a few days to several weeks depending on the platform and whether you clear on the first submission (and if this is your team’s first time going through cert, you likely will not). Before that, you need a gold master. Before that, a series of release candidates that are progressively cleaner. Before the RC phase becomes your primary focus, you need a stabilization period, and before stabilization, content and feature locks.

Each of those phases has a minimum viable duration, and they stack. If that math puts your closing start date before you thought you’d be feature complete, that’s useful information. Either the schedule needs to move or the feature set needs to shrink (and remember: adding more capacity to a late project only makes it later). Both are legitimate choices. What’s not legitimate is ignoring the math and hoping things go faster than they usually do.

The other way to think about when to start is budget. If you know your runway, you know your last possible start date and you can reverse-engineer based on your monthly burn rate. Closing with six weeks of runway left and no publisher safety net is not a plan. It’s a gamble on everything going right, which it won’t.

There’s also a third trigger, and I think it’s the hardest one to call: content sufficiency. At some point, you have to decide that the game is good enough to ship, not perfect, not the version you imagined in year one, but a complete, coherent experience that delivers on its core promise. That decision is really tough because any game can be improved in perpetuity. There will always be another feature that would make it better, another pass on the level design, another week of polish on the UI. The question isn’t whether the game could be better. It’s whether it’s good enough to ship and whether you can afford to keep going. Those are different questions, and conflating them is how teams end up in limbo.

How to start

Deciding to close is not the same as closing. The transition needs to be deliberate and socialized, or it won’t hold. Here’s what that looks like in practice.

As you slowly start nearing the end of production, bring your core leadership together, your game director, discipline leads and executive producer, and go through the backlog with one goal: determine what will and will not make it into the game. This isn’t a conversation about what would be nice to have. It’s a conversation about what’s required. Everything that isn’t a must-have goes on the chopping block. That’s a hard conversation, especially for a game director who has been nurturing this vision for two, three or more years. But it’s a necessary one. Games that don’t have this conversation tend to keep adding things because nobody ever formally said they were done adding things.

Once you have a must-have list, agree on a triage process for things that come up during closing that weren’t anticipated (and things will come up). Certification requirements change, a platform update breaks something, QA finds a bug that exposes a design gap nobody noticed. When that happens, you need a fast, clear decision-making structure. My read is that the executive producer should have the final word here, not the game director. That might feel counterintuitive, but in closing, the goal is no longer to make the best game possible. The goal is to ship the game. Those are going to be at odds with each other to some degree, and when they are, the person accountable for the schedule and the budget needs to be the one who breaks the tie.

Then talk to the whole team. Not just the leads. Everyone. Explain what closing means, what will change about how decisions get made, what they should and shouldn’t be working on, and why. You work with adults and they work better when they understand the context. They also get less frustrated when a feature they care about gets cut if they understood it was always a possibility.

The phases of closing

These phases run roughly sequentially, though in practice they overlap at the edges. The important thing isn’t the exact boundaries, but that you label them, communicate them to the team and treat each one as a rigid constraint, not a suggestion.

Feature complete and code lock. No new features. No new systems. No major changes to existing features or systems. Minor improvements, bug fixes and deliberate certification-related work only. This is the line you draw and hold. If a new feature sneaks in after code lock, you haven’t locked the code. You’ve just created the fiction of a lock, which is worse than having no lock at all because people stop trusting the process. So please don’t do that.

Content lock. No new content, whether that’s audio, visuals, levels, narrative or anything else. Minor tweaks to existing content are still permitted, but only minor. One discipline gets special treatment here: writing. If the game is localized, and especially if there are voiceovers, narrative content needs to be finished at this stage or possibly earlier, because every change downstream triggers a cascade through localization, performance capture and VO pipelines that you really don’t want to be managing in the final weeks. QA hardware compatibility testing should start around this phase.

Feature and content polish. A short phase. Very minor improvements to features, code and content code, whether to improve the experience or to meet certification requirements. Localization should be final by the end of this phase. After this phase, it’s bug fixing only.

Final stabilization. This is where most of the closing time is actually spent. The work is bug fixing, performance improvements and memory management, and it’s more constrained than it sounds. Performance work can happen in code, through asset removal or asset optimization (ensuring culling is working correctly, nothing is rendering that shouldn’t be, texture budgets are respected, etc.). Memory work is primarily code, checking for leaks, ensuring levels fit, that chain loading doesn’t accumulate memory that never gets freed. Level design can be involved at the margins here, things like world partitioning, but the changes ought to be minor.

A few specific practices that matter in stabilization:

All check-ins should be atomic. One ticket, one check-in, approved by the check-in gatekeeper before it goes into the main branch. This is a discipline thing more than a technical thing. Bundled check-ins make it very hard to isolate what introduced a new bug.

Builds should be generated as often as QA can provide coverage for them. If QA capacity is the bottleneck, it’s legitimate to involve the broader team in smoke testing and regression. Not everyone’s first instinct, but it works.

As you approach release, check-ins and builds start to track one-for-one. One check-in triggers one new build. Yes, this is slow, but we’re looking for stability. This indeed maximizes stability and makes bug attribution much cleaner when something unexpected shows up.

Release candidates. The RC phase runs in parallel with polish and stabilization. At some cadence that the game director, EP and technical director agree on (weekly, every sprint, it varies), a build is designated as a release candidate and evaluated against the gold master criteria. RCs should be getting progressively cleaner. If they’re not, that shows that something structural is wrong and you need to understand what it is before it gets worse. The gold master criteria are straightforward:

• Meets certification requirements for all target platforms

• Runs on all target hardware specs

• Runs at the target frame rate

• Fits in memory without leaking

• Stable: no showstopping bugs, no major bugs, only approved minor bugs on record

• Plays from beginning to end without breaking

When an RC meets all of those criteria, that’s your gold master and you’re ready to submit it.

New roles the closing phase needs

Closing introduces a set of responsibilities that production probably hasn’t needed up to this point. I formalize these into named roles. What doesn’t work is leaving them undefined, because someone has to own each of these functions and if it’s unclear who that is, they may not get done.

Release candidate gatekeeper (typically the game director). This person decides which builds qualify as release candidates, reviews each RC against the gold master criteria, and makes the call on when an RC is close enough to start treating as a serious candidate for submission. They’re also the person who, ruthlessly and without much sentiment, prioritizes what gets worked on in the closing sub-phases. If two bugs are fighting for the same engineer’s time, the RC gatekeeper is the tiebreaker.

Check-in gatekeeper (typically the technical director or a dedicated release manager). After code and content lock, nothing goes into the Main branch without this person’s approval. Not a bug fix, not a small optimization, nothing. Every check-in gets reviewed against what it’s supposed to fix and whether it’s safe to merge given the current state of the build. It sounds like bureaucracy, and I understand why, but a late-stage build with three engineers making three small unreviewed changes that interact badly is the kind of setback that can push a team of underslept, tired developers over the edge.

Stability gatekeeper (typically the QA lead or a senior QA person). Nobody has a better feel for the actual state of the game than the people who play it every day, across every configuration, on every target spec. The stability gatekeeper co-signs release candidates with the game director. A build doesn’t go to cert just because the game director thinks it’s ready. The QA lead has to agree. That check catches things that look fine in a creative review but not so much when you actually play the game like a player would.

Tiger team leads (optional, context-dependent). Sometimes during closing, it makes sense to spin up small focused sub-teams for specific closing tasks: level optimization passes, CRT work, platform-specific compliance fixes. If those teams exist, they need leads, and those leads need to be explicitly authorized to make tactical decisions about their area without running everything up the chain. They’re effectively doing product owner work for that specific slice of the closing effort.

It’s also a good moment to build a closing RACI chart. Not because indie teams love process documents (they don’t) but because closing introduces enough new decision points that having a clear picture of who’s responsible, accountable, consulted and informed for each one saves a lot of headaches later.

Adjusting your team structure for closing

The impulse in closing is to have everyone available, all hands, maximum coverage. In practice though, too many people in the closing phase can oftentimes create more problems than it solves. People are passionate about they game they’ve been working on for so long and they find work to do. The problem is that’s not always the work that needs to be done.

Part of the closing transition is deciding deliberately who is on the closing team and who should be redirected. Some people are genuinely needed for stabilization and cert. Others would be more valuable starting concept discovery on the next project, or working on DLC. That’s a conversation to have, not a thing to be reactive about. People who end up without clear closing tasks either go looking for tasks that aren’t on the critical path, or they disengage, and neither is great.

This is also, by the way, one of the harder management moments in a development cycle. Telling someone they’re not needed for closing can feel like a demotion, even when it isn’t. How you articulate this matters. “We need you on what comes next” has a different emotional effect than “we don’t have work for you right now.”

New ceremonies

Production syncs can also change in closing. Some meetings that weren’t on the regular calendar need to be.

Risk reviews, at minimum weekly. Start with the top risks on the register: what’s on the critical path, what’s at risk of slipping, what decisions need to be made before the next build. Short, focused, no more people than necessary. Manage forward and proactively.

Bug triage, starting weekly and shifting to daily or near-daily during stabilization. Who owns what, what’s the severity, what’s approved to ship as-is and what has to be fixed before gold. The stability gatekeeper leads this or at minimum co-leads it.

Cross-functional leadership alignment, weekly. QA lead, engineering lead, art lead, narrative lead, audio lead, production, etc. Priorities, blockers, progress against the closing criteria. Production runs this. The purpose is to catch misalignment before it becomes a bottleneck.

Changes to playtesting

By the time a game enters closing, a lot of the team has stopped playing it as a whole experience. They’re in the bug list, the cert checklist, the performance spreadsheet. That’s totally understandable, but it’s an issue.

Although you’ve probably already done this (wink, wink), as soon as the game is playable from start to finish, set up a structured playthrough cadence where the team actually plays the whole thing. Not a section, not a favorite level, not the latest build in isolation. The whole experience, beginning to end. For a level-based game, a round-robin structure works: one session covers levels zero through three, the next covers four through seven, and so on, cycling through the full game over a period of weeks. Designers should own the playtest protocols and surveys, but everyone should be participating.

This matters because bugs don’t exist in isolation. A bug that looks minor in the tracker sometimes tells you something in context about the overall experience that the tracker just doesn’t capture. And the team staying connected to the game as a game, not just as a build to be stabilized, helps maintain the judgment calls that closing requires. You can’t make good decisions about what to fix and what to ship as-is if you’ve lost your feel for the experience those decisions are affecting.

Parting thoughts

Teams that have spent two, three, four years making something find it genuinely difficult to stop. That’s not weakness. That’s what happens when people care. The game director who wants one more pass on the opening level isn’t being obstructive. They’re doing what game directors do, which is try to make the game better. The artist who wants to fix that one texture that’s been bothering them for months isn’t ignoring the lock. They just love the work. The problem isn’t that these people have bad intentions. The problem is that the closing phase requires a kind of discipline that feels like it goes against the instincts that made them good at their jobs.

Your job, whoever you are, as the person running this, is to hold the line without breaking the people. That means being clear and consistent about what the locks mean and why they exist. It means making the scope cuts in advance, not in the moment, so nobody has to watch their work get removed under pressure. It means acknowledging what didn’t make it in, not pretending the cuts weren’t real, because they are and the team knows it.

And it means being honest with yourself about what you’re willing to ship. The gold master criteria tell you when the game is technically ready. Only you can decide when it’s good enough. Those are different questions and answering them honestly, without wishful thinking in either direction, is the real work of closing a game.

If this was useful, you might also like:

The games industry is extraordinarily good at accumulating experience and extraordinarily bad at passing it on.

We have people who have shipped thirty titles, navigated a dozen studio closures, made every consequential mistake in the book and came out the other side with something genuinely hard to replicate: judgment. And most of the time, that accumulation of experience sits in one person’s head and goes nowhere. The people around them, two years in, five years in, trying to figure out how to navigate a large organization or think about a career, are largely on their own. Sitting right next to all that invaluable experience!

That’s not an accident. It’s a structural issue in our industry and the damage in opportunity-cost is herculean.

Why mentorship is so scarce in games

Three compounding reasons.

The first is the leadership problem. Game development promotes its best technical people into leadership roles they weren’t prepared for and then provides minimal support once they’re there. The best engineer becomes the lead. The best designer becomes the creative director. Someone who was excellent at an individual craft is suddenly being asked to navigate organizational complexity, manage conflict, develop other people and somehow maintain their own output, all at once, without a map. I wrote about this in more depth in my piece on leadership. The relevant point here is that leaders who are themselves struggling to find their footing aren’t exactly in a position to build the structures that help others grow. There simply isn’t the bandwidth, the experience or the organizational priority for it.

The second is how the industry has historically thought about developers. There’s a tendency, more pronounced in larger studios than in the indie space but not absent from it either, to treat developers as resources to be allocated rather than people to be invested in. Skills are hired and games are shipped. When the project ends or the studio closes, the “headcount” just moves on. You don’t build long-term development infrastructure for people you’re not planning to keep. Right?

The third is structural economics. Development cycles run one to three years, for the most part. Many studios are effectively one-title companies: if the game hits, the studio survives; if it doesn’t, it’s lights out. Average developer tenure at a single studio is about three years, give or take. When you’re operating with that kind of timeline and that kind of existential pressure, long-term investments are genuinely hard to make. Mentorship pays off over years. In an industry where you’re not sure the studio will exist in two years, that calculus is difficult.

None of this is an excuse. Think of it as a diagnosis. Understanding why mentorship is scarce is what makes the deliberate choice to do it differently actually possible.

What mentorship is and isn’t

Coaching and mentorship are used almost interchangeably by many, so let me briefly touch on that.

Coaching is primarily about performance in the present. A coach helps someone get better at something they’re already doing, through structured reflection, targeted feedback, open-ended questions and deliberate practice. It’s context-specific and discrete: when the goal is achieved or the timeframe ends, the engagement largely ends with it.

Mentorship is longer and wider. A mentor isn’t helping you get better at today’s task. They’re helping you develop judgment, which is slower, less linear and can’t be measured from one session to the next. A mentor has usually traveled some significant portion of the road you’re on and is offering something that can’t be Googled: a perspective shaped by actually having been through it. The relationship tends to be less structured, more personal, oriented toward the whole arc of someone’s development rather than a specific skill gap.

In practice the two overlap. A mentor often coaches in the moment. But the underlying orientation is different. Knowing which one a person actually needs matters. If someone needs to improve how they run sprint reviews, that’s coaching. If they’re trying to figure out what kind of leader they want to be, that’s something else.

The distinction becomes especially relevant in games because we have a lot of exceptional individual contributors being asked to grow into something much more complicated. And that transition, from craft mastery to leadership, is exactly where mentorship is most useful and most absent.

What it looks like when it works

A while back I was new to a large AAA studio: new country, new genre, live ops for the first time, a company with its own culture and politics I didn’t yet understand. I was in a genuine maelstrom of cognitive and emotional confusion. About three months in, a very seasoned leader sought me out and asked if I’d like to meet regularly to talk through how things were going. No formal setup. Just an offer.

I said yes, and that became one of the more formative professional relationships I’ve ever had.

We met every two weeks. I came with problems, endless confusion and half-formed thoughts. He asked questions, offered perspective, sometimes shared how he’d navigated something similar and sometimes didn’t. What struck me most was something he said early on and kept saying: he thanked me after most sessions. He said I’d taught him something. I assumed it was politeness at first. Then I specifically asked him about it and he said it was genuine. In a mentorship relationship, he told me, everyone learns. If you’re paying attention, the person you’re mentoring will always have something to offer you, a perspective you hadn’t considered, a question that reframes something you thought was set in stone.

That stuck with me for a long time. And it’s probably the most useful thing I can tell you about what real mentorship actually feels like from the inside: it doesn’t flow in one direction. The person with more experience brings their history and their experience. The person with less experience brings their present reality, which is always more specific and more specific than the mentor’s memory of being in a similar position. Both of those things are worth something.

The mentor who gave me that relationship was also the one who ended every session by drawing attention to something I’d made him think about. Not as performance, but because he had actually been listening. How cool is that?

How to do it well

Finding the right fit. Not everyone is a good mentor for everyone. The most useful mentors are typically one or two career stages ahead: close enough to the mentee’s situation to have specific and relevant experience, far enough to offer genuine perspective. The person who is twenty years removed from your current position and has mostly managed other managers might be interesting to talk to, but they may not be the most useful mentor for where you are right now. What you’re looking for is someone whose specific path and perspective is actually applicable to your specific situation.

Before the first real conversation, it’s worth both people being clear about what they’re hoping for. Not in a formal agenda-setting way, but genuinely: what does the mentee want from this? Is it career navigation? Help thinking through a particular leadership challenge? Clarity in a new environment? And why is the mentor doing it? What kind of engagement can they realistically give? Getting this out early prevents the disappointment of mismatched expectations six months in.

The shape of the ongoing relationship. Consistency matters. The informal version of mentorship is real but not reliable, and the things that benefit most from it, career decisions, leadership challenges, sustained development over time, require continuity. Monthly is usually enough to maintain real momentum without becoming burdensome.

The agenda belongs to the mentee, not the mentor. A mentor who arrives with their own sense of what the mentee should be working on has made it about themselves. The mentor’s job is to be a useful thinking partner for whatever the mentee brings. Here’s a useful question I’ve used before and that helped me anchor conversations: “What’s the thing you haven’t fully figured out yet?” Not the win you already understood. The thing that still has rough edges. That’s where the useful work can happen.

It’s also not a bad idea establishing occasionally what the mentee is working toward over the next few months and checking in against that. Not as performance management, mentorship is not management, but because development without any directional intent can sometimes go nowhere.

What the mentor is actually doing. The temptation is to give answers. You have experience. The person across from you doesn’t. You know things they don’t.

Resist this, or at least resist it more often than comes naturally. The goal of mentorship is the development of the mentee’s judgment, not the transfer of the mentor’s judgment. If you tell someone what to do every single time they face a decision, you’ve produced someone who makes good decisions when they have access to you. Which is a limited and fragile thing.

Something that good mentors do instead is narrate their thinking rather than just their conclusions. Not “here’s what I’d do” but “here’s what I’m noticing, here’s what I’m weighing, here’s the thing I’d want to understand better before deciding.” That’s what actually transfers. The reasoning, not the answer.

When a mentee describes something that went wrong, the first move is often to identify what they did wrong. Resist that too. “Walk me through what you were thinking” is almost always a better first question, because there’s usually context the mentor doesn’t have, constraints that weren’t visible, choices that made complete sense given what the person knew at the time.

Be honest about your own failures. This is where the relationship either develops real depth or stays politely superficial. A mentor who only presents their wins is not that useful. The mentee is going to fail in ways that feel specific and personal to them. The most useful thing a mentor can do when that happens is demonstrate, through their own history, that failure is a normal part of the development arc and not evidence of fundamental unsuitability. Share the times you got it wrong. Specifically. Without making it a parable with some tidy moral attached to it.

If you’re the mentee. Most advice about mentorship addresses the mentor. The mentee usually gets a few lines about being receptive and showing gratitude. That’s a significant imbalance, given that the mentee’s behavior is at least as determinative of whether the relationship actually works.

The people who benefit most from mentorship are almost never the ones who waited for it to be offered.

They’re the ones who were proactive, who sought out the people they wanted to learn from and made those conversations worth having. When approaching someone, be specific about what you’re asking for. Not “would you be my mentor” (a large vague commitment most people will accept awkwardly and not know how to execute) but something more like: “I’m working through some career challenges and I’d value your perspective. Could we find an hour?” That’s a more concrete ask. If it develops into something ongoing, great.

Come prepared. Know what you’re bringing before you show up. Reflect on the last period since you last spoke: what happened, what you noticed, what you’re still unsure about. The mentee who arrives without having thought about any of this is essentially asking the mentor to do both sides of the work.

And do what you discussed. If a conversation produces a clear next action, take it and come back with an honest account of how it went. The mentor’s investment compounds when they see their input being acted on. When it repeatedly isn’t, the engagement inevitably starts to lose momentum.

One more thing: you don’t need to rely on just one. A single mentor has a single perspective, shaped by a specific career path. That’s valuable, but it’s seldom the whole picture. Over time, develop a small set of people whose experience and judgment you trust in different domains. Someone who knows the production side, someone who knows the creative side, someone who’s built a company. You’re building a board of advisors for your career, not installing a single authority.

A note for studio founders

If you’re building a studio, there’s something particularly relevant to you, that’s not just about your own development, that you should bear in mind.

The culture you establish early, how decisions get made, how failure is handled, how people are developed, sets much, much faster than you expect. By the time you have fifteen people, a lot of those patterns are already fixed. Mentorship, or its absence, is one of them.

A studio where experienced people invest seriously in developing less experienced people creates something that compounds: people grow faster, contribute more meaningfully sooner and stay longer. And eventually the people who were mentored become the people who mentor. The investment doesn’t just pay off once. It replicates.

A CNBC/SurveyMonkey survey of nearly 8,000 workers found that 91% of those with a mentor were satisfied with their jobs, while more than 4 in 10 without one had considered quitting in the previous three months. A macro analysis from Mentorloop shows that there’s a 72% retention for mentees vs. 49% for non-participants. The benefits are demonstrable and substantial.

None of this doesn’t require a formal program. It requires a cultural expectation, implicit or explicit, that experienced people share what they know, that questions are welcome, that the development of other people is part of the job rather than a distraction from it.

I’ve seen studios where that expectation existed. You could feel it in how conversations worked, in the questions people weren’t afraid to ask in front of others, in how junior developers talked about their leads, etc. And I’ve seen studios where it didn’t, where knowledge was hoarded or shared reluctantly, where seniority was a position to defend rather than a resource to distribute. The difference in velocity, morale and what the team was able to accomplish was not subtle, let me tell you.

When I look back at my career in this industry, the clearest influence I can trace in how I think and work isn't the studios, or the games, or the processes. It's the people who took time with me. Who asked questions when I expected answers. Who shared failures alongside the wins and didn’t make a big deal out of doing any of it.

Being that person for someone, even once, is not a small thing.

If this was useful, you might also like:

I’ve been on both sides of the conversation: the producer asking “what does it take to get promoted around here?”, and the manager awkwardly trying to articulate why someone who is technically very capable... isn’t quite there yet. It’s a frustrating conversation to have, for everyone involved, because the games industry does a pretty poor job of defining what “good looks like” at any given point in the production career.

So let me try to do that. Not as a formal rubric, certainly not as a checklist, but as an honest description of what I’ve seen work, what I’ve seen not work and some of the lessons I picked up along the way in trying to help clarify progression for producers.

What a producer actually is

A producer’s job is to create the conditions in which a team can make their best game. Not to coordinate tasks, not to run meetings, not to be the person who knows where everything is in Jira. Those things might be part of the work, but they are not the work itself.

Producers manage forward. What that means is that they see where the production is heading before everyone else does. Not in some oracle-like way, but just by paying attention: where is risk accumulating, what decisions have been deferred past the point of safety, what team dynamic is progressively degrading. They manage the space between people, the gaps in communication, the unspoken tensions, the creative alignment that tends to drift when no one is actively working to maintain it. And they manage clarity, making sure the team knows what they’re building, why, what phase they’re in and what success looks like right now.

It took me years to really understand that production is not fundamentally a coordination problem but a people problem. The spreadsheet is not the job. The people filling it in are actually the job. If you confuse those two things, you’re already on the wrong path.

On the producer / product manager distinction: this typically comes up in larger studios, mobile studios and anything built around live services. A product manager, broadly speaking, owns the “what”: the product vision, the feature roadmap, what gets built and in what order, grounded in player behavior data and business objectives. A producer typically owns the “how”: the execution, the team, the health of the production day to day. In very simple terms, you want a product manager asking whether you’re building the right thing, and you want a producer asking whether you’re building the thing right, and increasingly, whether the people building it have what they need to do it well.

That last part is easy to lose sight of early on because studios tend to ask for the coordination work first and loudest: the Jira board, the milestone tracking, the status reports, clear processes, sensible artifacts. It satisfies a kind of organizational anxiety in a way that people work doesn’t. Human dynamics are also just harder than process systems and the instincts take longer to develop. So most producers start by getting good at what’s asked of them most visibly and they stay there perhaps longer than they should. There’s nothing wrong with being rigorous about processes. There’s something wrong with mistaking it for the real job.

On title inconsistency: "producer" is the most common title for the role, but it's not universal. In some studios, particularly larger ones with technology or platform roots, you'll see "program manager" or "development director" doing essentially the same work. Some studios use "project manager." The titles vary enough that when you're evaluating a job posting or a resume, it's worth reading the actual responsibilities rather than anchoring on the title. What I'm describing here applies regardless of what it's called.

The levels and what they actually mean

Most studios have this progression in some shape or form: associate, mid-level, senior, lead or principal, director, and somewhere above that, executive producer or VP. Larger studios often have more steps: a “staff” level between senior and lead, or an “associate director” between lead and director. That additional granularity is typical for organizations where clear level distinction matters for compensation bands and organizational design. It’s not always meaningful in practice. Whether your studio has four levels or seven, the underlying shape of the progression is the same.

What's less consistent is what each level actually requires in terms of demonstrated capability and experience. I've seen "senior producer" mean three years in the industry and no shipped titles, and I've seen the same title mean a decade of complex project experience and real P&L exposure. Read the responsibilities, not the label.

There’s also a somewhat meaningful fork that opens at the lead or principal level, but only in larger studios. More on that below.

Associate producer

This is the entry point and the job at this level is deceptively simple: find mentorship, learn to do the coordination work well, foster visibility as much as possible, develop instincts for where things are drifting and begin to understand the studio, team and game deeply enough to make useful contributions to the conversations that matter.

In practice, an associate producer is typically supporting one team or one content area within a larger production. They own a slice of the backlog, run standups, track dependencies, flag blockers, and write meeting notes that are hopefully useful. The scope is narrow and the stakes are contained. That’s by design. The priority at this level is building foundational habits: rigor in tracking, discipline in follow-through, early development of that sense that something is about to go wrong before it does.

What differentiates a strong associate from an average one is not how clean their Jira board is but whether they’re starting to read the room. Do they notice when a developer’s energy has shifted? Do they bring problems with a proposed path forward rather than just flagging that there’s a problem? Are they curious about the game beyond their immediate slice of it?

In a corporate environment, an associate producer usually has a clear manager, structured onboarding and regular feedback. In a small indie studio, the same person might be doing administrative coordination, scheduling, QA facilitation and a slice of game design simultaneously, with minimal guidance. Both are valid, but the indie version requires more self-direction earlier and the margin for confusion about what the job is tends to be higher.

Typical experience at this level: zero to three years in the industry. Often the first professional production role, sometimes a transition from another discipline. Scrum Master certification is common and mildly useful. More useful is any experience organizing complex work with other people under time pressure, as well as a solid mentorship relationship.

Mid-level producer

The jump from associate to mid-level is largely about independence. A mid-level producer owns a meaningful production area without needing significant oversight to do it well. They can run a small team’s production end-to-end: milestone planning, sprint structure, risk management, stakeholder updates, etc. They’re starting to have real opinions about what the work systems should look like and those opinions are occasionally right.

At this level, the producer is typically interfacing with discipline leads (design, engineering, art) on a daily basis. This is where interpersonal skills start to visibly differentiate people. A mid-level producer who can build genuine trust with technical and creative leads is dramatically more effective than one who can’t, even if the less trusted producer has more polished “process skills”.

The mistake I see most at this level is a producer who has gotten very good at the visible work (clean board, timely reports, milestone dates tracked with precision, all that), and underneath that, a team that's slowly falling apart, a lead burning out, a developer who's lost the thread, a director who still doesn't know the scope won't fit. The process looks healthy on paper. The people are not.

At mid-level, the work is starting to ask you to care about which one is actually true, and to have the conversations the process can’t have for you. Those conversations are uncomfortable. Developing the willingness to have them, at this level, is a very large part of the job.

In indie studios, a mid-level producer at a ten-person shop might be the only dedicated production person on the team. Which means they’re also doing some of what a senior producer does in a larger studio: interfacing with external partners, contributing to milestone planning across the full project, supporting leadership decisions. The title doesn’t change. The scope does.

Typical experience: three to six years, more or less. One or two shipped titles, or meaningful live operations experience. Beginning to develop a production philosophy rather than just production habits.

Senior producer

This is where the work starts to substantially change. A senior producer is no longer primarily about execution within a defined area. They’re increasingly about judgment, risk management, organizational influence and leadership.

In a larger studio, a senior producer is typically running end-to-end production for a significant feature team or an entire module of a game. They’re managing producers below them and partnering as peers with discipline directors. They own their production area’s success with real accountability, which means they’re not just flagging when things are at risk but actively doing something about it: reprioritizing, renegotiating scope, realigning teams, collaboratively making hard calls about what gets cut and what gets protected.

The decision quality here starts to matter in a different way. A senior producer is being called on to make judgment calls with incomplete information, usually with meaningful downstream consequences. They’re the ones sitting in the room when scope has to be negotiated, when a feature has to get cut close to launch, when a team is in conflict and someone has to verbalize what’s actually happening. The ability to read a room, hold their own in those conversations and stay calm when the situation is genuinely difficult. That’s what separates senior producers who advance from senior producers who don’t.

External partnerships also start to appear in scope at this level. Third-party vendors, outsourcing partners, co-development studios, platform relationships. A senior producer needs to be able to manage dependencies that don’t run through the internal org chart.

At the senior level, most producers begin to encounter leadership in a more intentional way, even if it doesn't fully land yet. Some of it comes from proximity: working closely with a director or studio head who models something different from what they've seen before, someone who leads with context rather than directives, who makes decisions and elicits something in people in a way that's worth studying. Some of it comes from formal exposure: a leadership training program, a recommended book, a conversation with a mentor that reframes something they'd been doing on instinct.

What often starts to crystallize at this stage is a distinction between management and leadership, that managing is about the work and the systems, and leading is about the people and the direction, and that being good at one doesn't automatically make you good at the other. A senior producer who is technically excellent at running a production can still struggle to inspire trust, hold a team through uncertainty, or build genuine followership. That gap doesn't always become visible until the senior producer is asked to lead other producers or step into a higher-stakes organizational moment. But the good ones start sensing it earlier, not necessarily reading Kouzes and Posner or Brené Brown cover to cover, but developing a sort of awareness that the next phase of the career is going to demand something different from them than the current one does.

In an indie context, a senior producer at a small studio often has some version of executive responsibility by default. There’s no one above them in production. That can accelerate development if the person is genuinely capable, or create a dangerous gap if they’re being given a senior title they haven’t fully grown into yet. I’ve seen both, and the gap tends to show up around crunch time when the production decisions have real consequences.

Typical experience: six to ten years, with meaningful variation by studio. Has experienced at least one significant full production lifecycle, ideally also including post-release. And has managed others, even informally.

Lead and principal producer: the fork

At the lead or principal level, in studios large enough to have this distinction, there’s a somewhat meaningful split in career path.

A lead producer is primarily a people leader. They’re managing a team of producers, setting standards for how production is done across that team, coaching junior and mid-level producers, handling performance conversations and operating as a production leader at the organizational level. Their leverage comes from making other producers (and other developers) more effective. The best lead producers I’ve worked with had a particular quality that’s hard to put into words but easy to recognize: they made everyone around them better without making themselves the center of everything.

A principal producer is more of a craft or technical leader. They’re the person who defines what great production looks like, sets the methodology and process standards for the studio, consults on the hardest production problems and brings depth of expertise rather than width of management. They’re often the person a director calls when a production is struggling and they need someone who can diagnose what’s actually wrong. They don’t necessarily manage a large team of producers, but their influence on how production runs across the studio is significant.

The Venn diagram of those two roles is, quite frankly, enormous. Most people operating at this level are doing a mix of both things. The distinction matters more as a signal of developmental trajectory than as a rigid job description: where do you want to grow from here? Toward broader organizational leadership or toward deeper craft mastery? Both paths are legitimate and oftentimes mirrored in other game development disciplines (where they arguably make more sense than in production). Not everyone needs to manage people to have a meaningful senior career in production.

This split mostly exists in larger studios. In a twenty-person indie studio, there’s one senior production person and they’re doing all of it.

At the lead level, that quiet leadership awareness developed over the past few years becomes something more active. The producer is now responsible for other producers (their development, their performance, their growth) and that accountability has a way of forcing the questions that were easy to defer at the senior level. You can't lead a team of producers without developing a real point of view on what good leadership actually looks like, because they're going to reflect whatever you model for them, good and bad.

The abstract understanding that leadership and management are different things starts to show up in concrete daily decisions: how you run a one-on-one, how you give feedback that lands without shutting someone down, how you hold someone accountable while keeping the relationship intact. Many lead producers at this stage become more deliberate about the learning itself, reading more intentionally, seeking out mentors with genuine leadership depth, reflecting on their own patterns in a way that goes beyond professional performance. The frameworks that felt like theory at the senior level start to feel applicable, because now there's a specific person or situation to map them onto. And there's usually at least one hard moment (a producer on the team who isn't growing, a conflict that requires real courage to address, a situation where the technically correct production call and the right leadership call are not necessarily the same thing) that does more to internalize the lesson than any book or training ever could.

Typical experience: ten or more years. Has shaped how production works at an organizational level, not just within a team. Has navigated at least one genuinely hard production situation (a project in trouble, a team falling apart, a major scope crisis) and come out the other side with something to show for it.

Director and executive producer

This is where the scope becomes organizational rather than project-specific. A production director or EP is accountable for the delivery health of a full game or a studio’s full slate. They’re operating at the strategy layer - profit & loss statements, portfolio planning, go-to-market, organizational design, executive alignment, greenlight and cancellation decisions - while simultaneously staying close enough to the production reality to know when something is actually in trouble.

The stakeholder map also changes substantially. A director or EP is regularly in conversation with the publisher, platform holders, investors, creative executives, the board, external partners. They’re not managing the day-to-day anymore. They’re managing the conditions under which the day-to-day can succeed.

Hiring becomes a core responsibility at this level in a way it isn’t at lower levels. An EP who can’t build a great team and develop a strong production leadership bench will eventually hit a ceiling regardless of their individual capability. The output is the team. The judgment that matters most is often about people: who to bet on, who needs support, who is in the wrong role, and what the organization needs in order to do its best work.

Budget ownership is real at this level. P&L literacy is not optional. Not because an EP needs to be a CFO, but because decisions about scope, staffing, milestone timing, project health and release window have very real financial consequences.

What I didn’t fully understand until I was actually operating at this level is how much of the job is holding organizational stability when things are truly tough. Productions that are genuinely at risk generate a kind of organizational anxiety that is contagious. An EP who can’t stay grounded in that environment and project reasonable confidence without pretending everything is fine... well, the team picks that up immediately. It changes how they work, often for the worse.

At the EP level, leadership is no longer a competency you're developing but the primary medium through which you do your job. The game doesn't get made by your hands. It gets made by the culture you've built, the leaders you've grown, the standards you've modeled and the judgment you've brought to every hard decision people watched you make.

That cascading effect is real and it runs in both directions: an EP who leads well creates conditions where good producers become great ones, where the team feels safe enough to raise problems early, where the studio develops a kind of institutional resilience that outlasts any single project. An EP who leads poorly, who is technically excellent but emotionally unavailable or who optimizes for delivery at the expense of people, tends to produce studios that perform in the short term and slowly hollow out over time. By this point, the work of leadership is less about learning new frameworks and more about continued self-awareness, about knowing your own patterns well enough to catch the moments where your instincts might be working against the people depending on you.

In the indie space, an executive producer at a fifteen-person studio is often also doing some mix of COO, studio director and technical coordinator depending on what the team needs and what the gaps are. The title reflects seniority and scope of accountability. The specific work adapts to the context.

Progressing deliberately

So many producers I’ve known, especially early in their careers, approached progression the way you approach a performance review: do the job, get the feedback, hopefully advance. That’s passive and it works slowly and inconsistently.

The producers I’ve seen develop fastest, and who helped their direct reports develop fastest, had a different orientation. They thought about what great looked like at the next level before they were there and they pursued the specific experiences and competencies that would close that gap. Not abstractly, not just by reading books, but by deliberately seeking the situations that would require them to grow.

That means asking for the uncomfortable assignment, the production that’s in trouble, the team with the dynamics problem, the milestone no one thinks can be hit. It means working with leads and executives who are better than you at the things you’re trying to develop and paying real attention to how they operate. It means retrospectives on your own decisions, not just the project’s: where did your judgment fail, what did you not see coming, what would you do differently?

It also means being honest about which competencies are actually weak. Most producers have strong process skills. Fewer have strong people skills. Fewer still have strong strategic thinking skills: the ability to see where the organization is heading, what decisions need to be made at the portfolio level, how the current production maps onto the studio’s long-term health. That last one typically only develops through exposure to executive conversations, and it’s worth seeking that exposure earlier than most people do.

The “framework lite” I’d leave you with is this:

1. Know what good looks like at the next level in terms of competencies, experience and behaviors

2. Align with your manager on that

3. Close the gap in a concerted manner

4. When you get there, reset the horizon

If this was useful, you might also like:

Heads up: this is another long primer. Management is complex, multifaceted, and you can spend a lifetime improving this vector. So we cover a lot of ground.

A founder, maybe a year into their first project, tells me they are frustrated with someone on their team. The person is talented, maybe genuinely brilliant at what they do, but they keep missing expectations, or something about how they’re working is creating some frustration, or they seem checked out in a way that wasn’t there six months ago.

So I ask the founder: have you told them?

And there’s a pause.

“I mean... I think they know.”

No, they don’t know. Or they know something is wrong but not what or how seriously. And the founder doesn’t know how to begin that conversation, so they keep hoping the problem will resolve itself, or that the work will just sort it out, or that things will improve once the next milestone pressure kicks in.

They almost never do.

Managing people is the craft most technical founders have least training in and most need. Not because developers and artists and designers are difficult people, they’re generally not, but because managing creative, intrinsically motivated professionals under consistent production pressure is really hard. It requires a specific set of skills that don’t come automatically from being good at your craft, or from being smart, or from caring a lot about what you’re building.

This article is about those skills.

Leadership vs. management

These words get used interchangeably and that’s a problem because they describe different behaviors and activities that require different things from you.

Leadership is about direction: setting a compelling vision, creating meaning and purpose, inspiring people to commit to something beyond the immediate task. It operates in the space of “why” and “where.” At its best, leadership makes people want to do the work.

Management is about execution: creating the conditions, structures and habits that allow people to deliver on that vision reliably, over time, under real-world constraints. It operates in the space of “how” and “who” and “by when.” At its best, management makes the work actually happen.

A studio with great vision and weak management will struggle to translate that vision into a shipped game. And a studio with good management but no compelling vision will produce competent work that nobody, including the team, is particularly moved by. So you need both.

In practice, you’ll switch between these modes constantly, sometimes within the same conversation. Understanding the distinction helps you notice which mode a situation calls for, instead of defaulting to whichever one is more comfortable for you.

Why this matters and the research behind it

Before I get practical, I want to establish something important that the data actually supports: the quality of people management is one of the most significant variables in team performance, satisfaction and retention. Not “a” variable but one of the most significant ones.

In 2009, Google launched what became known as Project Oxygen, an internal research initiative to understand what separated their best managers from their worst. They analyzed more than ten thousand data points from performance reviews, feedback surveys and interviews, looking for patterns. What they found changed how they think about management entirely.

They expected technical expertise to top the list. It came last.

The behaviors that most distinguished high-performing managers were things like being a good coach, giving clear and regular feedback, taking genuine interest in team members’ development and lives, communicating a clear vision and creating the conditions for people to do their best work without micromanaging every decision. Stuff that sounds, when you list it out, almost embarrassingly obvious. But obvious and practiced are very different things.

The implications for indie game development are quite clear. You probably have a small team, which means each individual manager (which in many cases means you, the founder) has an outsized effect on how every person on that team feels about their work, how much they grow, how long they stay and whether the studio becomes the thing you envisioned. The same research found that managers had a greater impact on performance and wellbeing than almost any other organizational factor. That is a lot of leverage, in both directions.

Getting to actually, truly know your people

This one sounds so basic that people skip it, which is sadly a big mistake.

You cannot manage people effectively as abstractions. “The programmer” or “the artist” or “the narrative lead”, those are roles. The person in the role is someone with a specific history, specific motivators, specific fears, specific things that make them feel seen and specific things that make them want to quit. Managing the role is not the same as managing the person.

In my experience, the investment of genuinely understanding each person on your team pays off in proportion to how hard that seems upfront. Some of the most important things I’ve learned about people on my teams came from a conversation in a hallway, or a one-on-one that went in an unexpected direction or a question that came up organically breaking bread together.

These are some of the questions that I think are worth asking at different points in your relationship with someone:

• What drew them to this kind of work in the first place? Not this job specifically, but this field, this discipline?

• What does success look like for them, not just for the project, but for their career, their growth as a professional?

• What do they find energizing in their work and what drains them?

• What kind of feedback do they find most useful and what lands badly?

• What’s their preferred working style? Do they want to be checked in with often or does that feel like being watched?

You don’t ask all of this at once and you don’t need a formal framework to do it. The point is to build a real picture of who you’re working with, over time, through consistent and genuine attention.

Stephen Covey’s fifth habit, seek first to understand, then to be understood, gets at something very real. Most people in positions of authority listen to respond, not to understand. They’re already formulating their answer while the other person is still talking. The managers I’ve seen do this best, and from whom I’ve learned most, are the ones who are genuinely, truly curious about what the people around them are thinking and experiencing.

Communication

As hippie as this may sound: clarity is kindness. Ambiguity in communication is one of the most reliable sources of friction and rework I’ve ever seen in game development. People can spend days going in a direction that wasn’t intended, teams can duplicate work because nobody established ownership, maybe someone misunderstands the scope of a task and builds something twice as elaborate as what was needed. You’ve seen it happen.

Most of this is preventable. Not by writing longer documents or holding more meetings but by developing the discipline of communicating with genuine precision about what matters.

These are a few things that I’ve come to believe are non-negotiable:

Articulate the “why” not just the “what.” When you give someone a task without context, they have to infer the purpose. Their inference might be right or it might produce something technically correct but contextually wrong. “Can you update the combat system to feel slower and heavier” is a task. “We’ve been getting feedback that combat feels arcade-y, and we want it to feel more like a deliberate fight: slower, weightier, with more commitment on each move” is a task with enough context that the person can make good (or at least better) decisions you didn’t anticipate. This is why I like user stories, by the way.

Confirm understanding explicitly. Don’t assume that sending a message equals it being received and processed the way you intended. With important direction, especially direction about scope or priorities, build in a step where you ask the person to reflect back what they understood. Not in a condescending way, of course, but it’s genuinely surprising how often a two-minute conversation reveals a meaningful misunderstanding.

Match the format to the content. Sensitive conversations belong in person or on video, not in Slack. Quick status updates don’t need meetings. Technical constraints on major creative decisions probably warrant a written summary that everyone can reference. Learning which format is right for which conversation sounds simple; getting it consistently right takes practice.

Active listening

People say “active listening” like it’s a technique, something you can put on a checklist. It’s actually not. It’s a disposition, a commitment to actually listen to what someone is saying, rather than waiting for your turn to speak.

Kerry Patterson and colleagues wrote extensively about this in Crucial Conversations, a book I’d put on the short list of genuinely useful management reading. Their framing is that high-stakes conversations, the ones where emotions are running high, where there’s significant disagreement, where something real is at risk, tend to go badly because people shift into a mode of advocating for their own position rather than genuinely trying to understand the other person’s reality. Active listening is the discipline of resisting that shift.

Douglas Stone’s Difficult Conversations covers similar ground, with a particularly useful observation: most difficult conversations are actually three conversations happening simultaneously. There’s the “what happened” conversation (who did what, who said what). There’s the feelings conversation (what emotions are underneath this). And there’s the identity conversation (what this says about me as a person, my competence, my worth). Recognizing which conversation you’re actually in, and which one the other person needs to have, changes how you engage.

In practice, active listening means things like: letting people finish before you respond, asking clarifying questions that demonstrate genuine curiosity, reflecting back what you heard to check your understanding, sitting with discomfort when someone says something hard, rather than immediately deflecting or defending.

One specific technique that I like is a question Michael Bungay Stanier centers his work around. It’s: “And what else?” It sounds almost too simple, but asking it after someone’s first answer creates space for the more honest, more considered response that usually wasn’t in the first thing they said. The first answer is often the safe one. “And what else?” is how you get to the real thing. Try it and let me know how it goes.

Setting expectations

The gap between what a manager expects and what a team member understands is one of the most expensive gaps in any studio. It produces rework, it damages trust, it creates frustration on both sides, and it almost always comes down to expectations that were never made explicit in the first place.

The problem is that managers often operate from an implicit mental model of what “good” looks like and they assume their team shares it. They frequently don’t.

Two frameworks that can be useful. First: SMART goals - Specific, Measurable, Achievable, Relevant, Time-bound - are a useful forcing function for translating vague expectations into concrete ones. Not every expectation needs this level of structure, but for anything meaningful, applying even a few of these criteria makes the goal significantly clearer. “I want the combat to feel better” is not a goal. “I want to have a playable combat prototype that our team playtests and rates significantly higher on ‘impact satisfaction’ than the current build, by end of sprint” is something that you may or may not agree with, but you can actually work toward.

Second: OKRs (Objectives and Key Results), which operate at a slightly higher level and are particularly useful for connecting individual work to studio-level goals. The objective is a qualitative statement of direction (”Make our game feel distinctive in the crowded action-RPG space”). The key results are measurable outcomes that would tell you whether you’d achieved the objective (”Three external playtesters spontaneously mention the aesthetic as a reason they’d recommend the game”). The power of OKRs is that they separate what you want to accomplish from how you’ll know you’ve accomplished it, which is a distinction people blur constantly.

In game development specifically, setting clear expectations is complicated by the fact that a lot of the work is genuinely open-ended and creative. You can’t SMART-goal your way through concept discovery. The answer isn’t to abandon expectation-setting in creative phases; it’s to set expectations about the process rather than just the output. What should we know by the end of this sprint? What hypotheses are we testing? What makes this two-week period successful?

Blanchard’s Situational Leadership model is worth applying here too, though I won’t go deep into it (I wrote about it before). The short version is that the right level of directive guidance depends on the competence and confidence of the person you’re managing in a specific context. A new developer doing a type of task they’ve never done before needs more explicit direction than a ten-year veteran tackling something in their wheelhouse. Calibrating your approach to the person and the situation, rather than applying a uniform management style, is something the best managers I’ve worked with do almost unconsciously.

One-on-ones

If you do one thing from this article, make it this: hold regular, dedicated one-on-ones with every person who reports to you. Not ad-hoc catch-ups when you happen to be near each other. Not the five minutes at the end of a standup. Recurring, protected, uninterruptible time with each person.

Google’s research found that their highest-rated managers were significantly more likely to hold consistent one-on-ones than their lowest-rated ones. This is not correlation. The mechanism is quite direct: regular one-on-ones create a consistent forum for the things that don’t naturally surface in group settings, like career concerns, interpersonal friction, early signs of burnout, confusion about direction or ideas someone was hesitant to raise in front of the full team.

Without this forum, those things accumulate in silence until they become something much harder to address.

Let me share a few principles I’ve found contextually reliable:

• The one-on-one belongs to them, not to you. It’s not a status update meeting or a progress check. If that’s all you do, you’re using the time for management convenience, not for what it’s actually for. Start with their agenda, not yours.

• Show up prepared and expect them to as well. A shared document where both sides add topics before the meeting is a simple and effective practice. It signals that the conversation matters and gives both parties time to think.

• Thirty to sixty minutes, every couple of weeks. The cadence matters. Too infrequent and you lose the continuity that makes these conversations accumulate into something meaningful.

• Always end with a direct question about your own management: “Is there anything you wish I was doing differently or something I could do more or less of to help you?” This question is harder to ask than it sounds, because you might not love the answer. Ask it anyway.

One more thing. If you’re managing someone through a difficult period (a stretch of underperformance, or personal difficulty or a creative block) the one-on-one is not just valuable but irreplaceable. It is the venue in which trust is built slowly, incrementally, through consistent presence and genuine human attention.

Feedback

If you ask me, almost everyone in game development is uncomfortable giving direct, specific, honest feedback. This is especially true in creative disciplines, where the work feels personal, where the line between “this isn’t working” and “you aren’t working” is easy to cross accidentally.

The consequence is that people give feedback too rarely, too vaguely, too positively or in ways that obscure the actual message, and then feel frustrated when nothing changes.

The framework I’ve relied on most consistently (and that I’ve also written about earlier) is SBI, developed by the Center for Creative Leadership: Situation, Behavior, Impact. The idea is straightforward. Describe the specific situation in which the behavior occurred. Describe the actual, observable behavior (not your interpretation of it, not a judgment about the person, just what happened), and describe the impact that behavior had.

“In yesterday’s milestone review, when you interrupted the game director while they were presenting the design rationale to the publisher, it made the director visibly uncomfortable and I think it undermined the confidence of our presentation”: this is SBI. “You’re dismissive of leadership in group settings”: this is an interpretation, a character judgment, and it will make the other person defensive before you’ve even started.

What I’ve added to SBI over the years is an extension that I believe matters a lot: after delivering the feedback, pause. Ask a genuine question about intent. “I wanted to share that with you and I’m also curious what was happening for you in that moment. What were you trying to accomplish? What’s your interpretation of this feedback? What’s your sense of things?” Then listen. Don’t fill the silence. Don’t soften or walk back what you said. Just listen.

This extension does two things. It demonstrates that the feedback is a conversation, not a verdict. And it often reveals something you didn’t know: a misunderstanding, a context that shifts your read of the situation or simply the other person’s experience of a moment you interpreted very differently. Neither of you has the full picture. You learn more when you ask.

The same discipline applies to positive feedback, which people routinely underestimate. Recognition that is specific, timely and connected to impact: “the way you handled the physics edge case in the climbing system solved a very real problem we’d been stuck on for two sprints, and it did it without introducing the performance issue we were so worried about” is dramatically more motivating than “great work this week.” It tells the person what specifically they did well and why it mattered, which helps them do it again.

On receiving feedback: this is equally important and significantly less discussed. The practice I’d encourage is simple. When someone gives you feedback, your first job is to understand it, not to assess whether you agree with it. Ask clarifying questions. Reflect back what you heard. Thank them for raising it, regardless of whether you ultimately agree with their read. A manager who visibly receives feedback well, without defensiveness, without minimizing, signals to the entire team that feedback is safe, and that signal matters enormously.

Coaching

There is a flavor of management that essentially means answering every question your team brings to you, solving every problem, making every decision. Managers who operate this way are usually busy, often proud of how needed they are, and building teams that can’t function without them. Which is not a compliment.

Coaching is the alternative. The shift is from “tell” to “ask”, from being the answer to being the question that helps someone find their own answer.

John Whitmore’s GROW model gives this a shape: you move through Goal (what does the person want to achieve?), Reality (what’s actually happening right now, honestly?), Options (what could they do?) and Will (what specifically will they do, and when?). The role of the manager or coach in this sequence is to ask good questions and listen carefully, not to provide the solution.

Michael Bungay Stanier’s The Coaching Habit makes this more practical with seven specific questions worth internalizing:

1. “What’s on your mind?” to open

2. “And what else?” to get past the first answer

3. “What’s the real challenge here for you?” to focus on what actually matters

4. “What do you want?” to surface what they’re actually asking for

5. “How can I help?” to make the request explicit

6. “If you’re saying yes to this, what are you saying no to?” to surface tradeoffs

7. “What was most useful for you?” to close in a way that locks in learning.

The practice of coaching is simple to describe and difficult to build as a habit, precisely because giving answers is faster and more immediately satisfying. You know the answer, so why spend twenty minutes helping someone find it themselves when you could just tell them in two? Because two years from now, the person who developed the habit of solving problems through reflection is worth ten times more to your studio than the person who learned to wait for you to tell them what to do.

Google’s research found that the single most important behavior of their highest-rated managers was being a good coach. Not technical expertise. Not results orientation. Coaching.

I’ve seen this play out across different studios in different configurations. The directors, leads and producers who ask questions tend to have teams that are more autonomous, more confident, more creative and more likely to surface problems early, because surfacing a problem feels like bringing a thought rather than admitting a failure. The managers who answer every question tend to have teams that are more dependent, less confident and quieter because the implicit message is that the manager knows best, and disagreeing takes courage most people don’t necessarily have in abundance.

Delegation and empowerment

Delegation is not just task assignment. It’s an intentional transfer of ownership, of a task, a decision, a domain, with the expectation that the other person has what they need to succeed and the authority to actually follow through.

The difference between real delegation and fake delegation is this: in fake delegation, you hand off the task but retain the decision. You check in constantly, you override the person’s choices, and ultimately you give them the work but not the power. This is not delegation. It’s just distributed execution, and it is exhausting for both of you.

Real delegation means asking yourself, for a given decision or task: does this actually need to be me? If someone on my team could own this with the right context and authority, should I let them? The answer is yes far, far more often than you think or feels comfortable, especially if you’re a founder who built this thing and has opinions about every pixel.

A few practical things to get delegation right:

• Be explicit about authority. Not “can you handle this” but “you have full authority to make this call, I don’t need to be consulted before you decide, and you don’t need my approval to move forward.” The ambiguity around how much authority someone actually has is one of the most common sources of unnecessary check-ins and second-guessing.

• Set up for success, not just hand off. Delegation without context is just abdication. Make sure the person understands the goal, the constraints, the stakeholders they’ll need to engage and what success looks like.

• Follow up without micromanaging. There’s a meaningful difference between “I’m going to check in on Tuesday to see how this is going” and “send me an update every hour.” The first is support, the second sends a message that you don’t actually trust them.

The payoff of getting this right (beyond the obvious benefit of freeing your own time) is the development of the person you’re delegating to. Every ownership opportunity is a growth opportunity. And in a small studio, growing the capabilities of every person on your team is a pretty high leverage thing you can do.

Conflict resolution

I have a full article in the works about conflict resolution, but let me touch on this briefly.

I’m yet to see conflict in a game studio get better by being ignored. I’ve seen a lot of conflicts that got dramatically worse over months of avoidance, until what was originally a disagreement about a design decision had calcified into something much harder to address: entrenched resentment, factional dynamics, people who can barely be in the same room.

The pattern is typically in the lines of: two people have different views about something, instead of resolving it directly, they route around each other, or complain to third parties, or just quietly decide to stop engaging. The original disagreement grows a whole narrative around it, the narrative grows emotional weight, and by the time someone decides the conflict needs to be addressed, it’s carrying months of accumulated meaning that has almost nothing to do with whatever the original issue was.

The intervention I’ve personally found most useful is straightforward: create a structured conversation between the parties, sooner than you think is necessary. Not to determine who was right, but to create a context in which both people can express what they’re experiencing and be genuinely heard by the other.

The skills this requires are active listening and the discipline not to take sides. You’re not there to solve the conflict for them, but to facilitate a conversation in which the conflict can begin to resolve itself, which it usually can, once both parties feel genuinely heard by the other rather than just by their respective allies.

A couple of practical things that help:

• Separate the people from the problem. Frame the conflict as a shared problem to be solved, not a dispute to be won. “We have a situation where these two people are working together and communication has broken down, so how do we fix that?” rather than “one of you is doing something wrong.”

• Go to each party individually first. Hear their read of the situation without the other person present. This allows you to understand both perspectives before bringing the parties together, and it gives each person a chance to be heard without the defensive escalation that often happens when both parties are in the room from the start.

Don’t let it sit. The longer conflict remains unaddressed, the more it costs, in energy, in team trust, in the psychological safety that every other practice in this article depends on.

Handling failure

Every game project fails in some dimension, in some part of its development. Features get cut, milestones slip, something that seemed obvious in design falls apart in implementation, systems that worked in isolation create chaos when connected. Postmortems are full of things nobody predicted.

How a manager responds to failure sends one of the clearest messages about what kind of environment they’re creating.

The manager who blames publicly or who treats every failure as evidence of individual inadequacy, builds a team that hides problems. People don’t surface bad news early, because early bad news is punished. The result is that by the time problems become visible, they’re much worse than they needed to be.

The manager who treats failure as data, who asks what can we learn from this, what should we do differently, what does this tell us about our process, builds a team that treats failure as information. Problems surface earlier, because surfacing them early is rewarded. The team learns faster.

Amy Edmondson’s work on what she calls “intelligent failure” gets at something worth knowing and understanding: there’s a meaningful difference between a failure that results from trying something new in a low-stakes experiment (where failure is genuinely a useful outcome), a failure from unforeseen complexity in familiar territory (where the lesson is about system awareness) and a failure from preventable error in routine work (where the lesson is about process and attention). How you respond to each type should be different. The first deserves curiosity and celebration of the learning. The third deserves honest conversation about what process changes prevent recurrence.

In the context of an indie game studio, where budgets are small and every month matters, the cost of people hiding bad news is especially high. The cultural investment in making it safe to fail openly, and to learn from failure rather than just survive it, is an effective and proven long-term investment.

Performance management and reviews

“Performance management” sounds like something that happens in big corporations, in rooms with HR representatives and carefully worded documentation. It does not sound like something a twelve-person indie studio should be doing.

But here is what performance management actually is: it’s the ongoing practice of setting clear expectations, giving regular feedback and having honest conversations about how someone is doing relative to those expectations. If you’re doing the other things in this article, you are already doing performance management. The formal review is just the periodic, structured version of something that should be happening continuously.

The formal review matters for a few reasons. It creates a dedicated context for a more holistic conversation that doesn’t happen in the normal rhythm of one-on-ones. It creates a record that is useful if performance issues escalate. And it signals that you take each person’s development seriously enough to invest structured time in it.

A few things that make reviews more useful:

• Don’t let them be a surprise. If someone hears significant feedback for the first time in their formal review, something has gone wrong in the regular cadence of communication. Reviews should feel like a considered synthesis of things both of you already know, not a revelation.

• Separate compensation conversations from performance conversations when you can. When pay is on the table, people understandably orient toward what that number is going to be rather than hearing the substance of the developmental feedback. Two separate conversations, even if they happen in the same week, produces better results.

• Ask the person to self-assess first. Before you share your perspective, ask them: how do you feel this period has gone? What are you proud of? Where do you think you’ve struggled? What would you like to focus on developing? This accomplishes several things: it gives you useful information, it models the reflective practice you want to encourage and it often surfaces things you weren’t aware of.

• On managing underperformance specifically: the most common mistake I’ve seen is waiting too long to name it. By the time a manager is thinking “this person is not performing,” there have usually been months of accumulated issues that were not addressed directly. Address the first issue. It’s a much easier conversation and it gives the person a real opportunity to correct course before the situation has become serious.

When you do address underperformance, separate the person from the behavior. “You’re not pulling your weight” closes the conversation. “In the last three sprints, the tasks assigned to you have regularly slipped without early warning, and that’s created pressure on the rest of the team” opens one. One is a verdict. The other is a description that invites a response, which might include context you weren’t aware of, or might confirm your read and create the basis for a clear, documented plan for improvement.

Emotional intelligence

Daniel Goleman’s work on emotional intelligence identifies a cluster of competencies that cut across everything else in this article. Self-awareness: knowing what you’re feeling and why, and how your emotional state affects your behavior. Self-regulation: the ability to manage that state, to not let momentary frustration or stress drive decisions you’ll regret. Empathy: the genuine ability to understand what someone else is experiencing, not just what they’re saying. Social skills: the practical capacity to navigate interpersonal situations effectively.

These are not personality traits you either have or don’t. They’re capacities that develop with attention and practice.

The self-awareness piece is where I’d start for most managers. Most of the worst management decisions I’ve seen were made by people who didn’t have an accurate read on their own emotional state in the moment. I’m talking about the founder who delivers critical feedback when they’re actually furious about something unrelated, the manager who gives vague, uncommitted direction because they’re anxious about a conflict and don’t want to make it worse, or the leader who reads a person’s frustration as a threat to their authority rather than as legitimate dissatisfaction.

Getting better at this starts with noticing. Noticing what you’re feeling before a difficult conversation and whether that state is one from which you can show up usefully. Noticing the gap between your intent and your impact, asking, when a conversation doesn’t go the way you expected, not just “what did they do wrong” but “what did I contribute to this outcome.”

In practice and on a very personal level, the single most valuable thing I’ve developed over twenty years is the ability to pause, to create a moment between stimulus and response. When something frustrating happens, a person misses a commitment, a decision gets reversed, someone says something hurtful, the impulse is to react immediately. But the practice is to wait, to take the space to process what I’m actually feeling, separate from what I should communicate, before I say anything.

This sounds small. It’s not.

Managing remotely

Most of what I’ve described in this article applies regardless of where your team is located. The fundamentals don’t change when the team is distributed. The execution is harder.

Here’s what I’ve found actually matters most in remote contexts:

Intentionality about presence. In a shared physical space, a lot of interpersonal connection happens passively, in hallways, over lunch, in the ambient awareness of each other that an office creates. None of that happens remotely without deliberate effort. You have to create moments of genuine human contact that aren’t just work and you have to create them on purpose. A few minutes of actual conversation before the agenda starts. An occasional social call that’s just social. Some artifact that acknowledges the person rather than just the work.

Over-communication of context. In an office, context leaks: you hear conversations, you read body language across the room, you develop a sense of what’s happening in the organization through ambient observation. Remote teams don’t have this. What is obvious context to you needs to be stated explicitly. Write it down. Share it. Don’t assume people have the information they need to interpret what you’re asking of them.

Camera on. Not on every single call as a sacrosanct mandate, but for anything involving feedback, conflict, difficult conversations, anything emotionally significant, video is exponentially preferable to audio-only, because you lose enormous amounts of signal without the face. People interpret tone in text differently than intended. People misread audio-only delivery. For things that matter, close the gap.

Protection of asynchronous space. One of the real advantages of remote work, if you run it well, is that people can do deep work without constant interruption. Don’t squander it with a culture of instant-response expectations or unnecessary synchronous meetings. If something can be handled asynchronously, let it be. Save the synchronous time for what actually benefits from it.

Even more deliberate one-on-ones. The value of a consistent, protected one-on-one is amplified in a remote environment precisely because accidental connection is so much rarer. Do not let this slip. It is the primary mechanism through which you maintain genuine knowledge of how each person is doing.

One last thing

People management is a craft in the same way that game design or programming or art direction is a craft. It develops through practice, through feedback, through observing what works and what doesn’t, through making mistakes and taking those mistakes seriously enough to change and grow.

What nobody tells you when you start managing people for the first time, is that you are also a work in progress. The people you manage are watching how you handle uncertainty, how you respond to failure, how you treat the person with the least power in the room, how you take feedback, how you behave when things are going badly. They’re calibrating their trust in you and their trust in this studio as a place worth being, based on all of that.

You won’t get it right all the time. I haven’t, not even close. The question is whether you’re paying attention and trying.

Google’s research eventually identified something they called psychological safety, the sense that it’s safe to take risks, speak up, disagree, admit uncertainty, as the single most important factor in team effectiveness. And what they found, not surprisingly, was that psychological safety is built by managers. Through the accumulated weight of every conversation, every response to bad news, every piece of feedback, every moment where someone spoke up and you chose how to receive it.

That is where this work lives. Not in a framework or a methodology or a set of best practices, though frameworks are useful and I’ve given you several. It lives in the specific, unrepeatable moments of two people trying to do hard creative work together, and a manager trying to create the conditions in which that’s actually possible.

If this was useful, you might also like:

I remember working on a very successful game and I remember talented developers in teams directly responsible for the financial success of that game who were splitting a one-bedroom apartment with a roommate because they couldn’t afford to rent a place on their own.

Indulge me for a second, please, and let that sink in. A game generating tremendous amounts of money and the people who built it, who showed up every day and poured their creative energy into it, couldn’t make rent on their own.

This is probably an extreme example, but the problem of commensurate compensation is par for the course in the games industry. And that’s what I want to talk about.

The implicit deal nobody puts in writing

Most game studios make a promise. Not always out loud, and almost never in writing, but it’s typically there. It shows up as stock options with a one-year cliff and a vesting schedule that assumes the company survives long enough for any of it to matter. It shows up as a conversation in a one-on-one: “if this game does well, we’ll take care of you.” It shows up as the general ambient energy of early development, where everyone is building something together and the assumption is that if it works, everyone wins. Somehow.

The problem isn’t the promise. The problem is that it almost never gets defined. What does “take care of you” mean, exactly? What does “if the game does well” mean? At what threshold? By whose calculation? Nobody writes it down because it feels premature, or because pinning it down would make it feel transactional, or because the founders genuinely haven’t thought it through yet and they’re understandably very busy trying to make the game a reality.

And then the game ships. And if it does well, like really well, that’s when the vagueness becomes expensive. And not just financially. The gap between what people thought was implied and what actually materializes is one of the faster ways to destroy trust in a studio, because it goes straight to the question of whether the values on the culture deck are real or decorative.

So, a profit-sharing plan is how you make the implicit promise explicit. How you put it in writing, make it legally binding, and turn “we’re all in this together” from a vibe into an actual commitment.

Why this matters beyond the money

I write a lot about culture and what it actually takes to build a studio you can be proud and that people want to stay at. Not a studio people tolerate while they wait for something better, but one they genuinely want to be part of long-term. And profit-sharing is one of the clearest messages a studio can send about what it actually values, as distinct from what it says it values.

Because here’s the thing: developers know. They know whether they’re being paid fairly, whether the studio is doing well or when the gap between those two things is getting wider. You can’t really paper over that with team lunches and a Slack channel dedicated to puppies.

A profit-sharing plan doesn’t fix everything. It doesn’t automatically create trust or compensate for bad leadership or make up for a toxic creative environment. But in a studio that’s otherwise doing the right things, it sends a very strong message that is genuinely hard to send any other way: if this game does well, you will materially benefit from that. Not just in the sense that the studio survives and your job is safe. In the sense that money will come to you specifically, in a documented, contractually enforceable way.

I cannot emphasize enough how powerful this is for recruiting and retention. And it matters for the day-to-day culture of development too, because people who feel genuinely invested in an outcome will work differently than people who are just completing tasks.

It’s also, in my humble opinion, simply the right thing to do. Videogames are not widgets. Every game is a unique creative act, built by people who actively pour themselves onto the project. The people who build it should share in its success. Full stop.

What this is not

A profit-sharing plan is not a substitute for fair base compensation. If you’re paying people significantly below market rate and pointing to the profit-sharing plan as justification, you have the logic backwards. The plan is upside participation, not deferred salary. It supplements what people earn; it doesn’t replace it. Please don’t be that person; don’t weaponize a good thing.

It’s also not equity. Equity is ownership, which entitles the holder to a share of the company’s value and comes with its own legal and tax implications (see my gargantuan legal primer for game studios article for more). Profit-sharing is a contractual right to a portion of a defined profit pool in a defined period. Simpler, more flexible, and appropriate for most indie studios that aren’t structured for outside investment.

And it is not a promise. It’s a structure. The difference does matter: a promise lives in your culture deck and your all-hands presentations. A structure lives in employment contracts, is reviewed by a lawyer, and is enforceable. If your profit-sharing plan is a PowerPoint buried in your studio wiki, it has no real value. It’s just vibes. The moment it becomes meaningful is the moment the game ships and the money is real, and that’s when you want there to be no ambiguity about what was agreed.

Get it into contracts. Every employee, every contractor who is eligible. Before the game ships, ideally before development is much further along than it already is.

Defining profit

One of the most important things you’ll do when designing a profit-sharing plan is defining exactly what “profit” means for this purpose. Leave that vague and you’ll regret it.

This is my working definition: profit is what the studio actually receives after platform cuts, after publisher recoupment and after taxes. Not gross revenue. Not adjusted revenue. What lands in the studio’s account as actual net income.

Platform cuts are not profit. Steam takes its 30%, console platforms take theirs, that money was never yours to begin with. Publisher recoupment works the same way: if you have a publishing deal with a recoup clause, the publisher is recovering their investment from your revenue before you see any of it. What’s left after that recoupment clears is what becomes profit. If the game generates $2M in revenue and $1.5M goes to recoup, your profit is $500K, not $2M. Your profit-sharing pool is calculated on the $500K.

This has a practical implication: if you have a publisher deal with significant recoupment, it’s possible, likely even, that no profit exists for a significant period of time after launch, even if the game is selling reasonably well. Developers need to understand this. It isn’t a technicality designed to deny them their share. It’s how the math works, and managing expectations around it is a leadership responsibility.

One important thing not in this definition is the development costs. I don’t think a studio should require full recoupment of its own dev costs before the profit-sharing plan activates. The studio understandably takes the lion’s share of the profits precisely because it’s absorbing that risk. That’s why the profit-sharing pool is 5-15% and not say, 50%. Requiring dev cost recoupment on top of that would mean most profit-sharing plans never pay out, which defeats the purpose.

The scaling structure

Rather than a flat percentage that either triggers or doesn’t, I prefer a scaling model tied to profit thresholds. Something like this:

• $0 to $750K in profit: no profit-sharing pool

• $750K to $1.5M: 5% of profit goes into the pool

• $1.5M to $3M: 7.5%

• $3M and above: 10%

The specific numbers should reflect your game and studio’s economics. These are illustrative. But the principle is simple and solid: as the game generates more profit, the percentage going to the team increases. The studio’s risk was highest in the early stages, but as returns grow, a larger share flowing to the people who built it is appropriate.

This structure also makes the plan more credible to developers. Rather than a binary trigger that may never activate (like those all-or-nothing Metacritic target deals that you read about in the news), there’s a visible range of more atomic outcomes and what each one means for them. That’s something you can actually have an honest conversation about.

Who is eligible

Full-time employees who have been with the studio for at least one year are eligible. The one-year cliff serves two purposes: it creates a meaningful retention incentive, and it prevents the plan from becoming unmanageable if the team turns over significantly during development.

Contractors are more complicated, but worth getting right. There’s a meaningful difference between someone who freelanced for six weeks on a specific deliverable and someone who has been working alongside the team for eighteen months through a PEO or employer of record arrangement. The latter is effectively an employee. Treating them categorically differently from full-time staff, especially if the only reason they’re contractors is geographic or administrative, is exactly the kind of thing that erodes trust.

My approach is the following: any contractor who has worked continuously with the studio for twelve months or more is eligible for profit-sharing on the same basis as a full-time employee. Shorter-term freelancers are not. This isn’t perfect, but it’s defensible and it recognizes the reality of how distributed indie studios actually staff up.

What about someone who leaves before the game ships? This should be spelled out explicitly in the contract. A reasonable approach is a vesting schedule: employees who leave after year one but before launch receive a prorated share based on tenure, provided they left in good standing. Someone who was there for three years of a four-year development contributed to the game’s success. Cutting them out entirely is difficult to justify.

How the pool is distributed

Once the pool size is determined, you need a method for allocating it across eligible employees. A weighted scoring model is more equitable than a flat split, because different employees have different contributions, tenures and roles.

Here’s a framework that works reasonably well (feel free to tinker with the numbers):

Company performance (40%): a base score shared equally across all eligible employees, reflecting that everyone contributed to the outcome. This is the dominant weight because profit-sharing is primarily about participating in collective success.

Individual performance (25%): based on annual performance reviews. Each studio will have its own way of measuring this, and I’ll cover performance reviews in a future article. For this model, map whatever system you use to a 0-100 scale. A rough generic anchor set: exceptional performance scores 90-100, strong performance 70-85, solid/meets expectations 50-65, below expectations 25-45.

Seniority (15%): based on tenure with the studio, on a fixed 0-100 scale: 1-2 years scores 25, 3-5 years scores 50, 6-10 years scores 75, 10 or more years scores 100. Recognizes loyalty and accumulated contribution without rewarding tenure infinitely.

Role impact (20%): accounts for positions that had disproportionate influence on the game’s outcome: lead roles, critical technical positions, creative leadership. Scale: low impact scores 25, medium impact scores 50 (this is what you can expect for most developers), high impact scores 75, critical impact scores 100.

To see how this works in practice, consider two employees: Billie is a junior engineer, two years with the studio, strong performance review, medium-impact role. Jodie is a principal engineer, five years with the studio, adequate performance review, critical impact role.

The framework assessment:

Assume the studio has hit $2M in profit and the pool is 7.5% (again, this percentage is just an example), so $150,000 to distribute. With a 40/25/15/20 weighting:

• Company performance: everyone gets 100/100 as a base score.

• Individual performance: Billie scores 80/100 (strong review). Jodie scores 55/100 (adequate).

• Seniority: Billie scores 25/100 (1-2 years). Jodie scores 50/100 (3-5 years).

• Role impact: Billie scores 50/100 (medium). Jodie scores 100/100 (critical).

The math:

• Billie’s weighted score: (100×0.40) + (80×0.25) + (25×0.15) + (50×0.20) = 40 + 20 + 3.75 + 10 = 73.75

• Jodie’s weighted score: (100×0.40) + (55×0.25) + (50×0.15) + (100×0.20) = 40 + 13.75 + 7.5 + 20 = 81.25

• Total weighted score pool: 73.75 + 81.25 = 155. Allocation rate: $150,000 / 155 = $967.74 per point

The outcome:

• Billie receives: 73.75 × $967.74 = $71,371

• Jodie receives: 81.25 × $967.74 = $78,629

The model keeps the total distribution within the pool, rewards the factors you’ve decided matter, and produces an allocation that’s explainable to the people receiving it. That last part matters more than founders usually anticipate. When someone asks why they received what they received, you want to be able to show your work.

One honest caveat about individual performance scores: in a small studio, the person who designs the weighting is often the same person who conducts the reviews. That’s not inherently corrupt, but it’s not neutral either, and developers know it. Acknowledging this openly and building in some consistency checks on how reviews are conducted is more credible than pretending the system is fully objective. The performance component is 25% of the calculation (as proposed by me; you can change that as you see fit). It shouldn’t be a vector for favoritism, and being transparent about how scores are determined goes a long way toward preventing that perception.

Timing and taxes

Profit-sharing is typically distributed annually, after the financial year closes and taxes are finalized. This gives the studio time to confirm actual net profit, account for any outstanding liabilities, and calculate distributions accurately.

From a tax perspective, profit-sharing payments are compensation and taxed as such (I’m in California, but there may be other taxation mechanisms in other states, and certainly in other countries). Employees should expect to receive them as part of their annual income, not as a separate windfall. Worth communicating clearly so there are no surprises at tax time.

On vesting: the plan uses a simple one-year cliff. Employees who have been with the studio for at least one year are eligible, and from that point they receive their full calculated share in every profitable distribution cycle. You clear the cliff, you're in. So someone who joined in January 2033 on a game that ships and hits its profit threshold in December 2035 receives their full share in the first distribution, and every one after that, as long as they're still with the studio. Clean, simple and easy to explain to your team on day one.

The conversation you have before the game ships

None of this works if developers don’t understand it until the money arrives.

The plan should be introduced during onboarding, explained clearly, and revisited annually, especially if the studio’s financial situation changes in ways that affect the timeline. If the publishing deal means recoupment will take longer than expected, say so. If the game is underperforming projections and the thresholds are looking harder to reach, say that too. Developers are adults. They can handle the honest version of the situation. What they can’t handle, and what will damage the studio’s culture badly if it happens, is finding out after the fact that the plan they believed in was built on assumptions that were never realistic.

The flip side of that: if the game does well, this is one of the most powerful culture moments a studio can have. People receiving a check that reflects their real contribution to something they built together is not a minor thing. It’s the kind of moment that shapes how people talk about a studio for a long time.

If this was useful, you might also like:

I’m sure Microsoft has a strategy for Project Helix and the future of Xbox. I’m just genuinely struggling to make sense out of it.

What is Project Helix?

Quick context. Based on the talks at GDC this week, it’s a new console. Kind of.

The defining architectural characteristic is that Helix runs Windows underneath, with an Xbox Mode interface on top: a full-screen, controller-optimized experience Microsoft is already rolling out to Windows 11 PCs in April. From what leakers and the architecture both suggest, you can exit Xbox Mode into a standard Windows desktop and install Steam, Epic, GOG, whatever you want. Microsoft told developers at GDC to “build for PC” going forward. The Unified GDK means one build runs on both console and PC, which, if it works, would be genuinely useful for developers.

The proposed hardware looks impressive. Dev kits ship at some point in 2027, which means a consumer launch in late 2027 at the absolute earliest. Possibly simultaneous with the PS6, which wouldn’t be good for Xbox.

So: a Windows PC with a curated launcher as the default interface, sold as a console, priced at $1,000 to $1,200. That’s Project Helix.

What problem is Xbox trying to solve?

To understand Xbox’s strategy, we need to touch briefly on the status quo and the hole that Xbox is trying to dig itself out of.

A lost console war. Two back-to-back console generations, lost by a significant margin. The PS4 outsold the Xbox One 117 million to 58 million, roughly 2:1. The PS5 has done roughly 86 million units against Xbox Series' 34 million, closer to 2.5:1. That's a sustained, widening structural disadvantage.

An ineffective business strategy. Alongside the hardware decline came a strategic shift that was poorly communicated and, I'd argue, self-defeating. Starting around 2017, Xbox began prioritizing reach over hardware sales: more players, more platforms, Game Pass as the center of gravity. The "play our games everywhere" message followed. Then came the steady erosion of exclusivity: first a few titles, then most titles, and as of 2026, Halo: Campaign Evolved, Fable and Forza Horizon 6 are all planned for PlayStation. Xbox fans, understandably, felt betrayed. And the hardware rationale, the reason to own an Xbox specifically, collapsed alongside the exclusives.

No seminal games. Sony delivered God of War: Ragnarok, Spider-Man 2, Ratchet & Clank: Rift Apart, Gran Turismo 7, Ghost of Yotei, Returnal: major, critically acclaimed, console-selling titles. Xbox had Forza Horizon 5, which is genuinely excellent, and then a fairly long stretch of disappointment. Halo Infinite underwhelmed players, Microsoft Flight Simulator is great but it’s a niche title by definition, Hi-Fi Rush was also a great game but it didn't move consoles, and Starfield was divisive at best. Two consecutive generations without an equivalent to Halo: Combat Evolved, Gears of War, or Fable. Something that makes buying an Xbox feel non-negotiable.

Extraordinary spending and low ROI. Between 2020 and 2022, Microsoft spent a combined $83.5 billion acquiring ZeniMax/Bethesda and Activision Blizzard. The post-acquisition output, Starfield, Redfall, Hi-Fi Rush, Indiana Jones, Call of Duty: Black Ops 6, Deathloop, Ghostwire: Tokyo, generated somewhere in the range of $1.8 to $2.5 billion in total revenue. Strip out Black Ops 6 and you're looking at somewhere between $700 million and $1 billion. For a four-to-six year post-acquisition window on an $83.5 billion investment, that's a very difficult number.

Game Pass stalling. Game Pass compounds the picture. Subscriber growth was steady from 2019 through 2023, going from around 6 million to 33 million. Then it really slowed down. Mid-2025 estimates sit around 36 million. The 100 million target by 2030 that leadership set is not happening. And the fastest-growing segment of Game Pass is on PC: people already in the ecosystem, already paying, who don't need new hardware to keep doing so.

Okay, so that’s the situation. Now for the strategy.

What is Xbox’s strategy?

I've spent the last couple of days trying to play devil's advocate and articulate what they're attempting. Every time I end up saying to myself: this doesn't make sense. Nevertheless, here's my best effort.

The strategy seems to rest on four pillars. First, a hardware reset: putting the Series X era behind and signaling a new generation. Much needed. It makes sense.

Second, the open console play: by allowing Steam, GOG and Epic on Helix, Xbox is trying to solve the “content gap” between PC and console. One box, every library.

Third, performance through neural rendering: FSR Diamond, Neural Texture Compression, GPU Work Graphs. The pitch is that Helix punches above its silicon weight through AI-accelerated rendering rather than raw specs.

And fourth, ecosystem unification via Windows: the Xbox Mode rollout to Windows 11 PCs this April theoretically expands the “Xbox install base” to hundreds of millions of devices before the hardware even ships, so the console launch isn’t a cold start.

That’s the best I could come up with. It’s not entirely incoherent. But it’s a far cry from a winning proposition. Here’s why.

Why is that strategy not credible?

Unclear value proposition for an unclear end user

For the content gap argument to hold, a few things need to be true simultaneously: that this is a problem players actually want solved, that it isn’t already largely solved, and that there’s a meaningful audience willing to spend $1,000-plus on this specific solution.

On the first point, my admittedly observational take is that “I wish I could seamlessly play between PC and console” or “I wish I could play my Steam library in my living room” or “I wish I could seamlessly switch between productivity and play” are not exactly things I’ve heard many gamers say. It’s not top of the list.

On the second, cross-play already exists across much of the Xbox library. Call of Duty, Sea of Thieves, Forza Horizon 5, Halo Infinite, Minecraft: these all work across Xbox, PC and PlayStation in various configurations. The divide is narrower than it’s been in any previous generation.

On the third, who specifically is the new adopter Helix creates? Let’s work through the permutations:

1. If you’re a console gamer who doesn’t game on PC, the PS6 will almost certainly be cheaper and give you access to a better library of exclusives

2. If you’re a console gamer who also games on PC, with Xbox now releasing first-party games on PlayStation, you’re simply better off with a PS6

3. If you’re a PC gamer, you value flexibility, upgradability and tinkering: a closed hybrid doesn’t scratch that itch, especially when those Xbox games are already on Windows or Steam

4. If you’re already a Game Pass subscriber, Helix doesn’t change your situation at all

The person Helix is actually designed for, someone who currently owns both a console and a gaming PC, finds switching between them annoying, and has enough disposable income to spend $1,200 on consolidating them into one living-room box, is a real person. It’s just not very many people.

Questionable revenue upside

Then there’s the revenue problem the open console framing obscures entirely. A player who buys a Helix and spends the next seven years buying games on Steam has given Xbox $1,200 once for the hardware and maybe their Game Pass subscription. Meanwhile, Valve collects 30% on every single game that player buys for the next seven years. Xbox built the box. Valve gets the recurring margin. That’s not obviously a winning business model.

Performance through neural rendering

I don’t doubt that the technological advancements announced by Xbox’s Jason Ronald this week are fantastic. My question is: so what?

Sony will very likely match whatever rendering advances Xbox ships. Or at least get close enough that it won’t really matter to most players. One way or another, the PS6 will be very good. It will have the PlayStation install base, the developer relationships, the exclusive content, and, after their recent reversal on PC ports, a cleaner exclusivity story than they’ve had in years. Helix can win the spec sheet and still very much lose the generation again, because while specs do matter, when you’re splitting hairs, that’s not the deciding factor for why people choose one platform over another.

As for Valve, the Steam Machine may not match Helix’s neural rendering capabilities, but it doesn’t need to. Valve has an install base of hundreds of millions of PC gamers, libraries those players have been building for twenty years, and an enormous amount of goodwill that Xbox has spent the better part of a decade burning through. Asking players to ditch Valve for Xbox in the living room requires a compelling reason. Better ray tracing is just not it.

Unifying the ecosystem via Windows

This is the argument I find hardest to take seriously. Xbox games have been playable on Windows PC via the Xbox app for years. Xbox Play Anywhere has existed for years. Windows 11 has shipped with Xbox pre-installed for years. The “unification” Microsoft is describing is not new: it’s a UX refresh on infrastructure that already exists. What are we talking about here? I legitimately don’t get how this is a thing.

Brutal competitive landscape

The Steam Deck came out in 2022 and it docks. Plenty of PC gamers who wanted a couch device already bought one. And Valve has confirmed a Steam Machine for 2026: a proper living-room gaming box running SteamOS. One to two years before Helix ships.

The market gap Xbox is targeting is being filled by the company whose software Xbox needs to run, before Xbox’s hardware arrives. Once again: does that make strategic sense to you?

Valve’s position in all of this is, frankly, remarkable. They don’t need to “beat” Helix. Valve just needs Steam to remain the default place people buy PC games, which it already is by a wide margin. Even with lower specs, the Steam Machine is a direct competitor for the living-room audience with a devastating one year head start. The only way for them to give up this advantage would be if the upcoming Steam Machine turns out to be a disaster. It’s in the realm of possibility but I would not bet on that.

Sony is also sitting well here. They read the Project Helix situation clearly and made a sharp move recently. They were porting flagship single-player exclusives to PC (God of War, Spider-Man, Horizon) with a roughly 12-18 month delay after console launch. This was generating revenue and expanding the PlayStation audience on PC.

Then they scrapped it. Ghost of Yotei stays PS5 exclusive. Saros, launching later this year, stays PS5 exclusive. According to Bloomberg’s Jason Schreier, plans for other single-player PC ports were also cancelled. The main reason being concern about PlayStation exclusives running on Xbox-branded hardware once Helix ships.

Sony’s core competitive advantage is exceptionally high-quality content you can only get on PlayStation. Every PC port slightly erodes that advantage. With Helix trying to position itself as a device that can access everything, Sony’s counter is simple: make sure “everything” doesn’t include the games people most want. You want to play the next God of War at launch, buy a PS6. That’s a clean message, and it’s been Sony’s message, with occasional deviations, for thirty years.

Tough price point and challenging economic conditions

If Helix lands at $1,200, you can almost buy a PS6 and a Steam Deck for that amount. That covers nearly all of gaming with the exception of Nintendo. That’s a real comparison that real people will make.

It's also worth noting the economic conditions those real people are living in. The majority of Americans are living paycheck to paycheck by multiple recent surveys. Spending over a thousand dollars on a new console that doesn't do anything cheaper alternatives don't already do is a hard ask in this environment. [1, 2, 3]

What can Xbox do?

With the understanding that being an armchair coach is easy, here are my two cents.

Backpedal the no-exclusives decision. This is Xbox’s Achilles heel. And it’s simple: while there’s nothing wrong with pursuing more players, by enabling your content to be on other, more successful platforms, you eliminate the reason for gamers to buy your hardware.

Without exclusives there is no need to produce or buy any hardware.

The most logical choice here, by far, is to backpedal that position and line up a murderer’s row of great games for the Helix. Of course, it’s not easy, but Microsoft has an absolutely stacked studio portfolio. Playground Games, Halo Studios, The Coalition, Obsidian, Ninja Theory, Rare, Double Fine, Bethesda Game Studios, Arkane Lyon, MachineGames, id Software, inXile, Infinity Ward / Treyarch / Sledgehammer, Blizzard. The creative firepower is certainly there and it’s more than enough to build an exclusives strategy that gives players genuine reasons to own an Xbox, games they cannot get anywhere else.

Build a mobile device and own “gaming anywhere”. The Steam Deck proved there’s a real market for high-quality portable PC gaming. The ROG Xbox Ally is already a version of this, even if it’s not a first-party product. A proper Xbox handheld, positioned as “your Xbox everywhere, not just your living room,” is a vastly more coherent consumer proposition than a $1,200 living room PC competing with Valve. Sony has essentially no presence in this space. Nintendo owns the family-friendly end of portable gaming at a different price point. There’s room. And it’s arguably more future-proof: the trajectory of mobile hardware makes portable high-fidelity gaming increasingly inevitable.

Abandon hardware and focus on content. Xbox has legitimately something good in Game Pass. Double down on making that an undeniable a la carte value proposition. Alternatively, focus on getting your games into the hands of as many hands as possible, across Steam, Sony and Nintendo, and build the strongest publisher position in the industry regardless of hardware. It may not be the most profitable path, but it's a congruent one.

None of these are clean. Each has real problems and tradeoffs. But each of them can answer the question a consumer inevitably asks: why would I spend money on this instead of the obvious alternative? Helix’s answer to that question is still genuinely unclear to me.

The Xbox One déjà vu

In 2013, Microsoft launched the Xbox One. The pitch was a next-generation entertainment center for the living room: television integration, Kinect voice control, a device that was as much about cable TV as it was about games. It was technically ambitious but strategically muddled, to put it nicely. And it forgot, at the most fundamental level, what players actually wanted from an Xbox: games. Great games. The PS4 launched at $100 less with a cleaner message (”this is a games console”) and never looked back. Xbox has been playing catch-up ever since.

Project Helix isn’t the same mistake. But it certainly rhymes.

Competition is good for our industry. It’s good for developers, it’s good for players, it’s good for the creative health of the medium. I wish for Xbox to find a strategy that makes sense. We’d all benefit from that.

There’s a moment in every single production I’ve ever been part of where someone brings up an idea that wasn’t in the plan. A new mechanic. A different approach to a level. A visual treatment nobody had considered. And the idea is good. Not “worth filing away for the sequel” good. Actually really good, right now, for this game. This should be of no surprise to any game developer. The creative process doesn’t end when production begins. Far from it. Development begets creativity.

What studios do with this varies dramatically.

Some teams shut it down reflexively - “we’re in production, we can’t be doing this” - and devs carry a low-grade resentment about the decision for the next three months. Some teams chase it without thinking too hard about the cost, and then find themselves in a different kind of trouble six weeks later. And some teams have figured out how to take the idea seriously, test it deliberately, and make a real decision about it without burning the project down.

The tool for that last approach is a creative spike.

What a spike actually is

The term comes from agile software development, where a spike is a short, time-boxed investigation you run when an unknown is too large to estimate around. You’re not building anything permanent. You’re buying information.

In game development, a creative spike is the same thing applied to a creative or technical question: a small, focused effort - typically one to two weeks, rarely more - with a defined question at the center, explicit criteria for what a useful answer looks like, and a clear agreement about what happens when time is up.

That last part is where most studios get it wrong. A spike without a defined endpoint and a clear decision framework isn’t a spike. It’s just scope creep with better branding.

Preproduction is different

Quick clarification. Preproduction is about preparation and a large part of that is to answer questions. Running experiments, testing mechanics, pressure-testing the vision - all of that is expected and appropriate before you’ve committed to a production plan. The cost of exploration is baked into the phase. You don’t need a framework for deciding whether to spike something when the whole phase is, in a sense, one large spike.

What follows is primarily about production - the period after you’ve committed to a plan, locked a scope (as much as one can “lock scope” in game development), and made promises to yourself or others about what you’re building. That’s when new ideas become genuinely complicated and when having a real process for handling them matters.

The two questions you actually have to answer

When a promising idea surfaces in production, there are two questions worth separating cleanly, because they’re easy to collapse into each other and that tends to produce bad decisions.

The first is: is this worth exploring at all?

The second is: can we afford to explore it right now?

Both questions need real answers. Studios that skip the first one waste time exploring ideas that don’t belong in the game. Studios that skip the second one explore ideas they can’t actually afford and then wonder why they’re behind.

Is this worth exploring?

The first question is partly about risk management and partly about creative instinct - and in practice, those two things aren’t always easy to separate. A new idea might be worth a spike because the existing solution has a nagging weakness nobody’s been willing to name. It might be worth one because a team member noticed something in playtesting that nobody has a good answer for. Or it might just be that someone had a genuinely better idea than what’s in the plan, and the honest thing is to admit that.

The clearest filter is this: does the idea clearly advance your vision, your pillars and the experience you’re trying to create? Not “does it sound cool” and not “would players probably like it.” Does it make this game more itself?

A few real categories of ideas that tend to warrant a spike:

A technical unknown: say the game director has a theory that a certain shader would dramatically change how a biome reads emotionally, but nobody knows if the engine can handle this particularly expensive shader at scale without tanking performance. You’re not going to resolve that by talking about it.

A design question: a new traversal mechanic has come up that seems like it might work better than what’s currently in the build, but it touches a lot of existing systems and the implications aren’t obvious. Playing with it in isolation for a week tells you things that three design documents won’t.

An art direction shift: say an artist has been sketching a cell-shaded treatment for a dream sequence. The doodles look genuinely interesting. But “looks good as a sketch” and “works in-engine” are not the same statement, and you need to know which one you’re dealing with.

A level design hypothesis: the team suspects that a different structural approach to a mid-game hub would solve a pacing problem they’ve been papering over with smaller fixes. That’s worth a short investigation before committing to a rebuild.

A narrative or tonal question: a writer proposes a different register for a key character that wasn’t in the original design doc. It’s plausible. It might be better. Running a few scenes in that voice and testing them in context costs a week and tells you something real.

The category matters less than the underlying logic: you’re running a spike when a question is real, when the answer would change what you do next, and when you can’t get that answer any other way.

Can we afford it?

This is where intuition tends to mislead people. The idea feels urgent. The team is excited. The instinct is to find a way to make it work. Which is sometimes right - but the question deserves a real answer, not a rationalization.

A useful set of questions to work through, roughly in order:

Does it fit in the schedule? Look at the project plan with the spike inserted. Not the optimistic version of the plan - the one that reflects where you actually are. If making room for a one-week spike requires shifting work that was already on the critical path, you’re not really choosing whether to run the spike. You’re choosing what to sacrifice for it.

If we spend a week on this, what specifically is not getting done instead? Name the thing. “We’ll push some tasks” is not an answer. “The combat team won’t start on the boss encounter this sprint” is an answer. That level of specificity changes the conversation.

Can an external team run this spike? This is underused as an option and worth considering seriously, particularly for art and technical work. If a technical artist has floated a new shader approach, it’s not an absolute necessity for your internal team to be the one to test it. Bring in a freelance tech artist (or a graphics engineer if you can find one) to prototype it on a separate branch. If a 2D animation style has come up that nobody on the team can actually execute - think of something like Persona 5’s all-out combat overlays, where an animated 2D layer punctuates the 3D action - you can hire an external 2D animator to produce a proof-of-concept and composite it against real footage from the build. It won’t be the same as having the work fully integrated. But it’s often enough to make a real decision. And it doesn’t cost you team velocity.

What are the contextual implications for the team? Context-switching is expensive and most people underestimate it. Pulling two engineers off a system they’re deep in to run a one-week spike doesn’t cost one week. It costs one week plus however long it takes them to get back to where they were. That cost is real and it compounds. On the flip side: if the team has been excited about this idea and not running the spike means watching it get shelved indefinitely, that has its own cost. Morale is a resource. People who feel like their ideas get a fair hearing work differently than people who feel like the plan is untouchable.

All of that goes into the calculation. None of it is a formula. You’re making a judgment call - but you should be making it with real information, not enthusiasm.

How to actually run one

Assuming you’ve decided the spike is worth it and you can afford it: structure matters, and the structure is not complicated.

Start with a hypothesis and two or three questions.

The hypothesis is the thing you believe might be true. “We think cell-shading the dream sequence will create a more emotionally distinct experience than the current approach.” The questions are what you’re specifically trying to answer. “Can we execute this at acceptable performance cost? Does it actually read as more distinct in context, or just different? How much additional work would full integration require?”

If you can’t write a clear hypothesis, the spike isn’t ready to run. The hypothesis is what keeps a week of exploration from becoming a week of wandering.

Set pass and kill criteria before you start.

Before the spike begins, agree on what a pass looks like and what a kill looks like. Not vaguely - specifically. “Pass: the prototype performs within acceptable frame budget on target hardware and reads as meaningfully distinct in a blind playtest. Kill: either condition fails.” Those criteria don’t need to be elaborate. They need to exist and they need to be agreed on before anyone starts working, not after you’ve already seen results you’re attached to.

A pass can lead to one more round of exploration, but only with a new hypothesis and new questions. “It worked, let’s keep going” is not a plan. If the first spike answered its questions and raised a new one that’s worth answering, treat it as a new spike - with its own scope, its own criteria, its own endpoint. The second round is not a continuation. It’s a new commitment.

A kill is an agreement, made by the team, that this direction is closed. Not “on hold.” Not “we’ll revisit.” Closed.

Time-box it and hold the box.

One to two weeks is the right range for most spikes at the indie scale. Frankly, two weeks starts to feel more like a mini-production phase than an investigation, and tha might be a sign you’re either exploring something too large to spike or you haven’t scoped the question tightly enough. If a week keeps getting extended because “we’re almost there,” the spike has become something else. Name that honestly and make a real decision about it.

Assign clear ownership.

Someone runs the spike. Not the whole team - a small group, usually one to four people (this is contextual, of course), with someone accountable for the outcome. That person is responsible for bringing the result to the team at the end of the time-box: here’s what we found, here’s what it means, here’s the recommendation.

After a kill

I wrote about this before. Killing an idea the team was genuinely excited about is one of the harder leadership moments in production, and it doesn’t get easier just because the process was clean.

People brought something they cared about. They spent a week on it. The result didn’t clear the bar - but that doesn’t mean the idea was bad or the person who proposed it was wrong to raise it. Those two things need to be separated clearly.

What that looks like in practice: acknowledge the work, acknowledge what was learned, and be specific about why the decision came out the way it did. “We found out X, which means Y won’t work for us at this scale” is a more useful sentence than “it didn’t pass.” The team needs to leave that conversation understanding not just what was decided but why - and trusting that the process was honest.

The bigger cultural point is this: if people experience a kill as a reprimand - if the message they take away is “don’t bring up ideas that don’t make it” - you’ll stop getting ideas. The spike process only works over time if the team believes their ideas get a real hearing. A well-handled kill is part of how you build that belief. A poorly handled one erodes it fast.

When not to use them

A few situations where a spike is probably not the right tool:

When the question is really a scope question. If the idea is genuinely good but would require significant rework of existing systems or authoring significantly more content than originally anticipated, the relevant question isn’t “does this work” - it’s “are we willing to pay the real cost of including it.” That’s a production and prioritization conversation, not a spike.

When you already know the answer. Sometimes a spike gets proposed because it feels more diplomatic than saying “we’re not doing this.” If the honest answer is that the idea doesn’t fit the vision or the schedule, say that. Running a spike you expect to kill is expensive theatre.

When the team doesn’t have capacity to run it honestly. A spike conducted by people who are already overloaded, under time pressure, and half-present will produce unreliable results. If you can’t run it properly, either find external capacity or wait until you can.

The ideas that surface mid-production aren’t a problem to be managed: they’re just game development working the way it’s supposed to, creatively and iteratively. The question is whether you have a real process for finding out which ones you should pursue, and what they’ll actually cost to include.

A spike, done well, is how you hold both things at once: genuine creative openness and genuine production discipline. You’re not choosing between protecting the plan and being receptive to better ideas. You’re creating the conditions where both can be true.

If this was useful, you might also like:

Heads up: this is a long article. We cover a lot of ground on this one.

A small team, talented and motivated, has a game concept they genuinely believe in. They've talked about it, sketched it out, argued over it. They're excited - and why wouldn't they be? It's a great idea. So they open their laptops, spin up a repo, agree on a version of Unreal and start making things. And for a while, this feels like the right call. They're building, they're moving, they're making a game. This is what it's all about.

Then, somewhere around the four or five month mark in a say, eighteen month dev cycle, the wheels start wobbling. Nobody quite agrees on what the next thing is, or why. The to-do list is a chaos of notes, ideas and Miro diagrams dumped from every direction. Some things got built twice. Some things that should have been built first weren't built at all. The engineer is blocked waiting on art that nobody knew was a dependency. The designer rewrote a system the programmer had already implemented, because the spec wasn't clear. The game director is adding new features in real-time, because they saw something at a demo that they liked.

Nobody is doing anything wrong, exactly. There’s just no plan. No rhyme or reason. Planning feels slow and it’s not exactly the most fun of activities, but in my experience, the studios that invest in planning are the ones that move with intention and end up being faster when it really matters.

I want to pragmatically walk you through the full arc of project planning for a video game, from the structural logic that sits above everything else to the first sprint or Kanban board that gets work actually moving. We’ll use a fictional game called Ironfall (it shames me to admit how long I spent picking that name) as our running example throughout: a five-person team, PC-first, action-RPG, pre-funding, bootstrapped. Small enough to be realistic, complex enough to make the examples meaningful.

A few things we will not cover here, because they deserve their own dedicated treatment (and I’ve written about some of these already): staffing planning, risk planning, quality planning, communication planning, financial planning and team chartering. These are not optional topics. They're essential components of a complete project plan. But they're also big enough to warrant real depth and we'd be doing them a disservice by compressing them into an already long article. Look for those separately.

Let’s start at the top.

The planning onion: how planning is structured

There’s a model that Mike Cohn describes in Agile Estimating and Planning that I find genuinely useful as an orientation tool: the agile planning onion. The image is simple: planning happens at multiple levels, each nested inside the others, from the widest horizon down to the narrowest. Vision is the outermost ring. Then roadmap. Then release. Then iteration. Then the day of work.

The mistake most teams make is trying to do only one of these levels - usually the iteration or the day - and treating that as "planning." It isn't. It's scheduling. Planning is the whole stack.

Here's what that distinction actually costs you in practice. A team that only plans at the iteration level knows what they're doing this sprint. They don't know whether this sprint's work is the right work, whether it's sequenced correctly relative to what comes next, or whether the sum of all their sprints adds up to something that will be ready when it needs to be ready. They feel productive. They're not necessarily converging though. The disconnect between daily execution and the larger shape of the project is one of the most common - and most expensive - planning mistakes in small studios.

I’ve written separately about vision, what it is, how to build it, why it’s the most important alignment tool you have. If your vision isn’t clear yet, start there and come back. Everything below that assumes you have a coherent vision: you know what game you’re making, why, what’s unique about it, what the pillars are, who it’s for, what the experience should feel like and what you won’t do.

What we’re building in this article is everything between that vision and actual daily work.

So, starting from the vision and working down:

Roadmap. The multi-month shape of the project. What phases, what major milestones, what big bets in what order. The answer to "where are we going and roughly when?" This is your strategic horizon. For Ironfall: first playable by week twelve, pre-production done by week twenty, production through the end of the year. Nothing at this level says what work gets done. It's a sequence of destinations with approximate timing attached.

Release. What each of those destinations actually is. When the roadmap says "first playable by week twelve," the release is the thing you're delivering in that first playable: the specific goal it needs to achieve, what done looks like and the full body of work required to get there. Roadmap and release are easy to conflate because they both involve milestones and timing, but the roadmap answers "when" and the release answers "what." You need both.

Iteration. A sprint's worth of committed work. The two-week window (or whatever cadence you use) where the team selects a chunk of the release backlog and commits to completing it. This is where stories get pulled, work gets done and actual velocity data gets generated.

Day. Individual tasks and daily priorities. This mostly emerges from the iteration plan.

Each level should inform the one below it. The roadmap shapes the release plan. The release plan shapes what goes into iterations. The iteration plan shapes the day. When they’re disconnected, when the daily work has no visible relationship to the release, which has no visible relationship to the roadmap, you get a team that is busy and not necessarily converging and delivering valuable results.

Step one: define the high-level goals for the project

Before you can build a useful roadmap, you need to be honest about what success actually looks like for this project. Not in a fuzzy, aspirational way. In a concrete, answerable way.

For Ironfall, the team might define their high-level project goals like this:

• Prove out our combat system well enough within 14 months to pitch a publisher

• Build a demo before next year’s Steam Next Fest that gets us to 30k wishlists before Early Access

• Ship a polished, complete PC build on Steam, rated at or above a 7/10 by players in the target genre

• Ship a 6-8 hour single-player experience that demonstrates our studio can execute a complete narrative arc

• Maintain a team of 5, no crunch, sustainable pace throughout

These are not the same as the creative pillars or the vision. These are project outcomes - the things that define whether this endeavor succeeded as a project, separate from whether the game is good (though they're related). They answer: what are we trying to achieve and how will we know if we did?

Goals at this level should be:

Specific enough to generate decisions. “Make a great game” is not a goal. “Ship a feature-complete, stable, well-optimized build by Q3 of next year” is a goal. Specificity forces honesty.

Measurable or at least evaluable. You should be able to look at a goal and say, clearly, whether it was met or not. If you can’t, it’s not a goal, it’s an expression of hope.

Grounded in your actual constraints. A five-person bootstrapped team setting a goal of “achieve 150K wishlists before launch” is either a stretch target or wishful thinking, and you should know which one it is when you write it down.

Aligned with each other. If one goal says “ship fast” and another says “achieve AAA production values,” those are in tension and you need to decide how you’re resolving that tension before it surfaces in production as a fight.

Write these down. Put them somewhere visible. Socialize them regularly. They become the reference point for every hard tradeoff you’ll face in the next year or two of development.

Step two: outline the roadmap

A roadmap is not a schedule. A schedule tells you when specific tasks will be done. A roadmap tells you what phases the project moves through and in what rough order. It operates at the level of months and milestones, not weeks and tasks.

For game development, the roadmap should normally map to the development phases. If you haven't read my piece on game development phases it might be worth doing that before going further. The phase structure I use there is the foundation for what a roadmap looks like in practice.

At the roadmap level, Ironfall’s planning might look something like this:

Months 1-2: Pre-production. Core systems prototyped, art benchmarks established, production pipeline validated, first playable built. Team aligned on scope, tooling and working agreements.

Months 3-6: Production - MVP 1. Core combat loop, one complete playable level, primary progression system. Internally shippable. First closed external playtest.

Months 7-9: Production - MVP 2. Two additional levels, expanded enemy roster, narrative setup established, sound design integrated. Second playtest cycle.

Months 10-12: Production - MVP 3. Full content pass, meta systems (inventory, upgrades), all features built. Closed beta candidate.

Months 13-15: Closing. Bug triage, optimization, certification prep, launch campaign. No new features.

That's a roadmap. Rough enough to breathe, specific enough to plan against and have intelligent conversations around.

A few things worth naming about roadmaps:

They’re not commitments to dates. They're your best current thinking about sequencing and duration, informed by what you know today. When new information arrives - a feature turns out to be harder than expected, a playtest reveals a core loop problem that needs addressing - the roadmap changes. That's not a planning failure. That's planning working as intended.

They should have explicit milestones. Not just “MVP 1 done” but a crisp definition of what “MVP 1 done” means. Unambiguous criteria that anyone on the team could evaluate. We’ll come back to this.

They need to account for phases and transitions. Moving from pre-production to production is not a neutral moment. It requires certain things to be true: pipelines built, benchmarks established, documentation in place. The roadmap should mark those transitions and the conditions for crossing them.

In a planning tool like say, Trello, a roadmap can live on its own board - a single board with a list for each major phase and cards representing the key milestones and deliverables within each phase. This isn’t where you track daily work. It’s where you track the shape of the project.

Step three: define milestones

Milestones are the checkpoints on your roadmap. They mark moments where you pause, verify the state of the project and make a conscious decision about whether to continue, adjust or stop.

Most teams treat milestones loosely, as rough dates attached to fuzzy descriptions. “Alpha by September” without any clear definition of what Alpha means. This is a reliable way to reach September, call it Alpha and find out three months later that you weren’t actually where you thought you were.

A useful milestone has three components:

A name and date. Even if the date is approximate, you need one. A milestone without a target date is an aspiration, not a checkpoint.

Explicit completion criteria. Not “all features built” but: which features, to what standard, verified how? A milestone that any team member could independently evaluate as met or not met.

A Go/No-Go gate. An honest answer to: are we ready to move to the next phase? This is where you catch accumulated problems before they become production crises.

For Ironfall, the MVP 1 milestone might look like this:

MVP 1 - Target: End of Month 6

Completion criteria:

• Core melee combat system implemented, integrated and stable in build

• One complete level built to benchmark visual standard, playable start to finish

• Basic progression system (XP, leveling, stat application) functional

• No P1 or P2 bugs open

• Build passes a full internal QA sweep

• Milestone playtest conducted with at least 6 external players

Go criteria:

• Combat feels engaging and responsive per playtest feedback

• No critical technical blockers unresolved

• Team confidence in the plan for MVP 2 is high

• Budget and schedule are within acceptable variance of the plan

That specificity is uncomfortable to write, because it exposes you. If you write it down clearly, you know whether you hit it or not, and there's nowhere to hide. That discomfort is the point.

Those first three steps are about the shape of the project over time - where you’re going and how you’ll know when you’ve arrived. The next steps shift to a different question: what is the work, exactly? The roadmap tells you the destination. The following steps are about understanding everything that has to happen to get there.

Step four: understand the work breakdown structure

Here is where we go from roadmap to actual scope definition.

A Work Breakdown Structure, or WBS, is one of the most valuable practical tools in project management. The PMBOK describes it as a hierarchical decomposition of all the work required to complete the project. In plain English: you start at the finished game and work backward, breaking it down into every major deliverable, sub-deliverable and work package that needs to exist for the game to be complete.

Most teams find this the most uncomfortable part of the planning process, because it makes the scope explicit in a way that reveals how much there actually is to do. Which is, of course, exactly why it's valuable. Better to see the mountain now than to discover its true height at the halfway point.

For games, this translates naturally to an Epics > User Stories > Tasks hierarchy - which is the agile representation of the same idea.

Epics are a large body of thematically related work, too big to complete in one sitting and usually spanning multiple disciplines over multiple iterations. They represent a major feature, system or content area. Think: combat system, progression system, level 1, audio implementation, UI & HUD.

User Stories decompose epics into specific, valuable increments that a team can actually complete in a sprint or a reasonable unit of time. Each story is framed from the perspective of the player or user, capturing what they need and why. We’ll get into the anatomy of a good user story shortly.

Tasks are the last piece of the work hierarchy. They’re specific technical actions that need to happen to complete a story. These live at the level of individual work items that might take a day or two.

For Ironfall, the Combat System epic might break down like this:

Epic: Combat System

• User Story: As a player, I can perform a light attack that deals damage and plays an appropriate animation, so that combat feels responsive and satisfying

• User Story: As a player, I can perform a heavy attack with longer wind-up and higher damage, so that there’s meaningful tactical choice in combat

• User Story: As a player, I have a stamina bar that depletes on attacks and recovers over time, so that I have to manage resources in combat

• User Story: As a player, I can dodge-roll to avoid incoming attacks, so that positioning and timing are meaningful

• User Story: As a player, I receive clear visual and audio feedback when I take damage, so that I understand the state of combat

Each of these is a story, not a task. The tasks live inside each story - things like "implement dodge animation state machine," "hook stamina depletion to attack button press," "integrate SFX trigger on hit confirmation."

The WBS is your scope baseline. Once it exists, anything added to the game is explicitly a scope change, and scope changes have costs, which means they require a real decision.

Step five: write good user stories

User stories are not task descriptions. They're not bug reports. They're not feature requests. They are small, specific, valuable expressions of what someone needs from the system and why.

The standard format, from Mike Cohn’s User Stories Applied and widely reinforced by agile practice, is:

As a [type of user or player], I [need or want something], so that [I can achieve some goal or experience some outcome].

The “so that” is the part most people skip. It’s also the most important part. Without it, you don’t know whether a story was successfully implemented - you just know whether the technical work was done. With it, you have a way to evaluate whether the implementation actually serves its purpose.

What makes a user story good? The INVEST criteria - which has been around long enough that I’m slightly embarrassed to still be citing it - remains genuinely useful:

Independent - ideally, the story can be developed and tested without requiring another specific story to be done first. Dependencies exist, but stories should minimize them.

Negotiable - the story describes an outcome, not a solution. The specific implementation is a conversation between game director and relevant discipline developers, not a prescription.

Valuable - the story delivers something that matters to a player or to the project. A story with no clear value for a player or stakeholder is a task masquerading as a story.

Estimable - the team should be able to estimate it. Stories that can’t be estimated are usually too large or too poorly understood.

Small - a story should be completable within a sprint. If it can’t be, it needs to be broken down further.

Testable - you can verify, objectively, whether the story was done. This is where acceptance criteria come in.

Step six: articulate conditions of done and acceptance criteria

Every user story needs two things before it’s ready to be worked on: a Definition of Done that applies to all stories on the project, and acceptance criteria specific to this story.

The Definition of Done answers: what does “complete” mean for any piece of work on this project? This is a team-wide agreement, not a per-story invention. A typical Definition of Done for Ironfall might be:

• Code reviewed and approved by at least one other team member

• Audiovisual content reviewed and approved by relevant discipline lead

• Feature integrated into the main build and confirmed to work in context

• All related assets (art, audio, animation) integrated, not placeholder

• No new P1 or P2 bugs introduced

• Tested in the current build at the target performance budget and memory limits

• Story accepted by the product owner or game director

That last line matters. A story isn’t done when the developer says it’s done. It’s done when someone has evaluated the implementation against the acceptance criteria and confirmed it meets them. This distinction sounds bureaucratic. In practice, it prevents enormous amounts of debt from accumulating silently.

Acceptance criteria are the specific conditions that must be true for this particular story to be accepted as complete. They should be written before work begins, in a format that makes evaluation unambiguous.

For the dodge-roll story above in our Ironfall combat system:

Acceptance Criteria:

• Player can trigger a dodge-roll by pressing the designated button, provided stamina is above the minimum threshold

• Dodge-roll consumes a defined amount of stamina on activation

• Dodge-roll direction corresponds to the current movement direction or, if stationary, faces away from the nearest enemy

• Player is briefly invincible during the roll animation (frames 4-12)

• Appropriate animation plays without clipping or t-posing on all tested terrain types

• Input buffer handles dodge input during attack animations without ignoring or doubling

• Performance cost of the feature is within the frame budget on the minimum spec target machine

These are conditions, not descriptions. They’re the basis for a conversation between developer and product owner at the moment of review.

Step seven: build the backlog

The backlog is not a list of everything you want in the game. It is a prioritized, estimated, ready-to-work set of user stories that represents the known plan for the project at this moment.

Building the backlog properly takes time and requires a little discipline. Here’s how I think about it:

Start with epics and then break them down. Don’t try to write every story before you have the epics clear. The risk is fragmentation - spending days writing stories for a system that might get cut or restructured at the epic level. Get the epic structure right first, then decompose the highest-priority epics into stories.

Not everything needs to be story-ready immediately. Future epics can stay at the epic level until they move closer to the work horizon. The practice of keeping near-term work detailed and far-term work rough is called progressive elaboration, and it’s one of the more honest things agile planning does - it acknowledges that your understanding of distant work is inherently lower-fidelity.

Stories need to be "ready" before they're "done." Ready means: the story is written, estimated, has acceptance criteria and has no unresolved dependencies that would block it from starting. In agile practice this is sometimes called the Definition of Ready. It's the complement to the Definition of Done. A story that isn't ready shouldn't be pulled into a sprint.

Step eight: prioritize the backlog

Backlog prioritization is where a lot of teams lean on MoSCoW - Must have, Should have, Could have, Won't have - and stop there. MoSCoW is a fine starting framework, but it has a tendency to produce arguments at the Must/Should boundary, and it doesn't help you sequence within a priority tier. Knowing that ten things are all Musts doesn't tell you what to build first.

I wrote about prioritization techniques in a separate piece, so I’ll stay high-level here. The approach I want to add to MoSCoW is a value/effort matrix, which gives you the sequencing inputs that MoSCoW lacks.

The logic is simple:

Draw a 2x2. X-axis is effort (high to low). Y-axis is value (low to high). Plot your stories or epics.

The quadrants:

• High value, low effort - do these first. They are your quick wins and your early momentum builders.

• High value, high effort - plan these carefully. They’re your core investments. Understand dependencies and technical risk before committing.

• Low value, low effort - defer or deprioritize. Easy to do, but not important.

• Low value, high effort - cut or move to the Won’t have bucket. These are traps.

For Ironfall, the core combat loop stories (dodge, attack, stamina management) are high value and, assuming the team has done some prototyping, manageable effort. They go first. A cosmetic equipment preview UI might be low value and relatively low effort - nice to have, but not blocking anything. An elaborate multiplayer invitation system would be high effort and, for this game, low value. That one probably won’t be implemented.

The value dimension here is player value as filtered through the creative pillars. Stories that directly advance the core experience the game is trying to create are high value. Stories that are tangential, nice-to-have or system-level (important, but not directly experienced by the player) sit lower on the value axis and should be sequenced accordingly.

One thing I want to name directly: prioritization is not a formula. MoSCoW and the value/effort matrix are tools for structuring a conversation, not algorithms that produce a right answer. The actual prioritization decisions are made by people, using judgment, with the vision and the creative pillars as their primary reference. If a story advances the pillars, that is evidence for priority. If a story doesn’t clearly connect to the pillars or the milestones, that is a question worth asking.

Step nine: estimate the backlog

Estimation is one of the most discussed and least-understood topics in software and game development. Entire books have been written on it. Mike Cohn’s Agile Estimating and Planning is probably one of the most practical. I’ll give you the version that I believe applies to small indie teams.

First, a distinction that matters: estimating is not scheduling. Estimating is about understanding the relative size and complexity of work. Scheduling is about determining when that work can realistically happen. Confusing the two is one of the most common sources of planning dysfunction I've seen.

Story points vs. hours

In agile, using story points is a common way of estimating work. Story points are a relative measure of complexity, effort and uncertainty - not time. The key word here is relative. You’re not saying “this takes three hours.” You’re saying “this is about twice as complex as that.” That distinction matters because us humans are not great at estimating absolute time but reasonably good at comparing things to each other. Ask a developer how long a feature will take and they’ll give you a number that’s very often wrong. Ask them whether it’s more or less complex than something they already built and they’ll give you something you can actually use.

In practice, you calibrate against a reference story. For Ironfall, the team might agree early on that implementing the basic health bar UI is a 1 - it’s well-understood, straightforward, no surprises expected. From there, everything else gets estimated relative to that. The combat parry mechanic - with its input window, animation state machine, hit detection timing and feedback triggers - is probably a 5 or a 6. The full dialogue system, with branching logic, localization hooks, speaker portraits and integration into the narrative state manager, is probably an 8, maybe more, and the team should talk about whether it needs to be broken down further before anyone starts work on it. An 8 is almost always hiding a conversation that hasn’t happened yet.

Hours are an absolute measure of time. Unless they have a great deal of experience with the subject and working together, teams that estimate in hours tend to be optimistic about productivity (they forget meetings, context-switching, interruptions and the basic reality that development work rarely goes exactly as planned).

For small indie teams, I generally recommend estimating in story points using the Fibonacci sequence (1, 2, 3, 5, 8, 13) because the gaps between numbers on the Fibonacci sequence reflect something true about uncertainty: the bigger a piece of work, the less confident you should be in your estimate, and the Fibonacci gaps widen to reflect that.

The Fibonacci values:

• 1 - trivial, very well understood, no surprises expected

• 2 - simple, clear, minimal uncertainty

• 3 - moderate complexity, some unknowns

• 5 - meaningful complexity, requires careful thought

• 8 - large and/or uncertain, should consider splitting

• 13 - too big or too uncertain to work on directly

If your team estimates a story at 13, that is the estimate telling you to do more discovery work before attempting the story, not a signal to put it in the sprint anyway.

Planning poker

The practical mechanism for team estimation is planning poker, or some informal version of it. The team gathers around the backlog, someone reads a story, everyone thinks about it briefly and then simultaneously reveals their estimate. Differences trigger a conversation: why did the engineer think 5 and the designer think 2? Usually it's because they're imagining different implementations or one of them knows something the others don't. That conversation is the real value. The estimate that results is a product of shared understanding, not individual guesswork.

For a five-person team at Ironfall, planning poker might happen online or in person. The important thing is that estimation is done together and that estimates are not assigned by one person to another. A developer estimating someone else's work has limited information. Estimation is a collaborative act.

For transparency, there are many other ways of estimating the backlog. I like this one because it’s proven and highly collaborative. As with so many of these activities: the real value is in the dialog between teammates.

Velocity

After your first two or three sprints, you’ll start to have a sense of your team’s velocity: the average number of story points completed per sprint. This is the number that drives your release planning.

If the Ironfall team typically completes about 30 points per two-week sprint and the backlog for MVP 1 contains 180 points of Ready stories, you’re looking at roughly six sprints to complete MVP 1 - about twelve weeks of calendar time. That’s probabilistic, not deterministic. Some sprints will be better, some worse. But it gives you a real number to plan against, derived from actual team performance rather than optimistic assumptions.

This is very different from building a schedule by adding up individual estimates and multiplying by a confidence factor. That kind of schedule-building is essentially hope formatted as a spreadsheet. Velocity-based forecasting is empirical. It says: here is what this team has actually demonstrated they can do and here is what the math suggests about the future. With that comes appropriate uncertainty and honest conversation about it.

One thing I want to draw attention to: early velocity numbers are less reliable than later ones. In the first sprint or two, the team is still getting oriented, the tooling isn't fully set up, the stories might not be as well-defined as they'll be later. Don't anchor to early velocity numbers too aggressively. Let them stabilize over three or four sprints before making hard forecasts against them.

Step ten: note dependencies

Dependencies are probably the most under-documented aspect of backlog planning in small teams. And they are one of the most reliable sources of blocked work, wasted time and invisible critical path problems.

A dependency exists when story B cannot be started (or completed) until story A is done. These come in several varieties:

Technical dependencies - the most common. A feature can’t be implemented until a system it relies on exists. In Ironfall, enemy AI behaviors can’t be polished until the enemy health and damage system is implemented. Enemy encounters can’t be designed in levels until the enemy AI behaviors exist.

Asset dependencies - common in games and often underestimated. The combat animation system is only testable once the combat animations exist. The audio implementation for combat feedback can’t happen until there’s placeholder audio, at minimum.

Design dependencies - a systems design document needs to exist before the engineering implementation begins, or the engineer is building against assumptions that may not match what the designer intended.

External dependencies - work that is blocked on something outside the team. A middleware integration blocked on a license. An outsourced asset package blocked on vendor delivery.

What this looks like in practice: you pull a story into a sprint, the engineer starts work and somewhere around day two or three they discover they can't finish it because something else isn't done. The story gets pushed. The sprint fails to complete. Velocity suffers. Morale takes a small, unnecessary hit - and the frustrating thing is that the block was visible in advance if anyone had mapped it. That's the cost of undocumented dependencies, and it compounds across a production.

At the roadmap level, think about inter-Epic dependencies. If the Progression System Epic depends on the Combat System Epic being stable first, that dependency should be visible on your roadmap. It shapes sequencing at the macro level just as story-level dependencies shape sprint planning at the micro level.

Step eleven: visualize effort by discipline

One of the planning blind spots I see most often in small teams is aggregating all the work together without looking at how that work breaks down by discipline. A backlog that looks perfectly sized at the aggregate level can contain brutal imbalances - one person overloaded while another is waiting for work.

Let’s use Ironfall again as an example. Say the work is for MVP 1. After you’ve written and estimated all the stories, you take a pass at mapping them to discipline: Engineering, Art, Design, Audio, Narrative (or whatever disciplines your specific team has). Add up the estimated points per discipline.

Something like:

Now cross-reference with your team composition and availability. If you have two engineers and one artist, the engineering work is distributed across two people while the art load falls entirely on one. Given your sprint velocity, is the art workload realistic in the MVP 1 timeframe alongside the engineering dependencies that require art to unblock them?

If the answer is no, you have three options: reduce scope (cut or defer art-heavy stories), increase art capacity (outsource, or bring in support) or extend the timeline. Those are real tradeoffs, and this analysis is how you see them before they surface as a production crisis. A simple spreadsheet works fine for this - it doesn't require sophisticated tooling.

A simple and practical Trello setup

I’ve been referencing Trello throughout, so let me be a little more specific about how I’d set it up for Ironfall.

A quick disclaimer: Trello is one of dozens of tools that can do this job. Jira, Linear, Shortcut, Notion, Height, ClickUp - any of them can accommodate this structure. I'm using Trello here because it's free, simple and a good teaching example. Don't let tool selection become a two-week conversation. Pick something, set it up, start working.

Board 1: Roadmap

One board, big picture. Lists represent phases or major milestones. Cards represent key deliverables, milestones and major dependencies. Think of it as your strategic view - the shape of the whole project at a glance. Each card at this level represents a milestone or major deliverable, not a user story. You update this board when major things change and review it at each milestone. Daily work doesn't live here.

Board 2: Backlog

This is where stories live before they enter active development. Structure it as lists representing the state of readiness: Epics (not yet broken down), Icebox (broken down but not yet prioritized), Ready (written, estimated, acceptance criteria defined, no blocking dependencies) and Archived (cut or deferred). A story moves from left to right as it becomes more ready to work on.

Board 3: Sprint Board (if using Scrum) or Kanban Board (if using Kanban)

This is where active work lives.

For Scrum, the lists are: Sprint Backlog (committed this sprint), In Progress, In Review and Done. A new sprint means either a new board or a reset of this one. Cards in Done at the end of the sprint have met the Definition of Done - not just been declared finished by the developer working on them.

For Kanban, the lists are: Ready (to pull from), In Progress, Blocked (optional), In Review and Done. Work flows continuously. A WIP limit on the In Progress column - something like 6-8 active stories for a five-person team - keeps the board honest and surfaces blockers before they compound.

Card anatomy (every story card should have):

• Title: The user story statement

• Priority tier: Must, Should, Could

• Milestone: MVP 1, MVP 2, etc.

• Estimate: in story points

• Description: Context, design notes, links to relevant docs

• Definition of Done: copy/paste it each time

• Acceptance Criteria (as a checklist): specific, evaluable conditions

• Tasks (in comments): specific technical sub-tasks (optional, but useful for complex stories)

• Discipline labels: Engineering, Art, Design, Audio, Narrative, etc.

• Members: @ whoever is working on this

• Due date: Target completion, if applicable

• Attachments: Links to design docs, reference images, spec sheets

For dependency tracking in Trello specifically, since Trello doesn’t have native dependency linking, I use a simple convention: in the card comments, I add a comment named “Blocked by:” listing the card titles and links of blocking stories. When a blocking story moves to Done, the developer checks their cards to see what they’ve unblocked, and updates accordingly.

It’s not perfect. But it’s visible, shared and costs nothing.

Getting started with your first sprint or initial Kanban body of work

You've written the vision. You've built the roadmap. You've defined the milestones. You've created the backlog, written the stories, added acceptance criteria, estimated and prioritized. Dependencies are mapped. Now: how do you actually start?

If you’re using Scrum:

Pull the highest-priority, dependency-clear, fully Ready stories from the backlog that your team can realistically complete in two weeks. Target roughly your expected sprint velocity, but since you don’t have a velocity yet, you’ll have to make an educated guess. For Ironfall’s five-person team, starting conservatively at around 25 points is reasonable guesstimate for the first sprint.

Hold a sprint planning session. Walk through each story. Confirm understanding of acceptance criteria. Break down tasks for each story. Assign initial ownership. Confirm that everyone knows what they’re doing on day one.

At the end of the sprint, hold a sprint review, demo what was completed, evaluate against acceptance criteria, accept or reject stories, and have a retrospective: what worked, what didn’t, what do we change? These are not optional ceremonies. The retrospective especially is one of the highest-leverage improvement mechanisms available to small teams and I will forever agree with Clinton Keith’s framing that the willingness to surface and act on honest team feedback is what separates studios that get better from studios that just keep going.

If you’re using Kanban:

Select a body of work from the top of the Ready backlog. How much? Enough to fill the team’s current capacity without exceeding the WIP limit. For Ironfall with five people, a WIP limit of around 6-8 active stories across the team is a reasonable starting point: enough that no one is idle, not so many that everything is in progress simultaneously and nothing is completing.

Work flows through the Kanban board continuously. When a card moves to Done and is accepted, a new card can be pulled from Ready. The team meets regularly - at least twice a week for a small indie team - to review the board, surface blockers and discuss upcoming work.

Kanban’s strength is its flexibility for work that doesn’t fit neatly into two-week boxes. If your development model is more continuous than sprint-shaped or if you’re in a phase like closing or live operations where the work is highly variable, Kanban is often the better fit. In the production methodologies article, I talk in more depth about when to choose Scrum, Kanban or a hybrid, that’s the place to go for a more complete discussion of the tradeoff.

What the first week should not look like:

The first week should not look like continuing to plan. The first week should look like building. If you've done the work above - vision, roadmap, milestones, backlog, prioritization, estimation, dependency mapping - you have enough to start.

The plan will evolve. It always does. That’s fine. The agile manifesto’s point about responding to change over following a plan doesn’t mean the plan was wasted. It means the plan did its job by getting you oriented and moving and now it serves as the thing you update when reality arrives.

A note on what you haven’t planned yet

If you’ve worked through everything above, you have a solid project plan foundation. But I want to touch briefly on what isn’t in here, because the full picture of a production-ready project plan is larger than what we covered. And we covered a lot.

Staffing planning: how you’ll build and manage the team over time is its own topic, with its own timing considerations and tradeoffs. You can learn more about it here and here.

Risk planning: how you identify, document and respond to the things that could go wrong is something I’d argue is as important as any of the above. I wrote about this in the PMP best practices piece and covered risk registers in more depth separately (below). The short version: if you don’t have a risk register by the time you start your first sprint, you should.

Quality planning: your testing approach, standards, processes and tooling needs to be decided before you’re in production dealing with a bug backlog that nobody planned for. I also wrote an article about this. Feel free to check it out.

Communication planning, financial planning, team chartering and role definitions all belong in the full picture too. I still haven’t got to these.

None of these is optional. But none of them should block you from getting started on what we covered here. Do them in parallel, not instead.

What planning actually does

I want to close on something that’s easy to miss if you approach planning as a compliance exercise.

Planning is not primarily about producing documents. It is about generating shared understanding. When you and your team go through the work of writing stories, estimating them together, mapping dependencies, choosing what goes first and why - you’re not creating a backlog. You’re having the conversations that would have happened anyway, but on a bad timeline: in the middle of a sprint, under pressure, when someone discovers that two people had completely different mental models of how a system was supposed to work.

The plan surfaces misalignment early, when it’s cheap. It surfaces ambiguity early, when it’s resolvable. It creates a shared language for talking about the work and a shared reference for making decisions.

The Ironfall team, at the end of a well-run planning process, doesn't just have a Trello board. They have a shared picture of what they're building, in what order, to what standard and why. When something goes wrong - and something will go wrong - they have a foundation from which to respond rather than just react.

That’s what a good plan does. It doesn’t prevent uncertainty. It gives you a coherent place to stand when uncertainty arrives.

If this was useful, you might also like:

There’s a studio I know of that had a lovely values document. A thing of beauty. Thoughtfully written, professionally designed, genuinely good intentions behind it. It talked about trust, honesty, creative courage, all the right words. They printed it and put it up on the walls. They sent them to candidates as part of the offer package.

And then… the creative director systematically dismissed every single idea that wasn’t theirs. A senior developer got quietly pushed out after raising a legitimate concern with HR about a colleague’s inappropriate behavior. A QA analyst got fired for proposing improvements to the production plan. And one of the teams stopped flagging problems in reviews because the last person who did had a very bad week afterward.

The printouts of the values were still on the wall.

I’ve been in this industry for quite a while now and I’ve seen some form of this story play out in studios large and small, funded and bootstrapped, first-time founders and veterans who really should have known better. The language around culture has gotten more sophisticated over the years, sometimes too sophisticated, but the underlying failure is almost always the same: people confuse the articulation of culture with the thing itself.

Culture is not what you write down on a slide that gets buried in the Wiki. It’s your behavior. And its consequences.

What culture actually is

The simplest definition I’ve found and the one that lines up best with what I actually observe in studios, is that culture is the set of behaviors that get rewarded, tolerated and punished in your organization. Not the behaviors you intend. The behaviors that are actually reinforced, day after day, in real interactions, real decisions and real consequences.

Edgar Schein, one of the foundational organizational psychologists on this topic, described culture as operating on three levels: the visible artifacts and behaviors (the office, the documents, the dress code, communication styles), the espoused beliefs (what people say they value, their aspirational ideals) and the underlying assumptions (the actual, often unconscious, beliefs that drive behavior).

His observation, which has held up across decades of research and in my experience at basically every studio I've worked in, is that the underlying assumptions are the ones that actually run the place. And they are almost always invisible until something goes wrong.

What this means in practice is that culture isn’t primarily a communications problem. You can communicate your values with total clarity and still have a culture that looks nothing like them, because the real culture is being communicated through a thousand smaller signals: who gets promoted, whose ideas get taken seriously, how leadership responds to bad news, whether people who make mistakes are coached or scapegoated, whether someone can say “I don’t know” in a meeting without it costing them something.

For a small indie studio, this is both more urgent and more manageable than it is in a large organization. More urgent because in a team of ten, one person with deeply misaligned values can contaminate the entire working environment. There’s no buffer. There’s nowhere to hide from it. More manageable because the culture is being set by a very small number of people and interactions and you have real leverage over those if you’re intentional about it.

The question is whether you’re actually being intentional about it.

Why it matters more than you think

You might reasonably wonder why I’m spending this much time on something that isn’t directly about making the game. Here’s my honest answer: I’ve come to believe, over a long time and a lot of shipped and unshipped projects, that culture is one of the primary determinants of whether a studio succeeds. Not the only one, mind you. Luck, market timing, product quality, all of that matters. But culture is upstream of most of those things.

A team with strong psychological safety runs better playtests. Not because they have a policy about it, but because people actually say what they think about the game, which means the team gets better information, which means the game gets better faster. A team where blame is distributed freely and fairly runs into the same information problem a bad culture does, except in reverse: nobody tells you the system is broken because the last person who did was blamed for the system being broken.

A culture where “drive” and “passion” are used as cover to normalize overwork will burn out its best people first. In my experience it’s almost always the most committed developers who break first when the environment is unhealthy, because they care enough to work past the point where smarter people would have stopped.

A culture where the founder is the unquestioned creative authority and every decision flows through them produces a studio that can’t scale past the founder’s personal bandwidth, which is going to become a problem somewhere around month eighteen of a three-year production.

I’ve seen bad culture kill games that were genuinely good, and I’ve seen mediocre games shipped successfully by teams that trusted each other, communicated well and knew how to move together under pressure.

What good and bad look like

Good culture in a small studio tends to have some consistent properties, though it doesn’t look identical in every case.

Problems surface quickly. When something is going wrong, people say so early and the response is collaborative rather than defensive. This is the output of psychological safety, which Google’s Project Aristotle research identified as the single most important predictor of team effectiveness across hundreds of teams. It’s also what Patrick Lencioni was pointing at in his model of team dysfunction: when trust is absent, everything downstream gets corrupted.

Feedback is direct, specific and two-directional. People give and receive feedback without either softening it to uselessness or delivering it like an accusation. Leaders get feedback too. And act on it visibly, which is the part that actually matters.

The game’s creative vision is shared, not held. The game director owns the vision, but the team understands it well enough to make good decisions within it without escalating everything. A team that knows what the game is trying to be can move fast and with confidence. A team that doesn’t know, or isn’t sure if they’re allowed to interpret it, waits. And waiting in a small studio is expensive. Creative disagreement happens, regularly and visibly, but it ends with a decision. Not a consensus. Not a vague agreement to think about it. A decision.

People understand the financial reality of the studio. Not necessarily the accounting line by line, but they know roughly what the runway looks like, what’s being worked toward and what the stakes are. Founders who hide this, usually out of a well-intentioned desire to protect the team from stress, tend to produce teams that are surprised at the worst possible moment.

Bad culture in a small studio is often more dramatic than in large organizations, because there’s nowhere for it to go except directly into the work.

The founder is the cultural weather system. When they’re in a good mood the studio is in a good mood. When they’re anxious or under pressure, everyone feels it, adjusts their behavior accordingly, and the information that reaches the founder becomes filtered through whatever they think the founder wants to hear. This is one of the most common and most destructive patterns I see in first-time founders. They don’t realize they’re setting the temperature.

The “brilliant jerk” is tolerated. The senior developer who produces excellent work and treats colleagues with contempt is not an asset. They’re a structural risk. The work they produce doesn’t compensate for the behavioral permission their presence grants to everyone else, or the signal it sends about what the studio actually values.

Crunch is normalized and not examined. I’m not categorically opposed to periods of intense work. Anyone who’s shipped a game knows there are moments where this might be necessary. But studios where crunch is the default rather than the exception, where “passion” means working until you break and “dedication” means giving up your life indefinitely, are practicing a form of resource extraction that eventually catches up with them. The developers leave, or burn out, or stay and quietly stop caring. Any of those outcomes is bad.

Conflict avoidance masquerades as harmony. A team that never disagrees in meetings isn’t a healthy team. They’re having the disagreements elsewhere, in side channels, in resentment, in decisions that go unmade. The absence of visible conflict is not the same as alignment.

Some examples worth examining

Riot Games in its early years built something genuinely unusual. The studio’s culture was organized around player experience as a first principle, and that orientation was strong enough to inform decisions at every level of the organization. I observed it closely during my time there. The belief that strong culture enables trust which enables teams to focus on the work rather than organizational politics was not just a value statement, it was operationally real.

It was also eventually tested. The same cultural intensity that produced exceptional commitment from early employees created an environment that, by the time the studio reached several thousand people, had significant blind spots. The culture had calcified. What had been an authentic shared orientation became, in some pockets of the organization, a kind of cultural gatekeeping. The lesson I take from this isn’t that Riot’s early culture was wrong. It’s that culture at scale requires deliberate maintenance and the attributes that make a culture strong in a small studio can become brittle if they’re not actively examined as the organization grows.

Telltale Games is a harder story. A studio that built some of the most emotionally resonant games of its era and collapsed painfully. The postmortem accounts describe an organization under constant delivery pressure, with a culture that normalized unsustainable working conditions. The games were extraordinary. The studio didn’t survive. Both things are true. The pattern is worth seeing: passion and craft, in the absence of organizational health, eventually consume themselves.

For a smaller example, look at Noble Steed Games, a small Australian studio that published their culture book publicly a few years ago. What strikes me about it is the preface, written by their studio director, Reuben Moorhouse. He opens by saying he’s seen a lot of culture documents and his reaction to most of them is that they sound like bullshit. And then he explains what they’re doing differently: every value in the document is accompanied by the specific policies and practices that enact it. Not aspirations: mechanisms. An anti-crunch policy. Pay transparency. Structured purpose meetings. The culture book as a form of institutional accountability rather than institutional aspiration. That’s definitely the right orientation.

Outside games, the most clarifying example I know of is still Netflix. Whatever you think of the company, their culture document (which I believe they evolved over the years), originally written by Reed Hastings and Patty McCord, articulated something genuinely useful: that the actual culture of an organization is defined by who gets promoted and who gets let go, not by what anyone says about values. Harsh, yes. But the underlying insight is sound: culture is what you actually practice, including the hard parts.

Building it: what actually works

Let me be clear about something before getting into the process. I’ve facilitated culture workshops with studios and senior leadership teams at various points in my career. The thing that makes them succeed or fail has almost nothing to do with the workshop itself. It has to do with what happens before it (commitment, humility, a genuine desire to build a healthy culture) and what happens after it (walking the walk). The workshop is the middle part. Treat it that way.

Step one: do the personal work first.

Before any group conversation, every founder should answer a handful of uncomfortable questions in writing, separately. Why are you building this studio instead of just taking a job? What do you want this place to give you that you don’t have? What kind of success would leave you feeling empty? If you have co-founders, each person does this independently, then you compare and have a conversation about it. You’re not looking for identical answers. You’re looking for compatible ones, and for the tensions that need to be named before they surface at a bad moment.

The values you’re about to articulate should come from something real. If they feel slightly uncomfortable to say out loud, you’re probably getting closer to the truth. If they feel perfectly polished and inspirational, they’re probably aspirational rather than actual.

Step two: run the workshop.

Block a half day with the founding and senior team. Start by asking each person to name two or three things that matter most to them in a work environment. Write everything down. You’ll start to see clusters immediately, and you’ll surface the first tensions. Then break into small groups (if there are enough participants for that) and ask each group to describe the ideal working environment for this specific studio, making this game, with these specific people. Two questions that tend to unlock real answers: “what needs to be true for you to consider this studio’s culture exceptional five years from now?” and “what would absolutely never happen here if the culture was healthy?” The second question is usually more revealing than the first.

From the discussion, identify three to five core values the full team has actively participated in naming. Not six, not eight. People can’t genuinely internalize that many things and you end up with a list nobody uses. Then, for each value, define what good and bad behavior actually looks like in concrete, observable terms at this specific studio. “We value transparency” is not useful. “When something is going wrong with the production, the person who knows about it raises it at the next standup rather than waiting for it to become a crisis” is useful.

Step three: translate values into mechanisms.

This is the step most studios skip and it’s the most important one. For every value the team has identified, answer one question: what would someone observe in this studio, on an ordinary Tuesday, that shows this value is real? If you can’t answer that concretely, you don’t have a value yet. You have an aspiration.

Noble Steed got this right. Every stated value in their culture book is paired with specific policies and practices that enact it. That’s the model. A practical way to get there: map each value against what you’re actually doing today versus what you want to be doing. The gap between those two things is your roadmap. Assign a specific owner to closing each gap, and a follow-up date. Not “the founders will figure it out.” One person’s name.

Step four: socialize it and keep socializing it.

New hires should understand the culture through how they’re onboarded, not just through a document. The culture is transmitted through behavior. The founder references the values in real decisions. The team sees them invoked when something hard happens. Over time that builds a shared vocabulary that actually does what values are supposed to do: makes hard decisions easier without relitigating everything from first principles. Publishing the culture document publicly, as Noble Steed did, is worth considering. It creates external accountability and signals something to candidates before they ever apply.

Step five: measure it and act on what you find.

The question “how is our culture doing” needs real data, not the founder’s intuition, which is subject to significant bias toward what they want to believe. A short quarterly pulse survey is more useful than an annual all-hands conversation. A few questions worth asking regularly: Can I raise a concern about the project without worrying about how it will land? Do I understand what this studio is trying to create and why? Does the way we actually work match what we say about our culture?

Tracking honest answers to those over time will show you where the culture is healthy and where it’s drifting. When the data shows something uncomfortable, something changes. Visibly. That’s the part that determines whether any of this has credibility.

Which brings me back to the brilliant jerk. If the most talented developer on the team treats colleagues with contempt and you tolerate it because they’re too valuable to lose, you’ve communicated something very specific: that performance is the exception to the culture. Everyone sees this. And it changes how they behave in ways that will cost you far more than whatever that person was contributing.

A word on timing

The most common mistake with culture in early studios is treating it as something to figure out later, once the team is bigger, once the game is further along, once there’s more to go on. The reasoning feels practical. It’s exactly backwards.

Culture sets early. The patterns established in the first few months, the way decisions get made, the way people talk about the work, whether people feel safe raising concerns, all of this calcifies faster than you’d expect. By the time you have a team of fifteen, the culture is already substantially formed. You can change it, but it requires real effort and real disruption. The time to think about it is now, not as a distraction from the game, but as a prerequisite for the game being good.

A studio’s culture eventually shows up in the product. Not literally, not as a direct translation, but in the care that went into the details, in whether the team trusted each other enough to push the design to the edge of what was possible, in whether people felt safe saying “this isn’t working yet” until it actually worked.

You’re building a place where people will spend a significant part of their lives working on something they care about. Most of them won’t remember the values document. They’ll remember how it felt to work there.

If this was useful, you might also like:

Contradiction o’clock

The games industry is simultaneously at its highest revenue ever (roughly $196 billion in global content sales in 2025) while also experiencing one of the most brutal human catastrophes in its short history.

One in three developers laid off in two years (1). Nearly 44,000 jobs gone since 2022. Students being told by their own professors they probably won’t find work in the field they’re training for.

Revenue up. People out. That’s the headline. Everything else flows from that flagrant contradiction.

What’s actually happening (according to me)

The industry didn’t just hit a rough patch. It underwent a structural transition and most of its leadership didn’t understand what they were living through until it was too late.

For thirty years, the games business ran on a simple growth engine: each console generation brought in new players, and a larger audience meant more revenue almost automatically. The market was always expanding. That’s the context in which the industry learned to operate, where bigger bets made sense because the pool of potential players kept getting deeper.

That engine stopped working somewhere around 2019-2021. The addressable audience for traditional games in mature markets had plateaued (and possibly started contracting). My read is that the pandemic disguised this reality: captive audiences and cheap money made the old model look healthier than it was, and the industry responded by hiring and spending as if the growth were real and permanent. When the pandemic tailwind disappeared, the underlying reality was still there waiting. That’s not a rough patch. That’s a business built on an assumption that is unfortunately no longer true.

So, the deeper issue here is that the audience for traditional games is not growing (2, 3). In the US, the number of people playing games has fallen below pre-pandemic levels. And the hours that used to go to games are not just sitting there waiting to be recaptured. They're going to TikTok, to sports betting apps, to YouTube, to OnlyFans - yes, really. Americans now spend 122 million more hours per day on social media than they did in 2020. TikTok alone accounts for 39 million of those daily hours. The competition was never really other games. It's algorithms and platforms designed by people who are very, very good at capturing attention and have no intention of giving it back.

The demographics of new players skew younger and younger, and those younger players aren’t buying $70 premium titles - they’re entering the gaming landscape through Roblox, Fortnite or whatever their friends are on. These are not games in the traditional sense. They’re social infrastructure. And you cannot compete with social infrastructure by making a slightly better version of what you already make.

Meanwhile, the games that do capture those young players (again, the Robloxs, Fortnites, Minecrafts of the world) function more like platforms than games. They obey Metcalfe’s Law: the more people use them, the more valuable they become to each user, which draws in more users. This creates a gravitational pull that makes it really hard for new entrants to compete for the same audience. When Concord launched, it didn’t just underperform. It generated nothing. Not a whisper. That was unthinkable five years ago. It’s the new normal now.

The macroeconomic dimension

The games industry analysis you typically read treats the sector as if it exists in a hermetically sealed environment. It very much does not.

American consumers, the largest gaming market per capita, are financially exhausted. Real wages stagnated for years (5), inflation hit essentials hard, credit card debt is at record levels (4), and the psychological weight of economic precarity suppresses discretionary spending in ways that don’t show up cleanly in quarterly reports but absolutely show up in whether someone buys a $70 game or not. Buying a game isn’t “just” a transaction. It’s a statement of confidence that you can afford to relax, to put your feet up and kick back with a video game. A lot of people can’t make that statement right now.

Regardless of where you land on the political spectrum, it’s hard to deny that the current U.S. administration has added a specific flavor of chaos on top of baseline economic anxiety. Tariffs on hardware components have raised costs for manufacturers and publishers alike (6). The GDC 2026 State of the Industry survey (7) found that 38% of business leaders say tariffs are already impacting their expenses and decisions. Supply chains for physical goods - consoles, limited editions, peripherals - have become unpredictably expensive. Sony is apparently considering pushing the PS6 to 2028 or 2029 (8) partly because AI’s insatiable demand for memory chips is making console-grade memory prohibitively expensive. That’s a staggering downstream consequence nobody had on their bingo card.

But the subtler damage from U.S. political instability is to investment confidence globally. Capital markets hate uncertainty above almost anything else. You can price risk. You cannot price chaos. When trade policy changes based on the mood of one person, international co-productions, licensing deals and platform agreements all become fraught. The GDC data is stark: 60% of non-U.S. industry leaders say current U.S. immigration and political policies have impacted their desire to do business with American companies. People have started canceling travel plans to the U.S. (9). This is a soft but real form of economic decoupling, happening in slow motion, and the games industry is not immune.

The war in Ukraine, now grinding into its fourth year, has removed an entire ecosystem of talented Eastern European developers from easy accessibility - studios in Ukraine, Russia and neighboring countries that were deeply woven into the global co-development supply chain. This is rarely discussed in industry coverage. It should be.

The China question

This is one of the most consequential long-term story in games. And yet, Western industry media treats it like a weather report: noted, filed, forgotten.

Chinese developers now account for 20% of global player spending and roughly 38% of spending growth. Their publishers have captured approximately half of all global player spending growth since 2019 (15). Their share of overseas revenue has grown from 11% to 14% in six years and is accelerating (10). Games like Black Myth: Wukong, Where Winds Meet and Infinity Nikki are not curiosities: they’re signals. Chinese studios are producing games that are culturally sophisticated, technically polished, commercially savvy and developed at a fraction of Western cost structures.

The old Western industry complacency of “they can’t match our quality” is gone. They matched it. Then they undercut it. Then they opened a domestic market of 1.4 billion people that Western developers can barely access due to regulatory barriers.

There’s a painful irony here. Western VCs spent a decade chasing moonshots and tech fads (VR, blockchain, AI) in gaming while Chinese studios quietly mastered the fundamentals: great art direction, solid mechanics, smart monetization and deep community management. The West bet on technology disruption. China bet on craft and scale.

The AI debacle

The generative AI situation in games is a case study in the gap between those who understand how things are made and those who mainly understand profit & loss statements.

The thesis was simple: we’re going to need significantly fewer artists, writers and programmers, use AI to generate assets and code for pennies and pocket the difference (naturally, the people making these decisions found more sophisticated ways to say it). Simple, right? The reality though: generative AI in 2026 is genuinely impressive for specific, bounded tasks like code assistance, brainstorming, marketing copy, a bit of concept art, that kind of stuff. But it’s nowhere near capable of replacing the creative judgment, iterative craft and systemic coherence required to make a good video game.

The GDC data confirms this with unusual clarity: only 5% of AI users in the industry use it for player-facing features. Only 19% for asset generation. The actual number-one use case is research and brainstorming. Management fired the people who knew how to do the work and replaced them with a tool that’s good at helping people think about the work. Let that sink in.

The sentiment numbers tell the real story. In 2024, 18% of game industry professionals thought AI was having a negative impact on the industry. In 2026, it’s 52%. The more developers actually work with these tools, the less they believe the hype. Make no mistake: that’s not technophobia. That’s practitioners accurately assessing what a tool can and cannot do.

This is nothing but a congruent extension of what’s happening with AI at large, outside of the games industry. In a survey from the National Bureau of Economic Research, 80% of companies using AI reported zero productivity gains (13). A study from HBR in which researchers embedded themselves in a mid-sized tech company for eight months revealed an increase in both defect rates, as well as employee burnout (14). A study from a group of researchers at Remote Labor Index (RLI) measured the effectiveness of AI automation in 240 projects across 23 domains of digital freelance work. Thy concluded that AI agents achieved a dismal automation rate of less than 3%.

The Google Project Genie situation is almost farcical. A tool that generates one-minute-long 720p walking simulators - which cannot support crouching, climbing, or shooting - sent gaming stocks into freefall and erased billions in market cap (11, 12). Analysts who actually understand game development called it what it was, but markets didn’t care. This is the cost of having an investor class that is fundamentally illiterate about how games are made. They cannot distinguish between “neat demo” and “production-ready,” so they panic at demos, jump on the hype train and miss the actual structural trends that matter.

The real AI story in games (the one that will matter in five years) is narrow AI applied to specific production tasks: coding assistance, level testing, QA automation, dialogue variation, localization assistance. Not replacement. Augmentation. Small studios that integrate these tools thoughtfully might be able to do more with less. Large studios that used AI as a pretext to gut their creative workforce will find themselves unable to make anything good… and reality will follow in the form of lagging revenue.

The good

There’s genuine creative vitality in this industry. And it’s almost entirely concentrated in the places that institutional money has tragically abandoned.

The AA and indie space is producing the best games anyone has made. Clair Obscur: Expedition 33 is one of the most celebrated games in history and it’s being compared to the golden age of JRPG design. Blue Prince, Split Fiction, REPO, Schedule 1, Peak, Dispatch - these are games made by small, focused teams with creative autonomy and reasonable budgets and players are responding to them with enormous enthusiasm. Infinity Nikki from China demonstrated that a fashion-forward open world game built for a female audience could generate hundreds of millions of dollars in revenue - a market that Western publishers consistently dismissed or misunderstood.

The Nintendo Switch 2 is doing extraordinary numbers (past 17 million units rapidly) proving that when you get the hardware-software relationship right and respect your audience, the market responds. Nintendo is arguably the best-run major company in games, precisely because it has consistently refused to chase trends it doesn’t understand.

The Steam Deck ecosystem has quietly become a fourth major platform. 28% of developers in the GDC survey are already building for it. 40% want to. This is a platform built on openness, developer respect and genuine value for players. And it’s growing. Valve continues to be one of the best-positioned companies in the industry, operating with patience and without the quarterly earnings pressure that drives everyone else’s bad decisions. Unsurprisingly, Valve is a private and not publicly listed company.

Unionization is rising. 82% of U.S. developers now support unionization, up from 60% the year before. This is what systemic exploitation produces. Crunch culture, with 87% of full-time developers doing overtime in the past year, combined with repeated layoffs and broken trust has created the conditions for organized labor to finally take root in an industry that has resisted it for decades. This is ultimately good for the health of the creative workforce, even if it will be contentious in the short term.

The bad

The AAA publishing model continues its well-documented structural crisis and shows little to no signs of self-awareness about it.

The befuddling GaaS moonshot strategy has been catastrophically expensive and almost uniformly unsuccessful. Concord, XDefiant, Suicide Squad, Marvel’s Avengers, LawBreakers, Crucible, Highguard (it’s honestly hard to keep track) - the graveyard of failed live-service games that were supposed to print money forever, is genuinely extraordinary.

Each of these represented hundreds of millions of dollars and years of developer labor. The pattern is identical every time: executive excitement about a recurring revenue model, green light without honest market analysis, massive team assembled, product ships into a market already dominated by entrenched giants and notoriously hard to carve out share of market, monetization model antagonistic to players, nobody plays it, studio gutted or closed. Rinse and repeat.

Discoverability on PC has become a genuine crisis. With tens of thousands of games releasing annually on Steam, the signal-to-noise ratio makes it incredibly hard for good games to find their audiences without either existing IP recognition or viral social media momentum, both of which are largely outside of the developers’ control. Matthew Ball’s observation that mobile spend is “five years flat” and the share of spend going to new releases is at a decade low applies increasingly to PC as well. The rich get richer. Old giants strengthen. New entrants struggle to be seen.

Private investment has fallen 55% year-over-year and is now at a fraction of pandemic levels. The funding ecosystem for mid-sized developers (too large for indie, too small for AAA) has essentially collapsed. Multiple developers in the GDC survey described a gap in the market at their scale: award-winning studios unable to secure development funding despite strong track records. This is a talent and creative capacity that is simply being lost.

Root causes

Most of this traces back to a handful of interconnected failures.

The COVID hiring binge was built on a false premise: that pandemic-level engagement represented a new baseline rather than a temporary spike. Leadership didn’t distinguish between the two because distinguishing them would have required slowing down when money was cheap and optimism was high. Nobody wants to be the person who pumps the brakes at a party.

The obsession with GaaS reflected a fundamental category error: the assumption that because some live-service games made enormous recurring revenue, live-service was a replicable formula. It isn’t. Fortnite, Roblox, League of Legends and World of Warcraft succeeded because they got there first (or nearly first), built communities that became self-sustaining social networks and had the resources to invest in them continuously for years. You cannot replicate network effects by copying features. You needed exceptional innovation and a pound of luck, or you need to be there first. That ship left a while ago, honestly

Investors have generally understood the financial landscape well enough - where the money is, which territories are growing, where the revenue curves are pointing, that kind of stuff. What I put forth is that they've consistently misjudged is the actual opportunity inside games: VR was going to change everything, then the metaverse was going to connect us all, then blockchain was going democratize our time and our digital assets, and now AI is supposed to result in 100x productivity improvements.

Each cycle followed the same pattern: genuine excitement, over-extrapolation of the potential of new technologies, aggressive capital deployment, disappointing returns, quiet retreat (seriously: where are VR, the metaverse and NFTs now?). The underlying mistake is applying a SaaS lens to a creative industry - looking for scalable, recurring revenue models in a space where the best outcomes come from people with genuine creative obsessions who are given time, autonomy and reasonable resources. That's not a pitch deck that funds easily, and the mismatch has cost the industry enormously.

Predictions for 2026… and 2027

No one asked for this, but it’s my Substack, so I’ll share anyway.

The AAA implosion will continue. We look at past behavior to predict future behavior and there are few indicators of change to be found. That said, the studios that have always understood what it takes to thrive at that scale - Santa Monica, Naughty Dog, Rockstar, Sucker Punch, Larian - will continue to do so. They've earned that position through craft, discipline and a clear sense of what they are. A select few others will find their footing. The rest will continue to be in for a difficult time.

At least one major publishers will either merge, be acquired, or undergo restructuring significant enough to constitute effective collapse in their current form. Ubisoft is the most obvious candidate, already partially restructured through its Tencent deal and, quite frankly, still hanging by a thread. There will likely be others.

The studios most at risk are those that have spent five years making GaaS moonshots that didn’t land or won’t land while their single-player franchises atrophied.

GTA VI will be the defining commercial event of 2026. If it performs as expected (and why shouldn’t it? They did it multiple times before), it will set revenue records that will be used to argue both that the industry is healthy (it generated billions) and that the industry is broken (one game captured all the oxygen). Both will be correct.

The Chinese ascent will continue and accelerate. I'd be genuinely surprised if we don't see at least one Chinese title in 2026-2027 to break through to genuine mainstream Western success in a way that can no longer be dismissed as a niche phenomenon. The combination of production quality, sophisticated monetization and enormous domestic market providing development subsidy means Chinese studios can afford to be patient in Western markets in ways that Western studios cannot.

The AA renaissance will quietly become the dominant creative story of the industry over the next two years. The games that critics and players love will increasingly come from studios of 10-50 people with focused visions and lean production. The question is whether the funding and publishing infrastructure to support this tier will materialize or whether these studios will continue to struggle for survival despite making the best work in the industry.

AI will slowly start to settle into its actual role: a genuinely useful productivity tool for rather specific tasks, not a replacement for creative workers. The backlash from players against AI-generated content will intensify further. Studios that used AI as a pretext for mass layoffs will find themselves unable to ship competitive products and will face a talent market deeply skeptical of their intentions when they try to hire back. The studios that integrated AI tools thoughtfully while retaining their creative workforce might find themselves having a competitive advantage in production speed.

Unionization will accelerate. One or two significant strikes or organizing actions at major studios will happen in 2026-2027. This is inevitable given the conditions: repeated layoffs without accountability, crunch culture and a generation of workers who watched their colleagues lose jobs to AI cost-cutting and plain old greed. The question is not whether but when and where.

The geopolitical situation will get worse before it gets better for U.S. based studios. International co-productions will face more friction. Talent from outside the U.S. will be harder to recruit. The industry’s center of gravity will continue shifting toward Eastern Europe and emerging markets for development talent, toward East Asia for market growth. The U.S. will remain important but will represent a declining share of the global gaming economy.

The future of Xbox is tenuous (16). Nadella replaced Phil Spencer, a 38-year gaming veteran whose entire identity was video games, with Asha Sharma, someone whose entire background is AI, platform operations and commerce. That is not the description of someone hired to double down on great games. That's the description of someone hired to rationalize a business unit into a larger platform strategy.

I’m going out on a limb here and predict that the next Xbox will ship - in the next couple of years, RAM willing -, but it won't be a gaming console in any traditional sense. More like an Xbox One but instead of TV with a dash of games, it will be an “AI-driven ecosystem with a dash of games”.

The remaining console hardware situation is genuinely uncertain in a way it hasn’t been since the early days of the medium. The Steam Deck Oled facing stock issues and the PS6 potentially delayed to 2028-2029 because of AI’s memory and GPU demands is not a minor hiccup - it’s a signal that the gaming industry is now operating in an environment where its hardware roadmap is being disrupted by an entirely external technology sector. That’s new and its implications are not fully understood yet.

In closing

The games industry is not dying. It’s sorting itself out after a period of profound mismanagement, delusional optimism and questionable capital allocation. The AAA space remains largely rudderless. AI delusion has cost tens of thousands of people their jobs and careers. Capital continues to flow in the wrong directions. None of that is resolved.

BUT… something else is happening at the same time and it deserves equal attention.

The 2026 Steam Next Fest is, quietly, one of the most exciting showcases of creative ambition I’ve seen in years. Small teams, first-time developers, studios from corners of the world that the industry barely acknowledged a decade ago - making things that are strange and bold and deeply personal. Developers are finding their voice, organizing, pushing back, demanding better. New creative centers are emerging in Latin America, Eastern Europe, Southeast Asia, bringing perspectives and aesthetics that the industry has never had before.

I spent a lot of words in this piece on what’s broken. And it is broken, in significant ways. But I’ve been around long enough and I’ve never been more excited about the bottom-up creative energy that’s building right now. The people who make games because they love making games, who care about craft and artistry and the singular experience of building a world that someone else gets to live in for a while - those people are not going anywhere. And I think, in the end, that love for the work is more durable than any of the structural problems we’re currently living through.

If this was useful, you might also like:

Heads up: the game competitive analysis framework is about a third of the article. The rest is two full sample analyses. While I hope they provide clarity, please treat them as supplementary.

Most competitive analysis in game development defaults to vibes. We play a game, we like it or we don’t, we reverse-engineer a handful of reasons why and we move on. If a game we loved failed commercially, we blame marketing or timing without asking whether the creative work itself was misaligned with its market. A game that aligns with our taste gets credit for things it didn’t actually do well. A game that doesn’t gets blamed for problems that aren’t the real issue.

Neither of those helps you make better decisions about your own work.

The framework I’m presenting here is designed to force analytical rigor. It’s structured in five layers that build understanding progressively: context (what world did the game enter), positioning (who was it for and did it find them), business (did the commercial reality match the ambition), creative experience (does the game deliver on its creative promise) and synthesis (what actually happened and what does it mean). Each layer asks specific questions. Together, I believe they can provide a pretty complete picture of why a game succeeded or struggled.

This isn’t academic. It’s practical. If you’re making a game in a crowded genre, you need to understand why similar games succeeded or failed, and “they had good design” or “the marketing was weak” won’t cut it. You need to know what the actual leverage points were. You need to see where decisions got made that determined outcomes. You need a causal chain, not a scorecard.

I’ve used earlier versions of this framework myself. Not every layer carries equal weight for every game. A game that failed primarily because of positioning doesn’t need a deep creative analysis. A game that succeeded despite weak marketing because the creative work was singular deserves most of your attention on the creative layer. The structure is a checklist of what to consider, not a mandate for equal treatment.

I’m going to walk through the framework first, then apply it to two real games: Inside, by Playdead and Ashen, by A44. Inside is worth studying because it’s a critical and commercial success that did almost everything right and understanding how and why is instructive. In contrast, Ashen is worth analyzing because it’s a good game that got a lot right but also had a few more nuanced issues that kept it from being the success it could have potentially have been.

The five-layer framework

Layer 1: context

Before you touch the game itself, establish the environment it was released into. This is where most analyses move too fast.

Market and genre landscape. What did the genre look like at launch? Was the space crowded, nascent or oversaturated? Who were the direct and indirect competitors? What had recently succeeded or failed in adjacent territory and why might players have been primed or fatigued for this kind of game?

Studio and development context. Who made it and what’s their trajectory? Is this a debut, a pivot, a follow-up to a hit? What were the production circumstances: team size, funding, timeline, engine choice, whether it went through early access? For indie games this layer is often the most explanatory one, because constraints shape decisions more directly than intent.

Platform and distribution. Where did it launch and was that the right call? PC-only vs console day-one, Steam vs Epic vs Xbox Game Pass vs console storefronts, early access vs direct release. Each of these is a strategic choice with real consequences on audience shape and review dynamics.

Timing and cultural moment. Was there a tailwind or a headwind? Did it release alongside a major competitor? Did it catch a cultural moment or miss one?

Layer 2: positioning

Target audience. Who did the studio appear to be making this for? Was that audience well-defined, underserved, or already well-served? For indie games especially, it’s worth asking whether the game had a clear intended player, because the failure mode of many indie games is making something for a diffuse, imagined audience.

Value proposition and differentiation. What was the game’s core pitch? What did it promise to do differently, better or more honestly than alternatives? This doesn’t have to be the marketing pitch. It’s the implied promise the game makes in its first hour.

Discoverability and marketing. How did the game reach people? What was the visibility strategy: press coverage, streamer seeding, festival presence, social media, Kickstarter history, word of mouth? For indie games, discoverability is often more decisive than quality. A good analysis quantifies this where possible (Steam reviews, Twitch peak viewership, SteamDB estimate ranges) and explains the gap between potential and reach.

Reception snapshot. Critic vs player reception, Steam review sentiment, community discourse. Were there specific pain points that emerged consistently? A divergence between critic and player scores often signals something worth investigating.

Layer 3: business

Pricing strategy. Was the price calibrated to perceived value and audience? Mispricing (too high relative to scope, or too low and signaling a lack of confidence) is a common indie mistake. Were there launch discounts, bundles or regional pricing, and did those choices help or undercut the game’s perceived value?

Sales and financial outcome. What do available signals tell us: SteamSpy estimates, developer-disclosed numbers, awards, sequel greenlighting, studio survival? The analysis should form a hypothesis about whether the game was a financial success relative to its likely budget and be honest about uncertainty. “We don’t know but here’s what we think the signals suggest” is valid.

Post-launch support. Did the studio patch and update? Was there DLC and was it well-received? Did they engage with community feedback? Post-launch behavior sometimes reveals how confident the studio was in their foundation and how healthy the relationship with the player base became.

Business model fit. For premium games, the central question is whether the price-to-content ratio held up. But it’s worth also asking: was there untapped value in early access, a cosmetic DLC strategy or a sequel hook that was never pulled? For games that underperformed, could a different model have changed the outcome or was the problem upstream of monetization entirely?

Layer 4: creative experience

Fantasy. Before any loop or system can be evaluated, a game needs to answer a more fundamental question: what does it feel like to be in this game? Every great game is built around a fantasy, not necessarily a narrative one, but an experiential one. The promise of what you’ll become or feel while playing. A game that articulates this fantasy clearly, and then builds every mechanic, visual and sound to serve it, creates an experience players remember and evangelize.

Core loop. Once the fantasy is established, the core loop is the mechanical engine that delivers it. This is the series of actions the game intends you to perform, moment to moment and session to session. What you do, what that produces and how that feeds back into what you do next. Is the loop well-designed? Does it give players clear agency at every step? Is the moment-to-moment execution captivating or does it become rote? Does the loop scale (remain interesting as players develop mastery) or does it plateau quickly?

Onboarding and accessibility. First impressions are disproportionately determinative of retention. How steep is the initial curve? Does the game respect the player’s time and assumed competence? Does it teach through play or through instruction? For indie games, which often lack the QA resources to smooth rough edges, a demanding or confusing onboarding can produce a first-week review score that permanently anchors player perception.

Systems design and depth. How do the game’s interlocking systems create complexity and replayability over time? Where does depth come from: mechanics, narrative branching, procedural generation, build variety, emergent interaction between systems? This is where you assess whether the game has legs, not just a good first hour. Shallow systems can sustain a short, focused experience but become a liability the moment the game asks for more time than it can justify.

Pacing and structure. How is the experience shaped over time? Where does it peak, drag or overstay its welcome? Pacing failures are often invisible in the first session and fatal by the third. A game that front-loads its best ideas and coasts on repetition afterward loses its word-of-mouth precisely when it should be building it.

Art direction and audiovisual coherence. For indie games especially, visual and audio identity punch above their weight in marketing and first impressions. The question isn’t “is it pretty” but “is it coherent and intentional?” A distinctive aesthetic executed with conviction (even a lo-fi or minimalist one) can be more commercially valuable than a generic high-fidelity one, because it creates a recognizable identity that travels through screenshots, trailers and thumbnails before a player ever touches the game.

Narrative and tone. If story is part of the game’s value proposition, how does it land? Does the mechanical experience support or undermine the intended tone? Some of the most interesting failures here aren’t in the writing itself but in the dissonance between what the game says it’s about and what it actually makes you do.

Technical state at launch. Bugs, performance, platform parity. Launching in a rough technical state can be fatal to review scores and word-of-mouth in a way that a patch six months later rarely repairs. The question isn’t just “was it buggy” but “did the technical state signal something about the game’s readiness and how did that shape early perception?”

Layer 5: synthesis

This is what separates a teardown from a review or a design postmortem. It’s the hardest part and the most valuable.

The central argument. Every good analysis needs one. Not a list of pros and cons but a thesis: this game succeeded or struggled primarily because of X, which was caused by Y, and was amplified or dampened by Z. You should leave with a clear explanatory story, not a balanced scorecard.

Key leverage points. Where did the decisions that actually determined the outcome get made - in development, in positioning, in pricing, in launch execution? This is where you connect the dots across all five layers. Two or three leverage points is usually enough. The goal is the short list of decisions or circumstances that everything else cascades from, not an exhaustive account of every choice the studio made.

The causal chain. Where did the decisions that determined the outcome actually get made: in development, in positioning, in marketing timing, in launch execution? This is the moment to connect the dots across all five layers. The best analyses find the moment of leverage when there is one: the single decision, circumstance or miscalculation that everything else cascades from.

What to take from this. What can a developer actually do differently because of this analysis? These should be generalizable but concrete. Not "make a good game" but "in a crowded genre, a distinctive visual identity may matter more to discoverability than gameplay depth, because players decide whether to click before they decide whether to play." If a lesson dissolves on contact with a real decision, it's not a lesson - it's a truism. Cut it.

Inside: a five-layer teardown

Layer 1: context

Market and genre landscape (2016). Inside launched into a puzzle-platformer space that was mature but not oversaturated. The indie scene in 2016 was crowded with platformers, but most were either action-focused (Celeste wouldn’t release until 2018) or lighthearted (the tail end of the retro pixel art wave). Atmospheric, narrative-driven platformers were less common. Limbo’s success in 2010 had proven there was an audience for dark, minimalist puzzle-platformers, but six years had passed. The space wasn’t fatigued. If anything, players were primed for Playdead’s return.

Studio and development context. Playdead was a 25-person indie studio in Copenhagen. Inside was their second game, following Limbo’s critical and commercial success (over 1 million copies sold). The studio had institutional knowledge, technical capability and brand equity. Development took six years (2010-2016), an unusually long cycle for an indie game, but Playdead was self-funded after Limbo’s success and received a $1 million grant from the Danish Film Institute. The team switched from a custom engine (used for Limbo) to Unity to simplify development, adding their own temporal anti-aliasing rendering routines (later open-sourced).

This context matters. Inside wasn’t a debut or a pivot. It was a studio leveraging its strengths: experience making atmospheric platformers, technical capability to create a signature visual style and the financial runway to take the time needed. The six-year development cycle signals a commitment to quality over speed.

Platform and distribution. Inside launched on Xbox One first (June 29, 2016), then Windows via Steam (July 7), followed by PlayStation 4 (August 23). The Xbox exclusivity window was likely part of a deal that provided funding or marketing support. Microsoft featured Inside prominently at E3 2014 and 2016. The game later came to iOS (December 2017), Nintendo Switch (June 2018) and macOS (June 2020).

The multi-platform strategy was ultimately correct. Puzzle-platformers have broad appeal across console and PC audiences. The Xbox launch first gave the game Microsoft’s marketing weight and Game Pass visibility, while the quick Steam follow-up captured PC players who had supported Limbo.

Timing and cultural moment. Inside released in the summer of 2016, a relatively quiet period for major releases. No direct competitors launched alongside it. The game benefited from six years of anticipation (Limbo fans had been waiting), Microsoft’s E3 showcase presence and a free Limbo promotion on Xbox in advance of Inside’s release. There was no headwind. If anything, the timing was ideal.

Layer 2: positioning

Target audience. Inside was made for players who value atmosphere, environmental storytelling and puzzle-solving over action. The target audience overlaps with Limbo’s fanbase but extends to anyone drawn to narrative-driven indies with artistic ambition. This was a well-defined, underserved audience in 2016. Most puzzle-platformers were either too light (mobile-casual) or too action-heavy (Ori and the Blind Forest). Inside occupied a distinct niche: dark, minimalist, thoughtful.

Value proposition and differentiation. Inside’s core pitch: a hauntingly atmospheric puzzle-platformer with environmental narrative, stunning visuals and thematic depth rarely seen in games. The differentiation was clear: it wasn’t just Limbo 2, it was an evolution. More color (muted but present), more complex puzzles, more ambitious scale (the Huddle sequence) and more thematic ambition (conformity, surveillance, loss of agency). The game promised to make you feel something uncomfortable and stay with you after it ended.

Discoverability and marketing. Inside had exceptional visibility for an indie game, largely because of Playdead’s track record and Microsoft’s support. Key discovery drivers:

• Microsoft E3 showcases (2014, 2016): massive exposure to core gaming audience

• Critical acclaim from previews: IGN, Polygon, Kotaku and others covered it extensively pre-launch

• Limbo’s legacy: players who loved Limbo were actively looking for Inside

• Game Pass inclusion: Inside was an early Game Pass title, giving it additional reach

• Strong press relationships: Playdead had earned trust with press through Limbo

Steam reviews: 65,154 reviews at 96% positive. SteamSpy estimates 2-5 million owners on Steam alone. This is exceptional discoverability for an indie game, though much of it came from quality and word-of-mouth rather than paid marketing.

Reception snapshot. Inside received near-universal critical acclaim. Metacritic: 87 (PC), 91 (Xbox One), 93 (PS4). User scores on Steam: Overwhelmingly Positive (96%). Critics praised the art direction, sound design, atmosphere, pacing and thematic depth. Some criticized the ambiguous ending, but most saw it as a strength.

There was no divergence between critics and players. Both groups loved it. The few criticisms that emerged were about the short length (3-4 hours) relative to the $20 price, but this was a minority view and didn’t impact the overall reception.

Layer 3: business

Pricing strategy. Inside launched at $19.99 on all platforms. This was well-calibrated. The price signaled premium indie quality without overreaching. $20 for a 3-4 hour game is defensible when the experience is polished, memorable and replayable (achievement hunters, secret ending). The price also positioned Inside as a deliberate, focused experience rather than a sprawling one. No launch discount, no bundles initially. The game earned its price.

Sales and financial outcome. Steam revenue calculator estimates $76.8 million in gross revenue from Steam alone (this includes all platforms via Steam keys and direct sales). Net developer revenue after platform cuts, refunds, discounts, and VAT: approximately $22.7 million. SteamSpy estimates 2-5 million owners on Steam. Console sales (Xbox, PlayStation, Switch) likely pushed total units to 4-6 million across all platforms.

Development budget is not publicly disclosed but we can estimate. 25-person team for 6 years in Copenhagen (high cost of living). Rough estimate: $15-20 million total development cost. At $22.7 million net revenue from Steam alone, Inside was highly profitable before counting console sales, mobile sales and ongoing revenue from continued sales and bundles.

This is a clear financial success. Playdead could afford to take six years because Limbo had funded the studio, but Inside more than paid for itself and set the studio up for their next project and then some.

Post-launch support. Playdead patched bugs and performance issues shortly after launch but did not release DLC or major content updates. This was the correct decision. Inside is a tightly crafted, complete experience. Adding DLC would have diluted it. The studio focused instead on porting to additional platforms (iOS, Switch, macOS), which extended the game’s reach and revenue.

Business model fit. The premium model was perfect for Inside. A $20 upfront purchase for a complete, focused experience. No microtransactions, no early access, no episodic structure, no shenanigans. The game’s value proposition (a singular artistic experience) wouldn’t have worked with free-to-play or games-as-a-service. The model aligned with the product.

Layer 4: creative experience

Fantasy. Inside’s fantasy is not power or mastery. It’s vulnerability and compulsion. You are a small boy in a hostile world, hunted and alone, drawn inexorably toward something you don’t understand. The fantasy is atmospheric dread, the feeling of being watched, the discomfort of moving forward because you have no other choice. Every visual, sound and mechanic reinforces this. The boy’s animations are fragile. The environments are oppressive. The sound design is sparse and unsettling. The game never lets you feel safe.

This is a coherent fantasy executed to perfection. Inside doesn’t waver. It doesn’t give you moments of heroism or relief. It commits to its tone from the first frame to the last.

Core loop. The loop is simple: move right, solve environmental puzzles, avoid death, progress. The puzzles involve physics (pushing objects, timing jumps), environmental interaction (activating switches, using mind-control helmets to manipulate mindless workers) and occasional chase sequences. The loop is not about complexity or mechanical depth. It’s about pacing and tension. Each puzzle is just difficult enough to make you think but not so hard that it breaks flow. The chase sequences inject urgency. The loop serves the fantasy: you are always moving forward, always under pressure, never in control.

Onboarding and accessibility. Inside has no tutorial, no text, no UI. You start running and the game teaches you through play. Jump over a log. Climb a ledge. Hide from a searchlight. The learning curve is gentle but immediate. Within five minutes you understand the rules. This is exceptional onboarding design: respectful of the player’s intelligence, confident in its communication and seamless with the experience.

Systems design and depth. Inside is not a systems-driven game. There is no progression, no skill tree, no inventory, no build variety. The depth comes from puzzle design and environmental storytelling. Each puzzle is handcrafted. The game doesn’t rely on procedural generation or emergent interaction. This is intentional. Inside is a linear, authored experience and that’s its strength. The lack of systems allows the game to maintain perfect pacing.

Pacing and structure. Inside’s pacing is relentless. The game opens with a chase sequence that establishes the tone immediately. From there, it alternates between quiet exploration, environmental puzzles and high-tension chase sequences. The pacing never drags. Each environment introduces new visual ideas and puzzle mechanics. The game builds toward the Huddle sequence, a shocking tonal and mechanical shift that serves as both climax and commentary. The secret ending (accessed by finding hidden orbs) provides an alternate conclusion that recontextualizes the entire experience.

Inside is 3-4 hours long and that length is perfect. The game doesn’t overstay its welcome. Every moment is intentional. This is pacing discipline most games lack.

Art direction and audiovisual coherence. Inside’s visual identity is its most immediate strength. The game uses a muted color palette (grays, blues, reds) and a 2.5D perspective with depth-of-field effects that create a cinematic look. The lighting is dramatic and deliberate. The boy is rendered in silhouette or partial silhouette for much of the game, emphasizing vulnerability and anonymity. The environments are industrial, decayed, and oppressive: factories, farms, laboratories, underwater facilities.

The sound design (by Martin Stig Andersen, who also worked on Limbo) is sparse and atmospheric. There is no music in the traditional sense. Instead, ambient sound and environmental audio create tension. Footsteps, water, machinery, breathing. The soundscape is as important as the visuals in creating the game’s atmosphere.

This coherence is what makes Inside so memorable. Every visual and audio choice serves the tone. Nothing is extraneous. The game has a signature look that travels through screenshots and trailers, making it instantly recognizable.

Narrative and tone. Inside has no dialogue, no text, no explicit exposition. The narrative is environmental. You piece together what’s happening through visual cues: the mind-control helmets, the farms where mindless workers are grown, the laboratories where experiments are conducted, the Huddle (an amalgamation of bodies that becomes a grotesque escape mechanism or perhaps the culmination of the experiment you’ve been part of all along).

The themes are conformity, surveillance, control, loss of agency and the commodification of human beings. The game never explains itself. The ambiguity is deliberate. Players are left to interpret. Some see the boy as an escapee. Others see him as a failed experiment. Still others see the entire game as a metaphor for the player’s relationship to the game itself (you, the player, control the boy; the boy is just another mindless worker).

The tone is bleak, unsettling and uncompromising. Inside doesn’t offer catharsis or resolution. It offers discomfort and questions. This works because the mechanical experience supports it. You are always being hunted, always moving forward without understanding why, always complicit in whatever this world is.

Technical state at launch. Inside launched in excellent technical condition. No major bugs, smooth performance across platforms, tight controls. The game’s technical polish was frequently praised in reviews. This matters. A game with Inside’s tone and pacing can’t afford technical issues that break immersion. Playdead’s six-year development cycle gave them time to refine everything.

Layer 5: synthesis

The central argument. Inside succeeded because Playdead executed a cohesive artistic vision at the highest level while leveraging institutional knowledge, technical capability and brand equity built over six years. The critical and commercial success wasn’t accidental. It was the result of decisions made throughout development: taking the time needed to achieve polish, committing to a singular tone without compromise and positioning the game to reach both existing fans and new players through earned partnerships.

Key leverage points.

• Limbo’s success gave Playdead the financial runway and brand equity to take six years on Inside. Without it, they likely couldn’t have afforded the development time. With it, they could prioritize quality over speed.

• The decision to commit fully to a dark, atmospheric, narrative-driven experience meant the game had a clear identity and a defined audience. In a crowded indie space, that clarity was essential.

• The visual and audio design created a signature aesthetic that was instantly recognizable and highly shareable - driving organic discoverability through screenshots, trailers and word-of-mouth before paid marketing entered the picture.

• The game’s pacing, polish and thematic depth meant that players who started it finished it and recommended it. A 96% positive Steam review score is not just about quality. It’s about delivering on the promise the game makes in its first hour.

What to take from this. Brand equity compounds - a strong first game gives you the runway and audience trust to take risks on a second. Time and budget buy polish, but only if you use them with discipline. Atmospheric games live or die on coherence: if Inside had inconsistent tone, weak audio or rough pacing, none of the visual identity would have saved it. And short, focused experiences can justify premium pricing if the quality is there. Length is not value. Memorability is.

Ashen: a five-layer teardown

Ashen had the ingredients for a breakout indie success. A distinctive art style, Annapurna’s publishing muscle, Souls-like design from a studio making their debut, Journey-inspired co-op, Microsoft E3 showcases and a four-year development cycle that suggested polish and ambition. The game launched to positive critical reception (Metacritic 78) and was featured prominently alongside AAA titles. It should have been a triumph.

Instead, it was... good. Genuinely good in places. And then a bit frustrating in ways that kept adding up. A game that launched with momentum, received tepid player reception (Steam 67% positive, “Mixed”), sold modestly (20,000-50,000 copies on Steam alone based on SteamSpy, roughly $1.3M net revenue estimate) and unfortunately faded quickly.

The disconnect between what Ashen could have been and what it actually achieved is instructive. This is a teardown about execution gaps, misaligned ambitions and the difference between a good pitch and a game that delivers on that pitch.

Layer 1: context

Market and genre landscape (2018). Ashen launched into a Souls-like space that was mature and increasingly crowded. Dark Souls III had released in 2016. Nioh (2017) had proven the formula could be adapted successfully. Hollow Knight (2017) and Dead Cells (2018) were dominating the indie action space. Salt and Sanctuary (2016) had already proven a 2D Souls-like could succeed. The bar for Souls-likes was high and rising.

The space wasn’t oversaturated yet but players had expectations. They knew what good Souls-like combat felt like, what tight level design looked like, what meaningful progression systems enabled. Ashen was competing not just against other indies, but against the benchmark that From Software had set and refined over a decade.

Studio and development context. A44 Games (originally Aurora44) was a New Zealand indie studio making their first game. The team started with three people and grew to approximately 40 by launch. Development took roughly four years (2014-2018). The studio received support from Annapurna Interactive as publisher and had deals with Epic Games Store (timed exclusive) and Microsoft (Xbox/Windows Store, Game Pass).

This context matters. Ashen was a debut from a studio that had no prior shipped titles, no known institutional knowledge of how to make a Souls-like and no technical foundation to build on. They were learning as they went, using Unreal Engine 4, and scaling a team from three to forty during active development. Compare this to Inside, where Playdead leveraged institutional knowledge and brand equity from Limbo. A44 had neither.

The Epic exclusivity decision was particularly damaging. The game was listed on Steam for years before launch, building a wishlist community, then pulled at the last moment for a timed exclusive on Epic Games Store. This generated significant community backlash and cost the game launch momentum on its intended primary platform.

Platform and distribution. Ashen launched December 7, 2018 on Xbox One (via Game Pass), Windows (Epic Games Store exclusive initially) and later on Steam (December 9, 2019, a full year after launch). It later came to PlayStation 4, Nintendo Switch and iOS.

The Epic exclusivity was possibly a strategic misstep. The PC audience for Souls-likes is primarily on Steam. Launching on Epic meant smaller player base, weaker community tools and angry fans who had been waiting years. When the game finally arrived on Steam a year later, momentum was gone. Reviews on Steam reflected this: players noted bugs that had already been patched on other platforms and the game felt “old” at launch.

Timing and cultural moment. December 2018 was a crowded release window. Super Smash Bros Ultimate launched December 7 (same day as Ashen). Just Cause 4, Soulcalibur VI, Battlefield V and Red Dead Redemption 2 were all fresh releases competing for attention. Ashen had Microsoft’s E3 presence and Game Pass visibility, but it was a small indie competing in a AAA-heavy season.

There was no cultural tailwind. The game released into noise.

Layer 2: positioning

Target audience. Ashen was positioned for players who wanted a “lighter” Souls-like experience with Journey-inspired co-op and distinctive art. The pitch: a more accessible Dark Souls with emotional multiplayer moments and a striking visual style. The target was Souls-like fans who found From Software games perhaps too punishing and Journey fans who wanted more mechanical depth.

This is a reasonable audience, but it’s also a narrow one, and Ashen needed to execute perfectly to satisfy both groups. Souls-like fans want tight combat above all. Journey fans want atmosphere and emotional resonance. Ashen tried to serve both and arguably ended up fully satisfying neither.

Value proposition and differentiation. Ashen’s core pitch: Dark Souls combat + Journey’s passive multiplayer + minimalist art direction + town-building hub. The differentiation was clear in screenshots and trailers. The faceless character design, muted color palette (grays, blues, warm oranges) and low-poly aesthetic created a recognizable identity.

The problem was that the pitch promised more cohesion than the game delivered. The combat felt like a worse version of Dark Souls. The multiplayer rarely worked as intended. The town-building was shallow. The art direction was striking but couldn’t carry the experience when the mechanics didn’t hold up.

Discoverability and marketing. Ashen had strong visibility for an indie:

• Microsoft E3 showcases (2015, 2016, 2017): major platform exposure

• Annapurna Interactive as publisher: strong indie brand with press relationships

• Game Pass inclusion at launch: millions of potential players on day one

• Epic Games Store featuring: additional PC visibility (though controversial)

Despite this, player numbers remained modest. SteamSpy estimates 20,000-50,000 owners on Steam. Steam reviews: 3,743 total (as of early 2026), 66% positive. For comparison, Hollow Knight has 172,000+ Steam reviews. Ashen had the visibility but couldn’t convert it to sustained engagement.

Reception snapshot. Critics: Metacritic 78 (PC), generally favorable. Praised for art direction, atmosphere, co-op concept. Criticized for shallow combat, repetitive world design, technical issues.

Players: Steam 66% positive (Mixed rating), significantly lower than critic scores. Common complaints: floaty combat, poor AI companions, empty multiplayer, repetitive enemy design, inventory frustrations, uneven difficulty spikes.

The divergence between critic and player reception is not small. Critics reviewed the game over a few days and appreciated the aesthetic and concept. Players who spent 10-20 hours discovered that the systems were shallow and the execution was at times inconsistent. This gap signals a game that makes a strong first impression but doesn’t sustain it.

Layer 3: business

Pricing strategy. Ashen launched at $39.99 on all platforms. This was perhaps a miscalibration. The price signaled AA-quality scope and polish, but the game delivered a 10-15 hour experience with shallow systems. For $40, players expected more depth, more content or more polish. Souls-like fans could buy Dark Souls III or Nioh for less. The price created an expectation the game couldn’t meet.

A $24.99 launch price would have been better aligned with the actual content and polish level. The $40 price point invited direct comparison to more polished competitors and contributed to the “wait for sale” sentiment in community discussions.

Sales and financial outcome. Steam revenue estimates: $4.3M gross, $1.27M net (after platform cuts, refunds, VAT). SteamSpy: 20,000-50,000 owners. This is Steam only, one year after initial launch. Add Epic, Xbox, Game Pass, and later platforms and total units sold are maybe 100,000-200,000 across all platforms and services.

Development budget is not disclosed, but we can estimate. 40-person team for 4 years in New Zealand. Rough estimate: $8-12 million total development cost (New Zealand salaries are lower than US but still significant). At $1.27M net from Steam plus additional revenue from other platforms and Game Pass payout, the game likely broke even or achieved modest profitability, but nowhere near the success a game with this much visibility should have achieved.

For context, A44 survived and went on to make Flintlock: The Siege of Dawn, which suggests Ashen generated enough revenue (or the studio secured enough funding) to continue. But this was not a breakout success.

Post-launch support. A44 patched bugs and released one DLC (Nightstorm Isle, September 2019). The DLC added a new area and boss fights but didn’t address the core combat and progression issues. Post-launch support was adequate but didn’t fundamentally improve the game. The studio moved on to their next project rather than iterating deeply on Ashen.

Business model fit. The premium model was correct for the type of game Ashen was trying to be, but the price was too high relative to content and polish. Game Pass inclusion helped extend reach, but it also meant many players experienced the game “for free” and had lower tolerance for its flaws. If you paid $40, you might push through frustrations. If you’re browsing Game Pass, you quit and try something else.

Layer 4: creative experience

Fantasy. Ashen’s fantasy is exploration and survival in a harsh, sunless world where you build a home and form fragile connections with other wanderers. You are vulnerable, alone and the world is hostile. But unlike Inside, which commits fully to dread and vulnerability, Ashen hedges a little. It wants to be Dark Souls (mastery through challenge) and Journey (connection and atmosphere) simultaneously. The result is a somewhat muddled fantasy that never fully commits to either.

The tone is somber and melancholic, but it’s not oppressive. The art direction is beautiful, but it’s not cohesive with the punishing mechanics. The multiplayer is meant to create Journey-like moments, but it doesn’t quite work as expected. The fantasy Ashen promises (lonely wanderer finding connection) is somewhat undermined by the mechanical reality (frustrating combat, glitchy co-op, shallow progression).

Core loop. The loop is: explore the world, fight enemies with stamina-based combat, gather resources, return to town to upgrade gear and recruit NPCs, venture further. This is standard Souls-like structure. The problems:

Combat feels floaty and imprecise. Hit recognition is inconsistent. Weapons within the same class have identical movesets, making combat repetitive. Enemy design is limited and recycled. I mean, “underbaked” is the word that keeps showing up in reviews and I don’t think it’s far off.

Progression is shallow. Weapon upgrades aren’t as rewarding as they could be. Character builds lack meaningful differentiation. There’s no stat leveling, only equipment-based progression, which limits player agency and experimentation.

The loop can become tedious quickly. Without meaningful progression or combat depth, the loop becomes just grinding through repetitive encounters to reach the next area, which looks similar to the last.

Onboarding and accessibility. Ashen doesn’t hold the player’s hand, which is appropriate for a Souls-like. But it also doesn’t teach core mechanics as clearly as it could. Players report confusion about stamina management, weapon upgrading and companion AI behavior. The game assumes familiarity with Souls-like conventions but doesn’t execute those conventions well enough to reward that assumption.

Systems design and depth. Ashen’s systems are a bit thin:

• Combat: shallow. Limited attack variety, identical movesets within weapon classes, inconsistent hit detection.

• Progression: limited. Equipment-based only, no stat customization, upgrades feel unrewarding.

• Town-building: cosmetic. NPCs add vendors and minor bonuses but don’t fundamentally change gameplay.

• Co-op: multiple issues. AI companions are buggy (falling off cliffs, ignoring combat, failing to revive). Actual multiplayer matchmaking is unreliable. When it works, it’s fine, but it doesn’t work as often as it should.

The game lacks depth to sustain a 15-hour playthrough. Hollow Knight, for comparison, has intricate progression, diverse combat encounters and exploration that rewards curiosity. Ashen doesn’t quite get there.

Pacing and structure. Ashen starts strong. The opening hours are atmospheric, the world feels mysterious, the first boss is satisfying. Then the cracks appear. Difficulty spikes inconsistently, the Seat of the Matriarch dungeon is a notorious wall where many players quit, enemy variety stagnates, the world becomes a bit monotonous and by hour 10 you may be ready to churn.

Art direction and audiovisual coherence. This is Ashen’s greatest strength. The faceless character models, low-poly environments, muted color palette (blues, grays, warm oranges at the hub town) and lighting create a distinctive aesthetic. The game is beautiful in screenshots and trailers. The atmosphere is genuinely striking in the early hours.

But art direction alone can’t carry a game when the mechanics aren’t as strong. Players get tired of looking at gray cliffs and brown caves after 10 hours, especially when exploration doesn’t yield meaningful rewards. The audio design is solid, but not enough so to carry the entire game.

Narrative and tone. Ashen’s narrative is environmental and minimal, told through world design and NPC interactions. The story is about rebuilding civilization in a sunless world after the return of light. Thematically, it’s about connection, home and survival.

The problem is that the narrative doesn’t integrate with the mechanical experience. You’re building a town, but it feels like a menu screen, not a living place. You’re forming connections with NPCs, but they’re just vendors with shallow dialogue. The tone is melancholic, but the game never earns that emotion. It tells you the world is harsh and lonely but it doesn’t make you feel it the way Inside does.

Technical state at launch. Ashen launched with bugs and performance issues, AI pathfinding had serious issues - companions falling off cliffs, getting stuck, failing to engage - multiplayer matchmaking was unreliable, frame rate dropped on console and inventory management was genuinely clunky. For a game with four years of development and Annapurna's publishing support, this wasn't good enough.

Layer 5: synthesis

The central argument. Ashen underperformed because it failed to execute the fundamentals of the genre it was imitating. The game had strong marketing positioning, distinctive art direction and conceptual ambition - and none of that was enough once players spent 10-15 hours with shallow combat, unreliable co-op and a world that became repetitive. These execution failures were likely compounded by strategic decisions that added friction: Epic exclusivity that alienated the Steam community, $40 pricing that invited unfavorable comparison to better Souls-likes and a December launch window dominated by AAA competition.

This is a case study in the difference between a good pitch and a game that delivers on it. The pitch worked. The execution didn’t quite.

Key leverage points.

• A44 was a first-time studio with no institutional knowledge of Souls-like design, learning to make this type of game while simultaneously scaling a team from three to forty people. That combination is extremely difficult and it shows in the final product.

• The decision to build a Souls-like without mastering combat fundamentals was the central failure. If your genre is defined by tight, skill-based combat and your combat feels floaty and imprecise, everything else becomes window dressing on a shaky foundation.

• The $40 price point set expectations the game couldn’t meet. At $25, player tolerance for shallow systems would have been higher. At $40, direct comparison to Dark Souls III and Nioh was inevitable and unfavorable.

• The co-op system was marketed as the game’s primary differentiator and shipped broken. When your unique selling point doesn’t work, players don’t just feel disappointed - they feel misled.

• The Epic exclusivity deal likely made short-term financial sense for a first-time studio. It cost them launch momentum on Steam and generated lasting resentment that colored reviews and word-of-mouth a year later when the game finally arrived there.

What to take from this. You cannot overcome subpar execution in a genre defined by mechanical depth - art direction gets you coverage, it doesn’t carry a game. First-time studios attempting complex genres face compound challenges: if you don’t have institutional knowledge, either start smaller or bring in significant expertise. Price creates expectations, and knowing where your game sits in the quality hierarchy before you set a number is not optional. And ambitious scope without execution depth risks producing hollow experiences - it’s possible Ashen tried to do too much, and each system suffered for it.

In closing

The framework prevents you from attributing success or failure to the wrong causes. Inside didn’t succeed because “it was good.” Ashen didn’t fall short because “it was bad.” Both had strong art direction, major publisher support and E3 showcases. The difference is that Inside delivered on its promise at every layer and Ashen didn’t quite - and the framework tells you specifically where, and why, and what the leverage points were.

That’s what vibes-based analysis can’t give you. Actionable conclusions. The kind you can actually use when making decisions about your own game.

A good concept gets you in the room. After that, you have to deliver.

If this was useful, you might also like:

MBA programs have a reputation problem in the games industry. And some of it is earned, if you ask me. We associate them with soulless mobile games architected around whales and conversion loops, with AAA publishers chasing quarterly metrics at the expense of the people making the games, with executives who treat creative work like a commodity. The term “MBA thinking” has become shorthand for everything wrong with the business side of games.

Many indie studios fail not because they made a bad game but because they made business decisions without any framework for thinking about competition, market positioning, customer behavior or sustainable growth. They treat business as something that happens after the game is done or as an unfortunate necessity rather than a discipline with useful tools and patterns. This is expensive, to put it mildly.

Here's the thing though: the problem isn't the tools. It's that most of the people deploying them in games have never actually shipped one. An MBA toolkit applied by someone who doesn’t understand or value creative work is likely to produce extractive, player-hostile outcomes. The same toolkit applied by someone who actually cares about games and the people making them can help build studios that don’t collapse, products that find their market and video game businesses that sustain creative work over the long term.

This guide is about taking the parts of MBA thinking that actually apply to small game studios and leaving the rest behind. Not everything translates. Some of it is overkill for a five-person team. But there are frameworks here that can help you make better decisions about what to build, who to build it for, how to position it and how to stay solvent while you do it.

Part 1: understanding your competitive environment

Porter’s Five Forces

Porter’s Five Forces is a framework for analyzing the competitive environment you’re operating in. It was designed for manufacturing and large-scale business but it translates surprisingly well to games if you adapt it.

The five forces are:

1. Threat of new entrants. How easy is it for new competitors to enter your space? In games, the barrier to entry is extremely low. Anyone can make a game. This means you’re always competing with new entrants, which puts pressure on pricing and makes differentiation positively critical.

2. Threat of substitute products. What else competes for your player’s time and money? This isn’t just other games in your genre. It’s every other form of entertainment. A roguelike isn’t just competing with other roguelikes. It’s competing with Netflix, TikTok, books and going outside. This force is underestimated by most developers.

3. Bargaining power of suppliers. In traditional business, this means vendors who provide raw materials. For game studios, your “suppliers” are middleware providers (Unity, Unreal, Adobe, Autodesk, et al), platform holders (Steam, Xbox, Playstation, Nintendo) and talent (developers, artists, contractors). If you’re dependent on a single engine or platform, they have leverage over you. If specialized talent is scarce, they have leverage.

4. Bargaining power of buyers. Your players have a lot of options. Switching costs are zero. This means they have high bargaining power, which manifests as price sensitivity and high expectations for quality. The only way to counter this that I can think of is differentiation or building a loyal community.

5. Rivalry among existing competitors. How intense is competition in your specific market? If you’re making a deckbuilding roguelike in 2026, you’re in a saturated space with intense rivalry. If you’re making something truly novel, rivalry is lower but finding your audience is harder.

Why this matters for indie studios:

Most indies don’t think about these forces systematically, which leads to bad positioning decisions. You pick a genre because you like it, not because you've thought about how crowded it is. I've done this. Most people I know have done this. It's an expensive way to learn. You price your game at $15 because that feels right, not because you’ve thought about buyer power and substitute products. Porter’s Five Forces forces you (no pun intended) to think about the structural realities of the market you’re entering.

How to use it:

Before you commit to a project, spend an hour doing a Five Forces analysis. Write down:

• Who are your direct competitors? How many of them are there?

• What substitutes exist? What else competes for the same player time?

• What’s your dependency on platforms, engines, or key talent?

• How price-sensitive is your target audience?

• How easy would it be for someone else to make something similar?

If all five forces are working against you (high rivalry, low barriers to entry, powerful substitutes, dependent on a single platform, price-sensitive audience), you need either a very strong differentiation strategy or you should reconsider the project. This analysis doesn’t tell you what to build. It tells you what you’re up against.

Porter’s Three Generic Strategies

Porter also identified three strategies for competing: cost leadership, differentiation and niche focus. You can’t do all three. You have to pick one.

Cost leadership means you deliver comparable value at a lower price than competitors. This is hard for indies because you don’t have economies of scale. You can’t out-cheap a studio with 50 people and existing tech. The rare exception is if you’ve built tools or processes that let you produce content much faster than competitors. Most indies should not pursue cost leadership.

Differentiation means you offer something genuinely different that players value. This is the most common strategy for successful indie games. The differentiation can be in gameplay (a mechanic no one else has), art style (a look that’s instantly recognizable), narrative (a story that resonates in a way others don’t) or experience (a feeling the game creates that others don’t). The key is that the differentiation has to matter to players, not just to you.

Niche focus means you target a specific, narrow market and serve it exceptionally well. This works when the niche is underserved and you understand it intimately. A game for hardcore train sim enthusiasts doesn’t need mass appeal. It needs to be exactly what that specific group wants.

Why this matters:

Trying to compete on all three strategies produces a mediocre game with no clear positioning. You need to know what your competitive advantage is and commit to it. Most successful indie games are either highly differentiated or tightly focused on a niche. Trying to be everything to everyone is how you end up being nothing to anyone.

How to use it:

Write down which strategy you’re pursuing. If you can’t articulate it clearly in one sentence, you probably haven’t committed. Then audit your game’s features and scope against that strategy. If you’re pursuing differentiation through a unique mechanic, does every major feature support that differentiation or are you also trying to compete on scope? If you’re pursuing niche focus, are you making compromises to appeal to a broader audience that will dilute your value to the niche?

This framework is useful for scope cuts. If a feature doesn’t support your chosen strategy, it’s probably not worth building.

Part 2: understanding your product and market position

SWOT Analysis

SWOT stands for Strengths, Weaknesses, Opportunities, Threats. It’s one of the most basic MBA frameworks and also one of the most useful because it forces you to be honest about all four quadrants.

Strengths: what do you have going for you? This includes team skills, existing relationships, technical advantages, brand recognition if you have it, financial runway and any other internal advantage.

Weaknesses: what are your limitations? This includes lack of experience, budget constraints, small team size, gaps in critical skills, no marketing reach and technical debt.

Opportunities: what external factors could you exploit? This includes emerging platforms, underserved genres, timing (a trend you can ride), partnerships or market gaps.

Threats: what external factors could hurt you? This includes competitors launching similar games, platform policy changes, market saturation, economic conditions or technology shifts.

Why this matters:

SWOT forces you to look at both internal realities (strengths and weaknesses) and external environment (opportunities and threats) at the same time. Most studios do one or the other but not both. You overestimate your strengths and underestimate threats, or you see every opportunity but ignore your weaknesses.

How to use it:

Do a SWOT analysis at the start of a project and revisit it at the end of each milestone. Be brutally honest. Don’t write “passionate team” as a strength unless that passion translates to a concrete advantage. Don’t write “we’re small” as a weakness without also writing what specific capability you lack because of it.

The real value of SWOT is in the intersections. Look at your strengths and ask: which opportunities can we exploit because of these strengths? Look at your weaknesses and ask: which threats are we especially vulnerable to because of these weaknesses? That’s where strategy comes from.

The Four P’s of Marketing

The Four P’s are Product, Price, Place (distribution) and Promotion. They’re the fundamental levers you have to control how your game reaches players.

Product: the game itself. This includes features, genre, art style, narrative, technical quality, platform and player experience. In MBA terms, you’re thinking about product-market fit: does this product solve a problem or fulfill a desire for a specific group of players?

Price: what you charge. This isn’t just a number. It’s a signal about what the game is and who it’s for. A $60 game signals premium quality and positions against AAA. A $20 game signals indie polish. A $5 game signals casual or experimental. Free-to-play signals ongoing content and monetization. Your price needs to align with the other three P’s.

Place: where and how players access the game. Steam, Epic, console, mobile, itch.io, your own website. Each distribution channel has different audiences, discovery mechanisms and economics. Place also includes things like whether you’re in Game Pass, whether you’re doing a console-exclusive deal, whether you’re using a publisher for distribution.

Promotion: how you tell people the game exists. This includes trailers, press outreach, social media, influencer campaigns, Steam wishlist campaigns, conventions, paid ads and word of mouth. Promotion is the thing indie developers consistently underinvest in because it feels dirty or because they assume a good game will find its audience.

Why this matters:

The Four P’s have to work together. If one is out of alignment, the whole marketing mix breaks. A $40 game on mobile is misaligned (wrong Price for that Place). A pixel art casual puzzler promoted through hardcore gaming press is misaligned (wrong Promotion for that Product). A premium narrative game priced at $5 is misaligned (Price undermines Product positioning).

Most indie studios think about Product obsessively and treat the other three as afterthoughts. You figure out Price two weeks before launch. You pick Place based on where you have an account. You do Promotion if you have time after the game is done. This is backwards. The Four P’s need to be decided together, early, and revisited as the game evolves.

How to use it:

Write down your Four P’s explicitly. For Product, describe the game in terms a non-developer would understand. For Price, write the actual number and justify why that price makes sense for your game and your audience. For Place, list the platforms and distribution channels and explain why those and not others. For Promotion, write down the actual activities you’re committing to and when they happen.

Now read all four together and ask: does this make sense as a coherent strategy? If you’re making a hardcore strategy game, pricing it at $30, distributing on Steam and GOG and promoting through strategy gaming YouTubers, that’s aligned. If one of those is off, figure out which one needs to change.

Part 3: understanding your players

Market Segmentation

Here's where a lot of indie pitches fall apart, by the way. Market segmentation is the practice of dividing a broad market into smaller groups of customers who have similar needs, behaviors or characteristics. You can’t be everything to everyone, so you need to know who you’re actually building for.

Common ways to segment:

Demographic: age, gender, income, education, location. A mobile match-3 game might target women 30-50 with disposable income. A hardcore tactical RPG might target men 25-40 with gaming PCs.

Behavioral: how people play games. Do they play daily or weekly? Do they finish games? Do they play socially or solo? Do they optimize or explore? Do they pay for cosmetics or only premium games?

Psychographic: values, motivations and identity. Some players want challenge and mastery. Some want stories and emotional experiences. Some want social connection. Some want creativity and self-expression. Some want escapism.

Why this matters:

If you try to appeal to everyone, you’ll make a bland game that satisfies no one. Segmentation forces you to pick a specific group and serve them well. This makes every design decision easier because you can ask: is this what our target segment wants or are we chasing a broader audience at the expense of focus?

How to use it:

Write a one-paragraph description of your target player. Not a demographic profile, a person. What do they play? Why do they play? What do they value? What frustrates them about existing games? What would make them excited about yours?

Then audit your game against that segment. If your target segment values tight, focused experiences and you’re building a 60-hour sprawling open world, you have a mismatch. If your target segment values story and you’re spending all your time on procedural systems, same problem.

Segmentation also helps with marketing. If you know who you’re targeting, you know where to find them, what language resonates with them and what to emphasize in your messaging.

Customer Lifetime Value (LTV)

Customer Lifetime Value is the total revenue a player will generate over their entire relationship with your game. For a premium game, LTV is usually the purchase price minus platform fees. For a free-to-play game or a game with DLC, LTV is more complex. It’s the revenue from their first purchase plus all subsequent purchases over time, minus acquisition cost.

Why this matters:

LTV tells you how much you can afford to spend to acquire a player. This sounds abstract until you're six months post-launch watching your ad spend outrun your revenue and wondering where the math went wrong. Which is where many studios encounter it for the first time. If your LTV is $10 and it costs you $15 to acquire a player through ads, you’re losing money on every player. If your LTV is $30 and acquisition costs $10, you have $20 of margin to reinvest in growth or take as profit.

LTV also helps you think about player retention and monetization. A free-to-play game with high LTV can afford to be more generous with free content because each retained player is worth a lot. A premium game with low LTV needs to be very efficient with acquisition cost.

How to use it:

For a premium game, calculate LTV simply: Price × (1 - platform cut) = LTV. For a $20 game on Steam, that’s $20 × 0.70 = $14 LTV per player.

For a free-to-play or DLC-driven game, estimate: (average revenue per paying player) × (conversion rate) = LTV. If 5% of players pay an average of $15, your LTV is $0.75 per player.

Once you know your LTV, you know your ceiling for acquisition (marketing) cost. If you’re spending more to acquire a player than they’ll generate in revenue, you’re in trouble. This is how you evaluate whether marketing spend makes sense, whether a publisher deal is worthwhile (they’re taking a cut of your LTV) and whether your business model is sustainable.

Part 4: understanding strategy and growth

Product-Market Fit

Product-market fit is the moment when your game resonates with a defined market segment strongly enough that word of mouth and organic growth become sustainable. Before product-market fit, you’re pushing a boulder uphill. After it, the boulder rolls on its own.

Signs you have product-market fit:

• Players are actively recommending your game without you asking

• Retention metrics are strong (players keep coming back)

• Reviews are positive and detailed (players care enough to write)

• Organic growth is happening (wishlist adds, sales, player count going up without marketing spend)

Signs you don’t:

• Marketing spend generates short-term spikes but no lasting growth

• Churn is high (players drop off quickly)

• Reviews are lukewarm or critical

• You’re constantly explaining to people why the game is good

Why this matters:

Most indie studios never achieve product-market fit and don’t know it. They assume low sales are a marketing problem when they’re actually a product problem. You can’t market your way out of a product-market fit problem. If the game isn’t resonating with a defined segment, no amount of advertising will save it.

How to use it:

Before you ship, test with your target segment. Not with friends, not with random people on Reddit, but with actual representatives of the segment you’re targeting. Watch them play. Don’t explain anything. See if they get it, if they enjoy it, if they want more.

If you’re getting strong enthusiasm from a small group, you probably have product-market fit with that group. Double down on them. If you’re getting lukewarm feedback from everyone, you probably don’t have product-market fit anywhere. This is a pivot signal.

After launch, track retention and organic growth separately from paid acquisition. If retention is below 20% (players who play once and never come back), you don’t have product-market fit. If organic growth is zero (every player is from paid acquisition or your own efforts), you don’t have product-market fit.

Growth Engines (from Lean Startup)

Eric Ries identifies three engines of sustainable growth: sticky, viral and paid. Most businesses rely primarily on one.

Sticky growth means players come back repeatedly and stay engaged over time. You grow by keeping existing players longer than you lose them. This engine is measured by churn rate (how many players stop playing per month) and retention rate (how many stay engaged). If retention is higher than churn, you grow.

Viral growth means each player brings in more than one additional player through word of mouth, sharing or built-in social mechanics. Measured by viral coefficient: if each player brings in 1.2 new players on average, you have viral growth. If it’s 0.8, you don’t.

Paid growth means you acquire players through advertising and the LTV of each player is higher than the cost to acquire them. If LTV is $20 and cost per acquisition is $10, you can scale profitably.

Why this matters:

Most indie studios don’t think about which engine they’re relying on, which makes it impossible to optimize. A single-player premium game doesn’t have viral or sticky growth, so it has to work on paid (and ideally organic) growth. A free-to-play game with strong retention is built on sticky growth. A party game with built-in sharing mechanics is built on viral growth.

If you don’t know your engine, you can’t tune it. You can’t make informed decisions about where to invest.

How to use it:

Identify which engine of growth your game is designed for. If it’s a premium single-player game with no multiplayer or social features, your engine is paid + organic word of mouth. If it’s a live service game, your engine is sticky (retention). If it’s a social or party game, your engine is viral.

Then measure the right metrics:

• Sticky: track daily/weekly/monthly active users and retention curves. Optimize for keeping players engaged.

• Viral: track viral coefficient (how many new players does each existing player bring in). Optimize for sharing, referrals, and social mechanics.

• Paid: track LTV and customer acquisition cost. Optimize for conversion rate and reducing acquisition cost.

Part 5: understanding value and competitive advantage

Core competence as competitive advantage

A core competence is something your studio does exceptionally well that’s hard for competitors to replicate. It’s usually a combination of skills, processes and relationships that together create a defensible advantage.

Examples from successful indie studios:

• Supergiant Games: exceptional art direction + narrative voice + tight combat design + Darren Korb’s music. Each element is strong, but together they create a recognizable identity.

• ConcernedApe: one-person studio that can produce massive amounts of content efficiently. The competence is productivity and creative control at scale.

• Thatgamecompany: fantastic audiovisual experiences. Their competence is clearly execution polish at the visual and sonic level.

• ZA/UM: narrative craft that set the industry bar for indie storytelling. Whatever happened to the studio after Disco Elysium, the work itself remains the benchmark.

Why this matters:

If you don’t have a core competence, you’re competing on execution alone, which means every game might be a coin flip. Identifying what you’re genuinely good at lets you lean into it, build on it and create compound advantages over time.

How to use it:

Ask: what can our studio do that would be difficult for another studio to replicate? Not just “we work hard” or “we’re creative” but specific capabilities. Do you have an artist with a unique style? A programmer who can do procedural generation at a level most can’t? A designer with deep expertise in a specific genre? A process that lets you iterate unusually fast?

Once you identify it, make strategic decisions that leverage it. If your core competence is art direction, make sure the game’s design emphasizes visual storytelling. If it’s systems design, make a systems-driven game where that competence matters.

Part 6: practical frameworks for decision-making

The Build-Measure-Learn Loop (Lean Startup)

I won’t dive deep here since I’m saving The Lean Startup for a dedicated article, but it’s worth naming: the build-measure-learn loop is one of the most practically useful frameworks from startup thinking. Build a minimal version of something, measure how it performs, learn from the data, adjust, repeat.

This maps directly to game development: prototype a mechanic, playtest it, analyze what worked and what didn’t, iterate. The mistake studios make is building too much before measuring (six months on a mechanic before the first playtest) or measuring the wrong things (how much you like it rather than how players respond).

Reference this framework when making decisions about feature scope and iteration. If you can’t test something quickly, you’re building too much at once.

Minimum Viable Product (MVP)

Yet another Lean Startup concept worth mentioning: an MVP is the smallest version of your game that lets you test your core hypothesis. For a game, that’s typically “is the core mechanic fun?”, “is the core loop engaging?” or “does this art style resonate?”

The MVP is not a vertical slice with placeholder art. It’s the absolute minimum you need to answer a critical question. If you can answer “is the combat fun?” with three gray boxes and a prototype health bar, that’s your MVP for testing combat.

Indie studios waste enormous amounts of time polishing things before they know if the foundation works. Build the MVP, test it, and decide whether to continue or pivot before you’re six months in.

What not to take from MBA thinking

Not everything in the MBA toolkit is useful for indie studios. Here’s what I choose to ignore:

Excessive planning. Five-year projections, detailed financial models, 40-page business plans. These (perhaps) make sense for established businesses with predictable revenue. For an indie studio making a new game, they’re fiction. Plan for the next 6-12 months with some detail, have a rough idea of the 12-24 months after that and don’t waste time beyond that.

Financialization of creativity. Using ROI calculations to decide which game features to build is how you end up with soulless products. I've been in those rooms. The math is always right but to the detriment of the game. Some things are worth building because they make the game better, even if you can’t measure the return precisely. Trust your judgment about creative value.

Analysis paralysis. You can’t research your way to certainty. At some point you have to make a call with incomplete information and learn as you go. Frameworks are useful for structure, not for avoiding decisions.

Short-term optimization. MBA thinking often emphasizes quarterly results and short-term efficiency. Game development, especially for a small studio building a reputation, requires long-term thinking. Sometimes you take a financial hit on a project to build skills, relationships or brand that pay off later. That’s fine.

Putting it together

The frameworks in this article are useful when they help you make better decisions, and they become harmful when they substitute for judgment or creativity. Use them as thinking tools, not as rules.

The common thread is that they force specificity. They make you articulate what you’re doing, who you’re doing it for and why it should work. That discipline, applied correctly, doesn’t kill creativity. It protects it by making sure the creative work is pointing in a direction that has a chance of finding an audience and sustaining a business.

Some of these mistakes are genuinely avoidable. It’s a shame to learn them the hard way when you didn’t have to. I spent years doing exactly that.

If this was useful, you might also like: