The most expensive sentence in mobile gaming: "we'll build it in-house"

The real cost of standing up a LiveOps stack you were never meant to own, and why the smartest studios spend their engineering budget somewhere else.

Every studio that ships a live game hits the same fork. Launch goes well, the game grows, the user base builds. Then the easy growth flattens and the question shifts from "how do we get more players" to "how do we do more with the ones we have." The team agrees it needs better LiveOps, and someone in the planning meeting says the sentence that quietly reshapes the next two years of the roadmap: "we'll build it in-house."

The instinct is right about one thing. LiveOps is where the next stage of revenue comes from. Done well, it can lift revenue by tens of percent, sometimes more, off the same user base you already have, by getting the right offer, message, and reward to the right player at the right moment. The flip side is just as real. Not doing LiveOps, or doing it badly, leaves those same tens of percent on the table. That is what makes the decision that follows matter so much, because "we'll build it in-house" is quietly the most expensive sentence in mobile gaming.

I have had this conversation hundreds of times with studios of every size, and before that I lived it at Playtika, one of the few companies with the scale to actually build LiveOps in-house. I still remember a feature that looked trivial on the roadmap, a timed offer that was supposed to react to a player's last session, taking months of backend work before it fired reliably. That was with a dedicated platform team and real resources behind it. Seeing what serious internal tooling actually costs, then hearing the same story from teams trying it with a fraction of that, convinced me the build instinct is almost always a trap. The pattern repeats too cleanly to be coincidence.

The obvious cost is the one you underestimate

A real LiveOps layer is not a config file and a cron job. It is real-time segmentation, sophisticated flows, dynamic content, an in-app messaging engine with scheduling and lifetime rules, push by timezone, A/B testing with valid readouts, remote feature configuration, and a dashboard a non-technical operator can actually run. None of that gets built in a quarter or two. The publishers who genuinely did it spent years and dedicated platform teams most studios can't staff. For the few who pulled it off, five years before the thing really worked wasn't a horror story. That was just what it cost.

The partial tax you pay forever

Here's the real trap. You can't build the whole thing, so every feature ships at maybe seventy percent. The popup engine works but stays basic. Cooldown logic is thin, so players get hammered or go quiet. Frequency capping sits on the backlog. And it never really stops being partial. That becomes the ceiling you live under, and every gap turns into a ticket, and every ticket into a dependency on the engineers who were supposed to be building your game.

The hard parts are where it breaks

The hardest part is the part nobody sees. Truly real-time LiveOps means ingesting every event as it happens, updating each player's state in milliseconds, and evaluating segments and triggers on the fly so the system can react in the moment instead of on tomorrow's batch job. That event pipeline and low-latency state engine is the infrastructure that makes the difference between reacting with the right experience at the right moment and sending a message an hour too late. It is also the piece studios almost always underbuild.

Take real-time journeys. A player finishes a level, and within seconds you want the right message, offer, and reward, gated by who they are and what they've already seen and done. Doing that at scale, with cooldowns and exit rules and channels that don't step on each other, is hard engineering, and most in-house versions fire late, double-send, or only handle the one path someone had time to code. Dynamic content is the same wall: operators want to change an offer, a banner, a price, a missions flow without shipping a build, and most in-house tools ship a handful of remote values and call that dynamic. Sophisticated flows raise it again, chaining conditions, wait timers, branches, rewards, and webhooks with recurrence and exit rules. Engineers who take that on from scratch realize a few weeks in that they're building a workflow engine, not a feature, and that is undifferentiated infrastructure a studio has no business writing.

The maintenance bill nobody signs off on

Whatever you build, you now own, and owning it means maintenance. This is the part nobody signs off on, and the industry numbers are brutal. Roughly 80 percent of a piece of software's lifetime cost lands after launch, with maintenance running an estimated 15 to 25 percent of the original build every single year. Every OS update, every new ad network, every edge case in production, every operator who needs a field that doesn't exist yet lands on the same small group of engineers. Every hour spent patching your own LiveOps system is an hour not spent on the thing players actually open your game for. It compounds too. The engineer who built your segmentation logic leaves and the knowledge walks out with them, the next hire reverse-engineers a system with no docs, and the gap between what operators want and what the tool can do keeps widening. You slowly fall behind a whole category of platforms whose entire job is to keep moving.

Build where you're unique, buy where you're not

Studios should pour their engineering talent into the features and systems that make their game feel like theirs. LiveOps plumbing isn't that. The urge to build it comes from wanting control, but control over a half-finished internal tool isn't really control, it's a maintenance queue with your name on it. Real control is launching, testing, and adjusting an experience in minutes, without a release, without a ticket, without pulling an engineer off the roadmap.

So when you total up what "we'll build it in-house" really costs, it comes down to two things. The cost is dev time that should have gone into the core game, the thing your studio is actually great at. Studies of internal platforms put it in perspective: teams routinely spend between 10 and 40 percent of their engineering time managing their own infrastructure and tooling instead of shipping product. And the cost is poor LiveOps that never quite works, leaving a lot of money on the table month after month. Pay both of those for years, or run LiveOps on a platform like Kinoa and keep your engineers on the game only you can build. For almost every studio, that's not a close call. If you're weighing that decision right now, it's worth pressure-testing the build estimate before you commit to it. Book a call with us and we'll walk through what a platform actually takes off your team's plate.