The game backend is 5% of the budget and 100% of the launch

There is a half of every online game that almost nobody thinks about. Matchmaking. Inventory. Entitlements. The account service that decides whether you actually get in on launch night. By Mitchell Patterson's own estimate it accounts for roughly five percent of a game's budget, and it determines very close to all of whether a player ever reaches the thing the other ninety-five percent paid for.

Patterson is the founder and CEO of Wolfjaw Studios, which builds that layer for other people's games. He came to games from finance and early-stage investing, and he is emphatic that he never wanted to make a game of his own. What he wanted was the part everybody else was skipping.

A game that does not fail just means you can log in

Ask Patterson what success looks like and the answer is deliberately unimpressive. Not a review score, not a concurrency record. You open the game and you play it.

He is careful to say this does not get easier with practice. After years of launch days he still describes himself as terrified every time, and he is direct that no launch is ever perfect. What changes is not the risk, it is the number of times you have been in the room while it happened.

That is also his answer to what Wolfjaw actually sells, and it is a more honest one than most vendors give. Anyone can point a load generator at a system and claim ten million concurrents. Anyone who worked at a five thousand person studio can say they were on a game that held a million. Neither is the same as having done it, repeatedly, on someone else's launch date.

The prediction problem is part of why the reps matter. Patterson has watched the forecasting tools miss in both directions: a game with five hundred thousand wishlists that nobody plays, a game with an enormous marketing budget that lands flat, and a game nobody had heard of pulling eight hundred thousand players. You cannot plan your way to certainty on a curve like that. You can only be ready for it to be wrong.

The reward for a launch that works is a smaller contract

Here is the commercial problem hiding inside all of that competence. Wolfjaw signed a contract that included five engineers. The game launched with no problems at all. A month later the client explained that they did not need five people anymore.

This is the part of the business Patterson calls a badge of honor and a genuine strategic difficulty in the same breath. Work that succeeds completely removes the evidence that it was hard. The better the launch goes, the more reasonable it looks to spend less on the thing that made it go well.

The vendors you can name are the ones that failed

The visibility problem compounds in a way that should bother anyone who buys infrastructure. Patterson points out that several of his competitors are well known, market heavily, and have names buyers recognize from conference floors and LinkedIn.

Then he supplies the uncomfortable reason those names are familiar.

Public failure is the most efficient marketing an infrastructure vendor will ever get, because an outage is the only moment the layer becomes visible to anyone outside the studio. Which means recognition in this category is a lagging indicator of exactly the wrong thing, and a procurement process that starts with the names people already know is structurally biased toward the vendors with the worst record.

Patterson's stated alternative is slower and he admits it barely counts as a strategy. Say no to work outside the wheelhouse. Start every new client small enough to prove the relationship before scaling it. Then wait for people to move companies, because when they do, they bring the relationship with them. He is candid that he does not have a better answer, and that getting better at telling the story is the thing he personally needs to work on.

Identity is step one, and everything else hangs off it

The most directly useful minute in the conversation is the answer to a small question: if a tiny team is building a multiplayer game, what is the first piece worth getting right?

After understanding the architecture you actually want, the answer is identity. Not matchmaking, not inventory, not the social layer. How you create the persona that logs in, that later feeds the matchmaker, that gets associated with inventory, that may eventually need to work across platforms.

The ordering matters more than it sounds. Identity is the dependency the rest of the stack inherits, so a weak account layer does not fail on its own terms, it fails as matchmaking, as inventory, as a purchase that never grants the item. Teams that treat it as a later ticket end up rebuilding the systems they put in front of it.

Patterson is also clear that the sale for this has genuinely gotten easier, with one correction. The live service boom overcorrected into a period where every game was supposed to be live service, and he does not believe every game needs to be. The scale and dynamic systems questions show up in single player games too, which is a narrower and more defensible claim than the one the industry made in 2021.

The studio grows its own

Patterson rejects the ten-years-of-games-experience-only filter on straightforward arithmetic: a studio announcing five more games next year cannot conjure five times the veterans, because you do not clone people. So the studio hires out of college, hires people with no games experience and adjacent skills, and treats developing them as the actual product. He names it as the single biggest reason the company absorbed the last few years without breaking.

It shows up in the client list, which is a tenure list more than a logo list. Seven years with 2K. Five with Sony. Six and a half with InnerSloth, who were three people when the relationship started. Almost a decade with Riot. At that length he describes the work as no longer being a sale at all, just two teams deciding what to build.

What a founder learns when payroll comes out of his own account

The most revealing story Patterson tells is not about a launch. Early in the company's life his bank saw a new business receiving large checks and froze the account for two weeks to validate the activity. Payroll was due.

So he connected payroll to his personal bank account and paid the team out of it. Twice.

The employee who reminded him of this had come from large corporate and VC-backed companies, and his read was that any of them would have let the business fail instead. Patterson's own framing is less heroic and more useful: he thought he understood business before he ran one, and he did not. Cash flow is not a concept you learn, it is something you feel the first time you cannot pay people next week, and it changes your risk tolerance permanently.

He is equally direct about the mistakes. The company over-invested when things were going well. Its engineers became too opinionated with clients, which he corrected bluntly: it is not our game and not our money, so we build the track in the direction they tell us to build it. And after leaving finance specifically to escape corporate bureaucracy, he accidentally built layers of it himself, and took too long to notice.

His position on stability is the same kind of blunt. He will not promise his team that everything will be fine, because he would be lying, and he points out that the largest companies in the industry have laid off more people than anyone. What he offers instead is that the work will be good, the projects will be interesting, and the industry is not going back to what it was, which he says he is actually happy about.

What this means if you run a game

Three things carry out of the conversation for anyone operating a live game or buying the layer underneath one:

• Budget the backend as a launch-risk line, not an infrastructure line. At roughly five percent of spend it is too small to fight over and too load-bearing to defer, and it is the only part of the build that can make the other ninety-five percent unreachable.
• Build identity before you build anything that depends on it. Cross-platform auth and entitlements are the dependency the rest of the stack inherits, and retrofitting them means rebuilding whatever you put in front of them.
• Do not shortlist infrastructure vendors by name recognition. In this category the recognizable names are frequently the ones attached to public failures, because a working backend generates no coverage at all. Ask for tenure and reference calls instead.

Where to go next

The full conversation covers Patterson's route into games from finance, why he thinks the backend is about to matter well beyond games, and the one thing he would tell a three person team to do on Monday morning.

Listen to the full episode

Player Driven publishes a new conversation every Tuesday.

Get the week's argument in your inbox with The Operator's Briefing.

Or bring your own read to the room in Discord.