The Build Trap

Executive summary

For investment firms, the promise of a custom-built data management platform is seductive: complete control, perfect fit, and perceived lower long-term costs. Our survey of 45 senior data, technology, and operations leaders — who collectively attempted to build their own platforms — reveals a radically different reality.

81% rated their implementation as “Very Challenging” or “Extremely Challenging.” Only 9% reported that their project met original business objectives. The average overall platform success rating was just 3.4 out of 10. 93% of respondents (42 of 45) now explicitly say they would buy a commercial solution rather than build again.

The survey also revealed a consistent pattern: firms underestimated the complexity of building and maintaining an enterprise data platform, while failing to fully appreciate the operational, governance, and cost advantages offered by established vendor solutions.

The in-house path consistently led to significant delays, budget overruns, brittle architectures, and — most critically — a pervasive lack of trust in the very data the platforms were designed to deliver. This report distils their experiences into a clear, evidence-based case for a buy-first strategy in investment data management.

1. The unvarnished reality: key performance metrics

We asked respondents to rate four dimensions of their platform’s performance on a scale of 1 to 10. The results paint a stark picture of underperformance. Trust in data — the foundation of any investment process — scored below 4. Even when the technical infrastructure worked, the output frequently failed to meet the standards of portfolio managers, risk teams, and compliance officers.

We now have a beautifully fast pipe delivering garbage data to the front office.

2. The implementation nightmare

The difficulty of building a modern, enterprise-grade data platform was universally underestimated. When asked to characterize the implementation, the distribution was overwhelming: 81% described it as very or extremely challenging.

This difficulty translated directly into delivery failures. Only three respondents (7%) reported an on-time or near-on-time delivery. Over half (53%) experienced significant delays, often measured in years rather than months.

3. The seven deadly sins of in-house builds

The multi-select survey question on key challenges reveals the most common pitfalls. Scope creep was the single most common killer of in-house initiatives. Technical complexity was a close second.

1. Scope creep without change control

   The single most common killer of in-house initiatives. Requirements kept arriving after sign-off, budgets ran out, and the features operations needed most were descoped.

2. Underestimated technical complexity

   Multi-vendor data matching, corporate actions processing, and intuitive exception-management UIs were repeatedly underestimated. Backend teams delivered systems the business would not use.

3. Exception management the business rejected

   UIs built by backend engineers were universally rejected by operations teams. Breaks continued to be managed in Excel.

4. Data lineage as an afterthought

   Lineage was bolted on late and delivered unusable “spaghetti graphs”, leaving regulatory reporting a manual, nerve-wracking exercise.

5. Governance bolted on, or so rigid users bypassed it

   Security and controls were either retrofitted or implemented so tightly that users worked around the platform.

6. Key-person risk

   Platforms depended on one or two developers whose departure would render the system unmaintainable.

7. Total cost of ownership systematically underestimated

   Business cases emphasised year-one licence savings. Overruns, unbudgeted FTE, and five-year cost neutrality versus vendors were the typical result.

The business kept adding requirements after sign-off with no change control process. We ran out of budget 14 months in and had to descope the multi-eye approval workflows and exception management entirely — which were the two features operations most needed.

We’re back-end engineers; we don’t know how to build a high-performance, intuitive UI for data stewards. What we delivered is a clunky SQL-driven nightmare that the business refuses to use. They still manage breaks in Excel.

4. The outcome: projects that did not deliver

Meeting business objectives

When asked whether the project met its original business objectives, the responses were damning. Only four out of 45 firms (9%) could mostly agree that they achieved what they set out to do. For the other 91%, the platform either missed the mark entirely or left the organization in a state of costly ambivalence.

Documentation quality

The build process also fell short on documentation — a critical asset for audit, maintenance, and business continuity. Respondents were asked to rate the quality of documentation for data pipelines, data quality checks, and data transformations.

Poor documentation was not just a housekeeping issue; it created key-person risk and made regulatory reporting a recurring crisis.

We have no meaningful end-to-end data lineage, making regulatory reporting a manual, nerve-wracking nightmare.

5. The financial reality: total cost of ownership

The initial business case for building typically emphasized lower year-one licensing costs. The survey reveals that this calculation systematically ignored the true total cost of ownership (TCO).

• Budget overruns were common, with one Director of Data Management reporting a final cost of 2.3x the original budget after accounting for staff turnover and rework.
• Ongoing maintenance consumed significant engineering capacity. A Head of Operations Technology noted that ongoing maintenance was consuming 1.5 FTE of engineering time that was not budgeted.
• Key-person risk created a hidden liability. Multiple respondents described their platform as dependent on one or two developers whose departure would render the system unmaintainable.

