Build it yourself, or buy the outcome? The real cost of building in-house.

The Build-vs-Buy Maths Has Quietly Changed

Every asset manager reaches the same fork. The data is scattered across a custodian, a fund administrator, a registry, a CRM and a market-data feed. The board wants AI. The distribution team wants better reporting. And someone in the room says the words that have launched a thousand budget overruns: “We could just build this ourselves.”

It’s a reasonable instinct. You know your mandates better than any vendor. You’d own the IP. No licence fees. Full control. On a whiteboard, building in-house always looks cheaper and cleaner than it turns out to be.

But the maths that made “build” defensible a decade ago has inverted. Engineering talent is more expensive and harder to retain. The surface area you have to build — integrations, data quality, compliance logic, analytics, and now an AI layer that changes every quarter — has exploded. And the failure statistics for in-house software and AI projects are not close calls. They are landslides.

This isn’t a vendor telling you building is always wrong. Sometimes it’s right. This is the evidence on the table, so you can make the call your board can defend in two years’ time — not just the one that feels good in the meeting.

The Numbers That Never Make the Board Pack

When an internal build gets approved, the slide shows a tidy timeline and a one-off cost. What it never shows is the base rate — how projects like this actually land across the industry. Here is that base rate.

Read those together. The most likely outcome of a serious in-house build isn’t failure — it’s a project that ships late, costs far more than the slide promised, and delivers materially less than it was sold on. And roughly one in six doesn’t just overrun, it detonates. None of this is because your team is weak. It’s the base rate for the category, measured across thousands of projects by McKinsey, Oxford, Gartner and Harvard. Building in-house means betting you’re the exception.

Cost: What Building In-House Really Costs

Start with the people, because that is where 80% of the real cost lives — and it’s the line that the “no licence fees” argument quietly ignores.

To build and run a data-and-AI platform properly, you don’t hire one developer. You need data engineering to wire up and harmonise the feeds, platform/DevOps to keep it running, and someone who can own the AI layer. In Australia a single senior data engineer averages around $145k base — and well over $160k in Sydney — before superannuation, recruitment, tooling, cloud and the on-costs that push a fully-loaded figure well above the headline. A genuinely capable in-house team is comfortably north of $700,000 a year, every year, and that’s the run-rate before the platform has delivered a single report.

Then layer on what the board pack leaves out:

• The overrun premium. If your build behaves like the average (45% over budget, per McKinsey and Oxford), a $1M plan is a $1.45M reality.
• The value gap. The same study found large IT projects deliver 56% less value than projected. You don’t just pay more — you get less.
• The opportunity cost. Every engineer-month spent on plumbing is a month not spent on the thing only your firm can do: managing money and winning mandates.
• The maintenance tail. The build cost is a one-off. The maintenance cost is forever — and it never appears on the business case.

Risk: The Bill That Arrives After Go-Live

Cost is the part you can model. Risk is the part that decides whether the build was a good idea — and it almost all arrives after the launch party.

Key-person risk is the quiet killer. When you build internally, the knowledge of how everything fits together lives in two or three heads. The day your lead engineer resigns — and in a market this competitive, they will — a meaningful chunk of your platform becomes a black box nobody fully understands. The integrations still run, until an API changes and no one knows which script to fix. For a lean firm, this isn’t a hypothetical. It’s the single most common way in-house platforms quietly rot.

The maintenance tax never stops. Custodians get acquired. Registries change formats. Regulators tighten reporting. Every one of those is a ticket your team has to service before they do anything new — and the larger the platform, the larger the share of capacity that goes to simply keeping the lights on rather than building anything that moves the business forward.

The AI layer is a moving target. This is what’s new since the last time “build vs buy” was a clean decision. Models that lead today are mid-pack in six months. An in-house AI stack is a snapshot of the best thinking on the day it shipped — and it starts ageing immediately. Gartner’s warning that 60% of AI projects will be abandoned through 2026 for want of AI-ready data is, underneath, a story about firms that built before their foundations could carry it.

Compliance risk is asymmetric. A reporting bug in a marketing tool is an inconvenience. A breach that isn’t caught, or a regulatory report that’s wrong, is an existential, career-ending event. When you build in-house, that risk sits entirely on your firm’s balance sheet and your name. When you buy the outcome, it sits with a partner whose whole business is getting it right.

Speed: Your 18-Month Head Start Is Gone the Day You Ship

Here is the argument that should worry a CEO most, because it’s the one cost and risk modelling miss entirely.

