Every online game needs a backend. Player accounts, matchmaking, lobbies, inventories, stores, leaderboards, telemetry and server orchestration all have to exist somewhere, and for each one a studio has to decide whether to build it, buy it from a provider, or use a mix of both. Those decisions are often made early, under time pressure, and they shape the game's costs and flexibility for years.
Our engineers have spent 19 years running large online systems, and a good part of our technology advisory work is helping studios make these calls before they commit. Here is how we think about it.
Most online games need some version of the following:
Each of these can be bought as a managed service, built in-house, or assembled from open-source parts. Very few studios build everything, and very few buy everything.
If a system is central to how your game plays, such as a matchmaker for a competitive game with unusual team rules, owning it gives you room to tune it. If a system works the same way in most games, such as a basic leaderboard, a proven service is usually the sensible starting point.
Many managed services price per monthly active user, per request or per server hour. That can be very reasonable at launch and expensive at scale, or the other way round. Model the cost at your expected peak, at a healthy steady state and in the long tail years after launch. In one six-week infrastructure audit, we found enough waste to cut a game's infrastructure bill from $500K a month to $250K a month, which shows how far costs can drift when nobody revisits these choices.
Providers change their pricing, change their roadmap and sometimes close services altogether. Before you commit, check whether you can export your data, how closely your game code is tied to the provider's SDK, and how long a move to something else would take. A thin layer of your own code between the game and any third-party service makes a later switch far easier.
Building a service is only part of the work. Someone has to monitor it, patch it, scale it and respond when it fails during a live event. If your team does not have people to run a system around the clock, a managed service or a partner who operates it for you may be the better choice even if building it looks cheaper on paper.
Player data rules, regional storage requirements and platform holder policies can rule some providers out. If your studio has foreign ownership, or handles data for players in regions with strict residency rules, check these before you compare features.
A managed service can get a prototype online in days. Building production-ready services takes longer, and the schedule risk is real if launch is close. A common approach is to buy for launch, with a clear plan for which systems you would bring in-house once the game has found its audience.
For most studios, the answer is a mix. They buy or use proven services for commodity systems, build the parts that define the game, and keep a clean interface around each so they can change their minds later. The details depend on the genre, the scale, the team and the business model, which is why a review against your own plans is worth doing before you sign a long contract.
Terminal Velocity's technology advisory service reviews your architecture, vendor choices and technical plans before you commit to them. Senior engineers lead each engagement, and it ends with clear recommendations on what to build, what to buy and who should run it. Our reviews cover:
For one multiplayer FPS studio, a three-month engagement delivered a production-ready Linux server binary, a hardware performance analysis and a full vendor evaluation. The same engineers can carry on into implementation if you want them to. See our technology advisory work or start a conversation.
Most studios do both. Buy or reuse proven services for systems that work the same in most games, and build the parts that define how your game plays or where off-the-shelf pricing does not work at your scale.
Yes. Our vendor selection work compares providers, platforms and build or buy options against your game's needs, costs and long-term plans.
Yes. A launch readiness review looks at capacity, costs and likely failure points before a launch or a period of growth.
Yes. The senior engineers who carry out the review can continue into implementation if you want them to.