On a five-year view, a vendor platform would likely have been cost-neutral and delivered more functionality. The build vs. buy decision at our firm was made on first-year costs only.

6. The AI mirage: why coding assistants have not changed the build-vs-buy equation

A natural question in any boardroom debate is whether the advent of generative AI coding tools fundamentally alters the economics of in-house development. If AI can write boilerplate code, generate SQL queries, and accelerate feature delivery, doesn’t the build option become more viable?

The collective experience of our 45 respondents suggests the answer is a decisive no.

The more complex a domain and system, the more AI falls completely short. Our management assumed AI would let junior developers produce enterprise-grade code, but it was the exact opposite. The AI confidently generated plausible-looking changes to matching logic, only for the performance over large volumes of data to be completely degraded. Only a senior engineer with deep buy-side domain knowledge could spot many of the errors. The tools accelerated the production of code, but without expert oversight they accelerated the production of bugs.

This observation cuts to the heart of why AI has not made the in-house build path safer for asset managers, and is unlikely to do so in the foreseeable future.

• Domain complexity is non-linear. A system that works for three vendor feeds will not scale smoothly to fifteen. The edge cases in security mastering, corporate actions, and cross-reference management increase complexity exponentially. AI assistants, trained on general-purpose code, have no model of these esoteric financial data structures and can easily hallucinate plausible but dangerously incorrect logic.
• The bottleneck is understanding, not typing. The survey’s most-cited challenges — scope creep, multi-vendor data matching, exception management design — are problems of requirements definition and domain expertise, not of coding throughput. AI can write a function; it cannot negotiate a shared definition of “data quality” between a portfolio manager and a risk analyst.
• AI is a tool for experts, not a substitute for them. The firms that succeeded in building something useful were those with experienced data architects who used AI carefully and sceptically. For the majority who struggled with resource constraints and junior teams, AI would likely have compounded the problem by increasing the volume of unaudited, brittle code.

The typical management response — “It’s only a matter of time until AI gets much better at complex systems” — may prove true, but the timeline is uncertain and the cost of waiting is real.

Complexity is non-linear. AI might get there eventually, but I’m not betting my firm’s data infrastructure on a five-year hope. By the time the tools are genuinely reliable for this domain, the vendor platforms we could have bought today will have ten more years of embedded expertise we can’t replicate.

The verdict from the survey is consistent: AI assistants do not alter the fundamental build-vs-buy calculus. They make it faster to write code — but the hard work of designing, governing, and maintaining a trusted data platform remains a deeply human, deeply specialized challenge. A vendor platform arrives with decades of that domain reasoning already baked in. An AI-augmented in-house team, by contrast, must still learn it from scratch, one painful edge case at a time.

7. The overwhelming verdict: buy, don’t build

The open-text question “What would you change?” produced a near-unanimous response. The following phrases capture the essence of the 45 answers.

• Buy
• Vendor
• Off-the-shelf
• Commercial platform
• Don’t build
• Configurable
• SaaS
• Managed service

Buy. Don’t build. The buy-side data management space has mature vendors with deep domain expertise.

I would never again underestimate the value of vendor-driven automated lineage and impact analysis. Manual documentation is a lie.

We would engage a managed service or buy a platform with a curated feed library. Our business is lending money, not mapping CSV files.

Asset managers shouldn’t pretend to be enterprise software development firms.

The message is unambiguous: the project these leaders would change is the decision to build in the first place.

8. A better path forward: what vendor platforms deliver

The survey responses implicitly define the seven capabilities that a mature, off-the-shelf data management platform must provide. These are the areas where in-house builds consistently failed, and where a strategic buy decision delivers immediate, compounding value.

I’d buy, not build. The opportunity cost and the technical debt we’ve accrued by maintaining this monster have erased any perceived cost savings.

9. Conclusion

The evidence from 45 investment firms is conclusive: the in-house build of a comprehensive data management platform is a high-risk, low-reward strategy. The overwhelming majority of projects fail to meet their objectives, deliver late, blow their budgets, and produce systems that end users do not trust and will not adopt.

In almost every case, the respondents’ single most valuable outcome was the hard-won realisation that their firm should have bought a commercial solution from the outset.

We now have a clear understanding of what we actually need from a data platform — which we’ll now buy rather than build.

Don’t let your firm become the next cautionary tale. The investment data management market now offers mature, configurable, and deeply domain-aware platforms that have already solved the challenges these 45 teams spent years and millions trying — and failing — to overcome.