The build vs buy decision for a live-service game backend: what building from scratch really costs, what you give up by buying, and where source-available sits.
Build vs buy at a glance
| Category | Build in-house | Buy a platform |
|---|---|---|
| Time to market | Months to years before first live build | Weeks; backend exists on day one |
| Cost | Engineering salaries plus infra plus opportunity cost; runs into millions over a game's life | Subscription or usage fees; predictable line item |
| Control | Total. Every layer is yours to shape | Bounded by what the vendor exposes |
| Maintenance | Yours forever: on-call, patching, scaling, upgrades | Vendor handles platform; you handle your game logic |
| Scale | You build and prove it; mistakes surface in production | Inherited from a platform that's already done it |
| Source access | By definition | Usually none; most platforms are closed SaaS |
| AI-assisted dev | Build your own tooling | Varies by vendor; a source-available platform lets AI agents read the code (e.g. Metaplay Agent plus MCP servers) |
This table is missing a third column, which is what most of this article is about: source-available platforms let you buy the backend and still get the source.
Why every live game needs a backend
The build vs buy question applies to every live-service game, because every live-service game needs a backend. Player accounts have to persist, purchases have to be validated, configs have to update without a client release, and someone has to be paged at 3am when the database fills up. The question is whether you build these systems or pay for them.
The decision is often framed as binary. Build it yourself and you own everything but spend years getting there. Buy a closed SaaS and you ship fast but your data, your logic, and your continuity sit with a vendor. Each choice carries trade-offs.
A third path sits between them. We're Metaplay, and we ship a source-available platform: the full C# game server, Unity SDK, and Vue.js LiveOps Dashboard, delivered as source code and hosted by default on Metaplay's managed cloud, with self-hosting available. Building from scratch fits some teams, buying a managed platform fits others, and a source-available platform fits a third set. This article lays out what each route involves so the trade-offs are visible.
What a live-service backend actually requires
Building is expensive because a live game needs all of these systems, working together, in production, indefinitely. Here's the surface area:
| Subsystem | What it covers | Why it's hard |
|---|---|---|
| Identity & auth | Device, email, social, cross-device account linking, recovery | Account merging and recovery edge cases are endless; players lose devices |
| Persistence | Player state storage, schema migration, backups, consistency | Live schema changes on millions of rows without downtime or data loss |
| Server-authoritative logic | Validating every action server-side so the client can't cheat | Keeping client and server in agreement as the game changes weekly |
| Game configs | Tuning economy, content, and balance without a client release | Versioning, validation, staged rollout, instant rollback |
| LiveOps tooling | A/B tests, segments, scheduled events, offers, broadcasts | This is a product in itself, with its own dashboard and workflows |
| Economy and IAP | Currencies, inventory, store receipt validation (Apple/Google) | Fraud, refunds, receipt edge cases, store policy changes |
| Analytics pipeline | Event capture, transport, warehousing, reporting | Volume and reliability; one dropped event breaks a funnel |
| Admin and support tooling | Player lookup, state inspection, refunds, bans, mail, GDPR export | Support can't operate without it, and it's never "done" |
| Matchmaking & multiplayer | Pairing players, lobbies, match state | Latency, fairness, and scale all pull in different directions |
| Scaling & infra | Autoscaling, load balancing, regions, cost control | Getting it wrong appears as an outage during your launch spike |
| Security & anti-cheat | Server validation, rate limiting, exploit response | Adversarial and ongoing; attackers don't take breaks |
| Compliance | GDPR data export and deletion, audit logs, retention | Legal exposure; not optional in most markets |
| On-call and maintenance | Monitoring, alerting, incident response, upgrades | Ongoing for the life of the game, and often omitted from the original plan |
You can ship without all of these on day one. You can't operate a successful live game without most of them eventually, and the ones you skip early tend to become emergencies later, usually right when the game is taking off and engineering attention is scarcest.
What building a game backend really costs
The primary cost of building is engineering time. In 2024 we ran our own survey of 125 senior executives and tech leads at US mobile studios (minimum 50 staff), asking what their proprietary backend tech cost. The average came to about $21.7M per studio, built on three numbers from that survey:
- $138,864: average salary of an engineer working on internal backend tech
- 52: average number of people working predominantly on internal tech
- 36 months: average time these studios had been building it
That's self-reported data from a survey we published, so it reflects the industry describing itself rather than an independent audit. The full breakdown, with methodology, is in The True Cost of Building Your Own Game Backend.
Those are big-studio figures; a small team building a leaner backend won't spend anything like $22M. Our own analysis puts the cost of building backend technology in-house at around $21M over a typical multi-year build (The true cost of building your own backend). The structure holds at any scale: a backend is several engineers for several years, and the work continues after launch. Salary is the direct cost. Other costs are less visible.
Time to market. Three years of backend work is three years your competitors might spend shipping content and acquiring players. Markets and platform rules move; a backend that was state of the art when you started can be behind by the time it carries real traffic.
Opportunity cost. Every engineer on infrastructure is an engineer not on the game. In the same survey, 74% of studios that built in-house said game programmers had been pulled onto internal tech instead of game content. Of those, 41% reported slower development, and 34% each reported more crunch and higher turnover.
Ongoing maintenance. A backend isn't a project you finish; it's a system you run. After launch, the same team that built it is on call for it: patching, scaling, migrating schemas, chasing exploits, answering support escalations.
That load competes with the live game for the life of the title, and it's the cost least likely to appear in the original plan. Our co-founder's five years of lessons building a backend catalogs problems that surfaced once real players arrived.
For the wider industry view on this trade-off, Backend Tech: Build or Buy? The Industry Weighs In collects on-the-record takes from studio leads who've lived both sides.
When building your own backend is the right call
Building fits some teams. The conditions where it tends to make sense:
- Your requirements are novel. If your core loop depends on backend behavior no platform models, such as bespoke physics-authoritative netcode, an unusual real-time simulation, or a data model nothing off the shelf fits, you may spend more bending a platform to your needs than building the slice you actually require.
- The backend is your competitive edge. Some studios treat backend tech as a strategic asset and reuse it across a portfolio. Several large studios run bespoke stacks for this reason. When the backend is part of the moat, owning every layer carries a clearer return on the spend.
- You have the team and the runway. If you already employ an experienced backend group and have the budget to support them for years, including the post-launch years, building is a viable option.
- You need total control for compliance or platform reasons. Some regulatory or contractual situations genuinely require owning every component.
These conditions share a common thread: they're all about ownership and control over the backend.
What you give up when you buy a backend
Buying a managed backend addresses the cost problem directly. The systems already exist, a team operates them, and you build your game on working infrastructure in weeks rather than years. Closed platforms like Microsoft's PlayFab take this route; Microsoft says PlayFab powers titles including Minecraft and Sea of Thieves. We compare one such platform in Metaplay vs PlayFab.
In exchange for that speed, most managed backends involve the following trade-offs:
- Lock-in. Your game's logic and data live inside the vendor's system. Leaving means re-implementing on a new backend and migrating live player data, which is expensive and risky, so most teams never do it.
- No source. When you hit a wall, whether a behavior you need to change or a bug deep in the platform, you file a support ticket rather than read the code. You extend through whatever hooks the vendor exposes and stop where they stop.
- Someone else owns your data. Player data sits on the vendor's infrastructure under the vendor's terms. That's fine for some studios and a real concern about control and residency for others.
- Pricing you don't fully control. Usage-based models can make costs hard to forecast as you scale, and the vendor sets the meter.
So the typical buy decision trades the ownership and control that drive teams to build for the speed and reduced operational load that draw teams to a managed platform.
The third option: a source-available backend
A source-available backend gives you the working systems and the source code. You don't build the backend from zero, and the platform isn't a closed box. This is the third column the two-column table at the top leaves out.
This is what we do at Metaplay. You get a complete, production-grade backend on day one, plus the full source for the C# game server, the Unity SDK, and the Vue.js LiveOps Dashboard. The source can be read, modified, extended, and forked.
By default Metaplay runs it for you on its managed cloud (Kubernetes on AWS); because you hold the source, you can self-host it on your own AWS account via the Private Cloud plan, or fork it. This is the no-lock-in property: if you leave, you keep the source and the game keeps running.
What you don't do is build the surface area from the table above. It's already there:
- Server-authoritative game logic, written once in C# and run on both the Unity client and the .NET server, so the client stays responsive and the server stays the source of truth
- LiveOps: a customizable dashboard, A/B testing, game configs driven by Google Sheets or CSV with over-the-air updates, player segmentation, scheduled live events, and offers
- Economy with server-side IAP validation for the App Store, Google Play, and Steam
- Async matchmaker, leaderboards, guilds, in-game mail and broadcasts
- Analytics export to BigQuery or S3, built-in GDPR data export and deletion, and BotClient for load testing up to millions of simulated users
The platform also includes tooling for AI-assisted development. Metaplay Agent (currently in public preview) installs SDK skills for coding agents working in a Metaplay codebase, with Docs and Portal MCP servers exposing documentation, SDK source, and live infrastructure to those tools. Because you have the source, an agent can read the system it's changing rather than guess at an API.
Metaplay was founded in 2019 by people with backgrounds in the game and software industries, and studios such as Metacore, Trailmix, and Lessmore run on it in production. The scaling decisions built into the platform have already run under real player traffic, rather than being worked out during your own launch spike.
The platform has limits that bound where it applies:
- The client SDK is Unity-first. Unreal and custom engines get API access only, not a native SDK with the shared-logic benefit, though Unity WebGL builds are supported
- The matchmaker is async only; there's no synchronous real-time matchmaker
- There's no built-in physics engine for FPS-style authoritative hit detection
- No built-in voice or chat. You integrate a third-party service
A game whose core depends on synchronous shooter netcode or native console auth needs those from elsewhere: a closed platform that ships them, or a bespoke build.
The pricing model is a flat plan plus a per-day DAU licence fee: the Production plan is €1,985/month and includes the first 5,000 DAU per day, then €2.95 per 1,000 DAU per day above that. A game holding 100,000 DAU every day for a 30-day month works out to about €10,392.50/month all-in. At that scale the platform costs roughly what a single experienced backend engineer does, against staffing a full backend and DevOps team in-house for the life of the game. The exact tiers and a live worked example are on the pricing page.
Source-available sits on a different axis from the build-or-buy split: it pairs source access and data ownership, the properties that lead teams to build, with prebuilt systems and a subscription cost, the properties that lead teams to buy. Whether that combination fits depends on the requirements above.
When each approach fits
| If this describes you... | Route that matches |
|---|---|
| Novel backend requirements no platform models | Build in-house |
| Backend is a strategic asset reused across titles | Build in-house |
| Strong backend team plus multi-year runway | Build in-house |
| Need to ship fast with the smallest possible ops burden | Buy a closed platform |
| Comfortable with vendor lock-in for full convenience | Buy a closed platform |
| Want working systems now, but also source and data ownership | Source-available |
| Building on Unity and C# | Source-available |
| Need to read and modify backend behavior, not file tickets | Source-available |
| Want to avoid lock-in and keep the option to self-host or fork | Source-available |
| Predictable, DAU-based pricing you control | Source-available |
Build vs buy FAQ
How much does it cost to build a game backend in-house?
Expect several engineers over several years, plus ongoing maintenance for the life of the game. In our own 2024 survey of 125 senior executives and tech leads at US mobile studios (minimum 50 staff), the self-reported average came to about $21.7M per studio: roughly 52 people working about 36 months at an average salary of $138,864. That's vendor-published survey data, and it skews to large studios. A small team building a leaner backend spends far less, but the structure is the same.
Should an indie studio build its own backend?
Building even a minimal live-service backend is a multi-year commitment for several engineers, which is headcount an indie team would otherwise put on the game itself. The case where a build can still make sense is when the core loop depends on backend behavior no platform can model. Where that doesn't apply, buying or using a source-available platform provides working systems in weeks, leaving the small team on game content.
How many engineers do you need to build a game backend?
A realistic minimum is around five engineers to cover the core surface area: identity and persistence, server-authoritative logic, LiveOps tooling, economy and IAP, and the infra and on-call to run it. Studios that built full proprietary stacks in our survey averaged 52 people on internal tech, so five is a floor for a lean build, not a comfortable team for a large live game.
Isn't buying a backend always cheaper than building one?
Often, but not always. If your game needs backend behavior no platform supports, forcing a platform to fit can cost more than building the part you actually need. Buying a closed platform also carries less visible costs in lock-in and reduced control. Source-available platforms keep the prebuilt systems while returning source access and data ownership, which addresses those particular costs.
What's the difference between buying a SaaS backend and using a source-available one?
A closed SaaS hosts everything and gives you no source, so you extend it only through the hooks it exposes and your data lives on the vendor's infrastructure. A source-available platform like ours ships the full source code, runs by default on its own managed cloud, and lets you self-host on your own infrastructure if you choose, so you can read and modify any part of it and fork the codebase if you ever leave.
How long does it take to get a backend running with a platform versus building one?
With a platform, the backend exists on day one and integration is typically a matter of weeks. Building a comparable backend in-house is a multi-year effort before it's carrying real production traffic, and then it still needs ongoing operation.
How much does a managed game backend cost?
It depends on the model. Metaplay charges a flat plan plus a per-day DAU licence fee: the Production plan is €1,985/month including the first 5,000 DAU per day, then €2.95 per 1,000 DAU per day above that, so a game at 100,000 DAU every day costs about €10,392.50/month. Usage-based competitors meter different things (API calls, MAU, compute), so compare against your own traffic shape. The pricing page has the full tiers and a worked example.
Can I start on a platform and move to my own backend later?
With a closed SaaS, leaving means re-implementing on a new backend and migrating live data, which is why few teams do it. With a source-available platform you already have the source: Metaplay runs it for you on its managed cloud by default, and because you hold the code, moving to self-hosting is a supported path rather than a rebuild. See our pricing for the plans, including a Private Cloud option for self-hosting.
Last updated: June 2026. Pricing and features may change. See Metaplay pricing, book a demo, and the Metaplay docs. For more on the build vs buy decision, read The True Cost of Building Your Own Game Backend and Backend Tech: Build or Buy? The Industry Weighs In.
