The Hidden Cost of Studio Engineering

Microsoft fired id Software’s tech team (Doom, Quake, Wolfenstein). Rovio’s internal tech team contributed to a record $200 million impairment charge on the SEGA acquisition. These are just a few recent cases that got me thinking: is building rather than buying actually more expensive for a studio?

When I worked inside studios or led one, we always wanted to use third-party tools. The usability of external tools was usually very good. The teams behind them were extremely responsive. We could influence the roadmaps. And to be honest, they tended to be better than anything internal tech teams delivered. 

And yet at every studio, the internal tech team vetoed studios’ demands to use a tool they hadn’t made. And it always happened the same way:

A vendor demo goes well. The product is solid. The team using the tool likes it and wants to continue with it. Then there is a meeting. In this meeting, someone, usually a senior engineer or a CTO, says it out loud: "Why don't we just build this ourselves?”

The vendor loses the deal. The studio loses the tool. The central tech team spins up a project. After a longer-than-expected period, the internal product goes live. It’s usually less robust than the third-party version; after all, the vendor’s sole focus is on this one product. And it’s not cheaper either, as the tool now requires a team to work on it. And yet, nobody ever runs the math on the actual costs. 

This is the build-vs-buy analysis coming from someone who has led studios. I’ve also consulted and done due diligence on several of the top free-to-play publishers’ central tech teams and the tooling they provide. 

And in my experience, the gaming industry gets it wrong more consistently than almost any other sector, because the accounting makes internal builds look free when they are not.

If you’re here to lead, not to read, check the Total Cost of Ownership Calculator below.

The Accounting Illusion

When you license a third-party tool, the cost is visible. It lands on a budget line. It requires approval. It feels like spending money.

When you build the same thing internally, the costs disappear into existing salaries, absorbed into sprint cycles, and categorized as engineering or an investment in the company’s “core technology”. Because nobody approves a monthly invoice, the build decision appears to cost nothing. After all, you already have the engineering team.

But your internal engineers are not free. They are expensive professionals whose time has an opportunity cost. Every month spent building auth systems, leaderboard infrastructure, matchmaking logic, or economy tooling is a month not spent building what differentiates your game. That cost is real. It just does not appear on any invoice.

Total Cost of Ownership (TCO) forces the real comparison into the open. It asks one question: what does it actually cost, fully loaded, over the life of the system, to build and maintain this internally versus to license it externally? The answer almost always surprises teams that have never sat down to calculate it.

5 x Numbers Most Studios Never Calculate

TCO has five components. Studios routinely undercount or ignore three of them.

1. Build Cost

This is the one number studios do acknowledge, if imprecisely. How many engineers, at what fully-loaded cost, for how many months? A studio building production-grade backend infrastructure from scratch typically commits three to eight engineers for six to eighteen months. At current industry salaries, that is a capital outlay in millions before a single player connects to the game. Not to mention the cost of getting the backend you need in a few years rather than when you actually need it. 

2. Maintenance Cost 

This is where most calculations fall apart. The backend you ship is not the backend you keep. Platforms update. SDKs deprecate. Security vulnerabilities emerge. Engine versions shift. The consistent industry benchmark, across decades of enterprise software data, reflected in IEEE research and Gartner analysis, is that annual maintenance runs 15 to 25 percent of the initial build cost. Every year. Without end.

Run that out across a full system lifetime, and maintenance typically consumes 60 to 80 percent of total lifecycle cost. The build phase is actually the minority of what you will spend. A backend that took 18 months to build costs roughly 3 to 4 months of engineering annually just to stay current. For most studios, that math has never been written down.’

Not to mention that the thing that you buy is already battle-tested by others; the thing you build, well, you are going to be battle-testing it live yourself.

3. Evolution Cost 

This cost compounds the problem. Live service games do not have stable feature sets. New monetization models require new economic logic. New platforms require new integrations. New player behaviors surface new backend requirements. Every evolution is a mini-build project funded from the same engineering capacity you need for the game itself.

4. Knowledge Retention Cost 

This is the one almost nobody budgets for. What happens when the engineer who architected your backend leaves? In a tight labor market with specialized infrastructure knowledge, the answer can be six months of productivity loss, institutional knowledge that is simply gone, and a new hire who needs a year to understand a system they did not build. This is an existential risk that gets filed under staffing assumptions.

When you add these five components across a three-year horizon, internal builds rarely win. For teams without fifteen-plus dedicated backend engineers, they almost never win.

5. Opportunity Cost 

This is the highest cost and the one no spreadsheet captures. Every engineer-month spent on auth, matchmaking, leaderboards, and economy systems is an engineer-month not spent on the game itself. Backend infrastructure is table stakes. No player ever bought a game because its matchmaking or live ops tools were built in-house. 

The opportunity cost surfaces in games that ship later, with fewer live ops features, into a market that did not wait. A studio that spends its first year building backend is a studio that spends its first year not building what wins players. That delay never appears on an invoice, which is why it gets ignored, and why it is usually the most expensive line of all.

What Your Best Engineers Should Actually Be Doing

This is not an argument for outsourcing engineering judgment or hollowing out your team. It is the opposite argument.

Your best backend engineers should not be writing matchmaking code that already exists. They should not be building leaderboard systems that are commercially available, tested at scale, and maintained by a dedicated team elsewhere. That is not the work that makes your game better. It is the work that keeps the lights on.

The studios shipping faster and operating more efficiently are not doing so because they have larger teams. They are doing so because they are deliberate about what their team builds versus what they buy. They reserve internal engineering for the problems genuinely unique to their game, the systems that cannot be purchased, the advantages that live in custom logic, the features players will actually notice.

Run the Actual Numbers

The build-vs-buy decision is not a value question. It is a math question with a values component. Studios that default to internal builds without running TCO are simply avoiding a number they have never seen written down.

Run the calculation. Include maintenance, evolution, and knowledge risk. Compare it honestly against what the external infrastructure actually costs. Then make the decision with clear eyes.

In the end, buying infrastructure is a capital allocation decision. And like any capital allocation decision, it deserves rigorous analysis rather than a gut default to 'we have the engineers.'