The Build Trap - Why decisions to build in-house feels right - and what it actually costs

The decision that feels obvious

There is a moment most media organisations know well. The available tools don't quite fit. The agency stack is a black box. The data lives somewhere nobody fully controls. And someone in the room says: we should just build this ourselves.

It's a reasonable instinct. The organisation knows its own workflows better than any vendor. The requirements are specific. The team is capable. And owning the infrastructure feels like exactly the right move.

So the decision gets made. A team is assembled. A timeline is set. And the build begins.

The prototype is not the product

The first months are encouraging. A prototype takes shape. Basic functionality works. The team shows early results.

What's rarely visible at this stage is the distance between a working prototype and something that can run in production. These are not gradual differences. A prototype needs to work. Production infrastructure needs to work under load, over years, with changing teams, with data that evolves, with requirements nobody could anticipate at the start. Error handling. Audit trails. Versioning. Scaling. Security. Compliance.

None of these are features you add later. They are what the whole thing stands on.

What the budget does not capture

The direct costs of an in-house build are easy to see: developers, infrastructure, tooling. What rarely gets accounted for is everything else.

Every hour an internal team spends on infrastructure maintenance is an hour not spent on media strategy, optimisation, or client work. That trade-off compounds. Over two years, it often turns out that a significant portion of the organisation's technical capacity has been absorbed by a system that was supposed to free up capacity.

There is also the question of continuity. In almost every in-house build, there is eventually one person who truly understands the system who knows why certain architectural decisions were made, who carries the undocumented dependencies in their head. When that person leaves, and at some point they always do, the gap they leave behind is hard to quantify and harder to close.

Software that is not actively maintained becomes outdated fast. Every new channel, every new data requirement, every compliance change means adaptation work. What starts as a lean internal tool becomes a full-time project without anyone having consciously chosen that outcome.

The signs that the calculation has shifted

The symptoms of a build trap tend to show up long before anyone names them as such:

• The original team has partially moved on, and the system knowledge moved with them
• New requirements a new market, a new reporting need each require more effort than they should
• Documentation exists but has gaps nobody has time to close
• AI tooling has been evaluated or piloted, but connecting it to the in-house stack is a project in itself
• The question of rebuilding versus maintaining gets raised periodically and never fully resolved

Individually, each of these feels like a manageable issue. Together, they describe the same pattern: the infrastructure has become a cost centre, not a capability.

AI makes the cost visible

AI did not create this problem. It made the consequences harder to absorb.

Deploying AI on top of a self-built, maintenance-heavy infrastructure usually fails not because of the AI itself, but because of the data underneath it. Inconsistent structures, missing schemas, data points that do not connect. AI needs clean, structured, reliable inputs. What an in-house build accumulates over years is usually the opposite.

The organisations using AI productively in media right now share one thing: they had a solid data foundation before they started. Not afterwards. Before.

The decision nobody revisits

Building in-house is rarely the wrong call because of a lack of ambition or skill. It becomes the wrong call when nobody stops to ask whether the infrastructure being built actually differentiates the business or whether it just needs to exist.

Infrastructure that does not directly differentiate the core business is a running cost. It grows. It ties up people who could be doing something else. And once it is embedded, it is very hard to walk away from.

Building the foundation matters. Whether you need to build it yourself is a different question entirely.

Where Mercury fits in

Mercury has been developed inside real media operations environments since 2012. Not in a lab inside real, high-complexity operations, long before the term "AI-ready infrastructure" existed. That means the system was designed around the actual friction of media operations: multi-agency coordination, budget management complexity, reporting gaps, the need for a record that survives every technology cycle.

The result is a media operations platform that functions as a system of record open, agency-agnostic, API-first. It doesn't compete with the tools an organisation already uses. It gives them solid ground to stand on.

Building in-house made sense before that ground existed. It makes less sense now.

The foundation is ready. The question is whether to keep maintaining your own.