Build vs Buy AI: Why Building Your Own Tools Is Usually a Trap

Senior partners at mid-market funds keep floating the same idea after their first good AI moment: hire an engineer or two and build the firm’s own AI tooling in-house. It is tempting, it is understandable, and it is almost always the wrong call. Software has never been easier to build, and that is precisely why building your own makes less sense than it used to, not more.

Should you build your own AI tools?

Usually not. Building your own software used to make sense when your use case was genuinely unique, when nothing on the market solved your specific problem. That case still exists occasionally. But when the technology exists and the use case has already been built for, and in finance it almost always has, there is little reason to build it yourself. The vendor, in an AI-native software world, is almost always better positioned to serve you than your own two-person team.

I spent a decade at JP Morgan and watched the bank try to build its own version of nearly everything: its own terminal to rival Bloomberg, its own internal chat to rival Slack, its own chatbot, its own deal-sourcing platform. Every one of them crashed and burned. The bank spent well over $20bn a year on technology and still ended up buying the better third-party product every time. If the firm with the largest tech budget on Wall Street could not build one piece of software compelling enough to keep, that is a strong signal the rest of us cannot either.

Why does building feel so tempting right now?

Because the first result feels like magic, and magic clouds judgment. You write a prompt and a working dashboard appears. You ask a question of your data that you could not have asked a year ago. The cost of trying something has collapsed, so you try more things, and each small win feeds the sense that you could build anything.

Then comes the come-down. The dashboard that worked beautifully for one use case falls apart on the second. The agents you wired together start hallucinating in production. You look back and realise you built a tower of agents to do something a single, well-configured search alert would have handled more reliably.

The high makes you feel you can build anything. It does not give you the judgment to know what’s worth building.

What does the high hide from you?

It hides how much the software market has actually changed. Off-the-shelf enterprise software was genuinely bad for the better part of twenty years, clunky, bloated, built for procurement checklists rather than users. That is why building your own never sounded quite as crazy as it should have. That world changed faster than most people’s mental model of it did.

Software today, particularly AI-native software, is getting genuinely good, because AI now acts as a translation layer between you and the underlying system. You do not need to understand how the software works to get value from it. The best of it also solves a deeper problem than any single dashboard: making a firm’s data usable in the first place, and embedding real workflows on top of it rather than bolting AI onto the outside of an existing process.

That is the whole premise of a proper data layer for a deal firm. Your data lives scattered across email, the CRM, the data room, banker calls, portfolio reports, spreadsheets, and shared-drive folders nobody has opened since a previous fund cycle, and none of it talks to any of the rest. A model cannot reason over what it cannot see. Solving that is a year of serious architectural work, not a weekend sprint with a couple of API keys. Even the frontier AI labs are spending billions acquiring AI-services firms right now, because the binding constraint on value has stopped being model capability. It is getting the model into the right place, with the right data, doing the right job. The structured data layer is the actual hard problem, not the problem most partners think they are solving when they talk about “building our own AI tools.”

Are you even building the right thing?

Probably not, and this is the deeper issue underneath all the practical ones. The teams building the best AI software have spent years thinking hard about what software even is, now that a language model can reason, data can be unified across every source, and workflows can run themselves rather than waiting for a human to click through five screens.

A senior partner, by contrast, is immersed in deal flow, LP relationships, and portfolio governance, not in that question, and is pattern-matching against a decade-old frame of what software looks like. The future is not twenty separate SaaS products stitched together with brittle integrations that break every time one of them ships an update. It is one connected layer of structured information that a model reasons over and presents to the right person at the right time, with humans directing and approving rather than clicking through menus. “We need a CRM, so let’s build a CRM” is still stuck in the old frame, software as a place for humans to click. AI is an amplifier, and pointed at a half-baked idea of what your firm’s software should do, it just takes you further in the wrong direction, faster.

Software development itself has been amplified too, which cuts against you rather than for you. The specialist teams iterating daily against feedback from thousands of users are pulling further ahead every quarter, not converging with the rest of the field. Two engineers working evenings will not catch that gap.

What does building actually cost, even if you knew exactly what to build?

More than the build itself, on every axis that matters.

Talent is the first wall. Every genuinely good agentic engineer, someone who can build a system that holds up under real production load rather than a demo, is being paid seven figures by a frontier lab right now. There is no shortage of developers generally, but there is a brutal shortage of the ones who can build agentic systems that do not fall over the first time something unexpected happens.

Distraction is the second. Your job is buying companies, selling companies, or raising capital from LPs. Building an AI platform properly, with model selection, retrieval design, evaluation harnesses, security review, and compliance sign-off, is its own full-time job, and doing it half-time on top of your actual job means it gets done badly, slowly, or both.

The problem is usually already solved. Domain-specific platforms built by people who came from the industry, working alongside people who came from the labs, have head starts measured in years, not months. You are not racing them from a standing start. You are racing them from several laps behind.

Cost and maintenance never stop, and the initial build is the cheap part of the whole exercise. After that comes infrastructure, model upgrades every few months, retrieval re-tuning, security patches, and compliance reviews that never end. When the one or two engineers who built the system move on, as they eventually will, the institutional knowledge of how it actually works leaves with them.

Security is the risk most firms underprice entirely. The fastest way to leak sensitive deal documents is to build a custom agentic system in-house without people who genuinely know how to secure one. Hand-rolled agentic infrastructure is one of the largest underpriced risks in deal technology today.

What did the biggest firms with the biggest budgets actually do?

They bought. The largest, best-resourced firms in the industry, the ones with technology budgets that dwarf a mid-market fund’s entire operating budget, felt exactly the same high after their first good AI result and had the resources to act on it and build almost anything they wanted. They concluded, having genuinely weighed it, that the right answer was to partner with specialist AI providers and deploy across their portfolios rather than build in-house.

That is not a small data point. If firms with effectively unlimited resources could not justify the in-house build, a firm with a fraction of that budget almost certainly cannot either. I run a vendor in this space, so I am aware I talk my own book here, and you should weigh that. But the argument rests on the same reasoning the largest firms in the industry already applied, with far more scrutiny and far less at stake in the outcome.

Where does this leave you?

The firms building a proper structured data layer now are laying a foundation that everything else gets built on top of. The firms still debating whether to build their own tooling will, in a year or two, end up buying it anyway, just later and from whoever got there first. See how firms use it if you want to see what that looks like in practice rather than in theory, or talk to us if you want to work through your own specific case.

The real question was never really about engineering talent or budget. It is whether you can stay disciplined when the high from your first good result is telling you to keep building.