Building a serious platform internally is a 12–18 month exercise — if it goes well. During those months, your competitors who bought the outcome are already live, already learning, already compounding. By the time your build ships, the goalposts have moved: a new LLM has changed what’s possible, a new regulation has changed what’s required, and the version of the world you scoped for 18 months ago no longer exists.

This is the cruel twist of building in a fast-moving domain. The bespoke platform that costs $5M and 18 months to build is obsolete on a faster clock than you can amortise it. You don’t get to enjoy your head start — you spend it.

The economics of delivery have changed underneath the whole question. AI has collapsed the cost of integration, configuration and bespoke build — which means a partner can now deliver in weeks what used to take a consulting team half a year, and keep delivering as the world changes. A platform that improves continuously beats a platform that shipped once, every time.

The Two Costs a Spreadsheet Misses: Focus & Culture

Cost, risk and speed are the arguments that fit in a model. The two that most often decide whether the whole thing works never make the business case — and they both cut the same way.

Build, and your best people stop doing their actual job

An asset manager’s edge is investment judgement and distribution relationships — not data pipelines. The moment you commit to building in-house, your sharpest operations, data and analytics people get pulled off the work that compounds the franchise and onto plumbing that every firm needs and none competes on. The cost isn’t just their salary; it’s the mandates not won and the clients not seen while they’re debugging a custodian feed. Every hour your team spends being a part-time software company is an hour it isn’t spending being a better asset manager.

This is the most expensive line item that never appears on the build business case: not the engineers you hire, but the attention of the people you already have. Buying the outcome is how you keep scarce talent pointed at the only things that actually differentiate you — and let someone whose entire business is the platform carry the rest.

A partner can enforce a change of culture an internal team can’t

New technology only pays off if people actually change how they work — and change management is where internal builds quietly die. An internal team has to persuade colleagues, peers and sometimes their own managers to abandon the familiar spreadsheet, with none of the authority to insist on it. The path of least resistance is the old way, adoption stalls, and a capable platform slowly becomes shelfware that nobody can quite justify replacing.

An outside partner changes that dynamic entirely. They arrive with an explicit mandate, an implementation discipline, and the distance to enforce a new way of working that an internal colleague never has — precisely because they aren’t entangled in the firm’s history, politics or personal loyalties. They can standardise the workflow, retire the workarounds, and hold the organisation to the new process. Counter-intuitively, the very fact that they’re not one of you is what lets them shift the culture. Change is easier to accept from a specialist you brought in to deliver it than from the colleague down the hall.

“But We’re Different” — the Four Build Arguments, Answered

Every build decision is defended with the same four arguments. They’re not wrong, exactly — they’re just incomplete. Here’s the honest other half of each.

Specificity is the argument that sounds most convincing — and it’s the one outsourcing actually answers best. The fear is that a vendor gives you a generic tool you have to bend your firm around. But buying the outcome is the opposite of buying a generic tool: your mandates get encoded as rules, your reporting cadence and formats are built to your spec, and your data sources are connected and owned for you. You get the tailoring without the team.

What Buying the Outcome Looks Like

“Buy” doesn’t have to mean a shrink-wrapped SaaS licence that you then spend six months and a consultant configuring. At Datafabric it means something closer to an outsourced platform team that owns the result, not just the software.

We own the integrations. Custodian, fund admin, CRM, registry, market data — connected, harmonised and maintained inside The Foundry. APIs change, we handle it. You never staff a data-pipeline team.

We own the configuration. Compliance rules, reporting templates and distribution workflows are built for your firm, not a generic default — and updated as your mandates change. No internal project manager, no roadmap politics.

We own the AI layer. Sherpa routes each task to the best available model, so “upgrading your AI” is something that happens automatically, not a migration project you scope and staff.

We own the outcome. Did the reports ship on time? Did breaches get caught? Did the distribution team hit target? If not, that’s our problem to fix — not a ticket in your backlog. That single line is the difference between buying a tool and buying an outcome.

The result is the thing the build promised but rarely delivers: a tailored, mandate-specific, AI-native platform — without the payroll, the key-person risk, the maintenance tail or the 18-month wait. Live in weeks, improving every month, at a fixed and known cost.

A Two-Minute Build-vs-Buy Test

Before you green-light an internal build, put it through these four questions. Answer them honestly and the right call usually answers itself.

There are genuine cases where building wins — usually when the system is your edge and you have the team to carry it indefinitely. For the data, compliance and AI infrastructure that every asset manager needs but none competes on, the evidence points hard the other way.