Is the future of game development a pipeline built around teams of five, four-month prototype cycles, and a curated player community that gates which ideas move forward?

Avalanche Studios seems to think so. In a recent profile on gamesIndustry.biz, Chief Publishing Officer Emma Farrow described exactly that model: games that don't prove themselves get killed, and culling is treated as proof the process is working. As Michael Duning-PTC put it when observing the piece:

"The ideas that survive are the ones that prove themselves."

What follows is our read on what that development model implies for the build vs. buy decision in game server infrastructure. This is the perspective of Mathieu Duperré, Founder and CEO at Edgegap, rather than a claim about what Avalanche said or does.

A Pipeline Built on Expected Failure

Avalanche's approach is a direct transplant of mobile development discipline into PC and console. Supercell is the canonical example from mobile:

• multiple small teams,

• aggressive culling,

• the occasional breakout that funds everything else.

Of their last 10 games at one point, seven were killed in prototype, two in soft launch, and one (Clash Royale) launched globally. Farrow describes structurally the same thing, just for PC and console audiences.

The logic is sound. Front-loading creative validation while teams are small keeps the expensive questions cheap. Does this feel fun? Is there an audience for it? Those are best answered at month four with five people, not month thirty-six with two hundred. And when a prototype dies, Farrow frames it as proof the process is working, not evidence of wasted effort.

That reframing matters.

In this model, money spent on prototypes that don't ship is not waste. It's the cost of finding the one that does.

The Infrastructure Math That Most Studios Miss

Here's where the build vs. buy question for game servers gets interesting.

Traditionally provisioned infrastructure (reserved instances, pre-bought capacity, dedicated fleets) is designed for a known game with sustained, long-term load. It amortizes well when one title runs for years. It amortizes poorly when the expected outcome is that most projects get cancelled.

A studio running three prototypes in parallel, each with a monthly community playtest, faces a different question than a studio shipping a single live-service game. The question isn't "how do we scale for launch." It's "how do we avoid paying for servers on games that will never ship." Those are different problems, and most traditional hosting solutions are built to answer the first one.

On-demand orchestration changes the math. A prototype running roughly 100 hours of online community testing in a month costs a few dollars on a pay-per-use platform, a far cry from the hundreds or thousands that reserved capacity implies. That's not a marginal improvement. It's a different category of financial commitment, one that makes running four or five parallel prototypes economically coherent rather than reckless. Edgegap's pricing calculator makes this concrete: studios can test what their actual testing hours would cost before committing to anything.

The Five-Person Team Problem

There's a second implication, less about money and more about time and organizational drag.

A five-person prototype team has a programmer, a designer, maybe one generalist wearing several hats. There is no room for a dedicated infrastructure engineer. If setting up multiplayer testing requires Kubernetes configuration, container registry management, or negotiating reserved capacity, one of two things happens. The prototype skips multiplayer testing entirely, which produces weaker signal from the community playtest. Or the team waits on central DevOps, which quietly kills the iteration speed the whole model depends on.

There's also the question of what "building your own" actually means at scale. Open-source orchestration platforms like Agones require deep Kubernetes expertise to run well, ongoing maintenance, and dedicated engineering time just to keep the lights on. Studios that invest in that infrastructure sometimes rationalize it as amortizable across projects. But in a model where most projects die, those "central services" still get billed internally to every prototype, inflating the cost of each small bet and raising the revenue threshold a game needs to hit before it pays for itself. That's the opposite of what rapid iteration requires.

Self-service, on-demand orchestration removes that bottleneck. The prototype team spins up a server, runs the playtest, and moves on. No tickets filed. No waiting. And if the game gets cut at month four, no infrastructure debt carried forward. Edgegap's orchestration platform boots game servers from cold start in an average of 3 seconds, which is the kind of turnaround a small team running a time-boxed playtest session actually needs.

An Informed Opinion: What This Means for Build vs. Buy

To be clear, this is our perspective rather than an established pattern across the industry.

In our view, studios choosing to make many small bets are also, implicitly, choosing to buy rather than build infrastructure, whether they have framed it that way or not. Building custom server infrastructure only makes economic sense if one large game will amortize that investment over a long horizon. A model that assumes most projects fail by design is structurally the wrong place to build.

We're seeing this play out with studios on Edgegap's platform. Halfbrick Studios, the publisher behind Fruit Ninja, used on-demand orchestration for Thrill of the Fight 2, a smaller-budget title that needed real multiplayer infrastructure without a dedicated DevOps team to run it. A small game, treated with the same infrastructure seriousness as a large one, without the large-game cost structure. That's the model. Some of the largest studios in the world, ones whose names you'd recognize immediately, use the same approach for exactly the same reason: variable output requires variable costs, and the alternative is paying for infrastructure on games that never ship.

The studios that recognize this early run leaner prototyping cycles. The ones that don't carry infrastructure costs on games that never ship, which makes the entire rapid-iteration model more expensive than it needs to be. The mobile industry learned this over years of iteration. PC and console studios adopting the same development philosophy don't have to learn it the slow way.

—

This article is inspired by and cites the reporting of Lewis Packwood, published on GamesIndustry.biz on March 10, 2026, and the observation of Michael Duning-PTC, published on LinkedIn. All rights in the original content are owned by their respective owners.