Build Your Own Runtime or Use a Platform?
Every serious team hits the same fork around month three: "why are we paying a platform cut when we could just run our own runtime?" It's a fair question and sometimes the right answer. But the version of that question most teams ask leaves out the parts that actually sink budgets. Let's walk the real trade.
Q: Should we build our own runtime or use a platform?
Build it yourself only if the runtime is your product, not your distribution. If you're a game studio, your runtime is overhead — it's the thing you maintain so players can open the game, and every hour spent on it is an hour not spent on the game. A shared platform turns that fixed cost into a variable one you stop paying attention to. The teams that should build their own are the ones selling runtime to others, not the ones who just want to ship a game.
Q: What does self-hosting actually cost that the pitch deck hides?
Three things nobody budgets: the compatibility tax (every OS update, every new device breaks something and you eat it), the payment integration tax (local rails in every market are a project, not a line item), and the cold-start problem (you have no audience, so you're also buying UA on top of building infra). A platform bakes all three in. Self-hosting them is a second company hiding inside your first.
Q: Won't a platform lock me in?
Lock-in is real, but it's rarely the dramatic "they hold my users hostage" story. The real lock-in is operational: your analytics, your billing flows, your release habits all bend to their API. The mitigation isn't building everything yourself — it's keeping your game logic portable. A universal runtime that speaks a standard you control means you can lift and shift. Build the portability, not the whole stack.
Q: When does building your own actually make sense?
When scale makes the cut bigger than the build. If you're moving millions of monthly players and the platform take is your largest line item after UA, the math flips. Or when you need controls a platform won't give you — specific sandboxing, specific data residency, specific payment terms. Most teams reach that point far later than they think, and some never do.
Q: How do we keep control without building the whole thing?
Treat the runtime as a standard, not a vendor. Write your game against an open runtime spec, keep your own user data and billing relationship where you can, and pick a platform whose exit is a config change rather than a rewrite. The goal isn't independence theater — it's not being unable to leave. A team that can leave is a team that negotiates from strength.
| Dimension | Build it yourself | Use a shared platform |
|---|---|---|
| Upfront cost | high (months of eng) | low (integrate and ship) |
| Per-market payments | you integrate each rail | bundled |
| Audience | you buy all UA | shared warm base |
| Compatibility risk | yours to eat | absorbed |
| Exit cost | none (you own it) | depends on portability |
| Right when | scale beats the cut | you want to ship a game |
