AI: Build, Buy, or Partner?

1. Three Paths, One Decision

Every firm putting AI to work faces the same fork, even if it never names it. You can buy a tool, build your own, or bring in a partner to run it. Three paths, one decision, and the firms that struggle are usually the ones that picked a path by default instead of on purpose.

The classic framing is build versus buy, borrowed from enterprise software. It is missing a leg. With AI, the scarce resource is often not the tool and not the money. It is the owner: the person who turns a capability into a changed workflow. That is why partner belongs alongside build and buy as a real, distinct answer, not an afterthought.

The mistake is treating this as one global choice. It is not. A firm buys for one workflow, builds for another, and partners to run the whole effort, all at once. The right question is never "are we a build firm or a buy firm." It is "for this specific workflow, which path fits," asked one workflow at a time.

This guide takes the three paths one at a time, lays them side by side, and names the hidden costs and the red flags that should move you off a path you were leaning toward. The spend behind each path is priced in how much a fund should spend on AI.

2. Buy: When Off-the-Shelf Is Genuinely Enough

Start here, because for most of what a firm wants, buying is the whole answer. Off-the-shelf, in the AI context, mostly means a capable model set up well: the right licenses, configured workspaces that hold your context, and a team taught to use them.

This is genuinely enough whenever the job is "help a person do this task with our context." Draft this memo our way. Screen this CIM against our box. Answer this DDQ from our library. A well-configured workspace puts the firm's knowledge and standards into a shared tool, and a person does the work faster, the same way every time. Most firms feel the large majority of the available value right here, at a cost measured in dollars per seat, not project budgets.

The case for buy is not that it is the cheap option you settle for. It is that it is frequently the correct option, full stop. Skipping it to build something bespoke is the most common way firms overspend on AI, because they pay for a build to do a job a configured tool already does. The detail of where a configured tool ends and a build begins is the whole of Claude Projects vs custom build.

Buy first, prove the value, and let the places where the tool genuinely hits a wall tell you what, if anything, you need to build. Walk before you pay to run.

3. Build: When the Workflow Is Yours and Recurring

Build when the workflow is yours, recurring, and high-volume. A Custom Build is a fixed-scope engagement that automates one job end to end, and the word that justifies it is recurring.

The economics only work when the same workflow runs on a schedule and the format holds. A board pack rebuilt every quarter for twenty portfolio companies. A screening memo produced for every inbound deal. An LP report assembled the same way each period. The build cost is fixed and the saving repeats, so the math improves every cycle the workflow runs. A build also clears the wall that off-the-shelf tools hit: it can run on its own without waiting for a person to open it, pull live data at scale, and meet a deeper governance bar than a configured workspace.

It is the wrong path for a one-off or a low-volume job. If something happens twice a year, a person with a good tool and a good setup beats any build on cost. The trap is building bespoke for a workflow that is not actually recurring, or that a configured tool already handles well enough. A build earns its place when the inputs come from a system you control and the saving repeats often enough to pay back the fixed cost many times over.

Reach for build deliberately, on the strength of a real number, not because building feels more serious than buying. The most expensive AI mistakes are bespoke systems built for workflows that did not need them.

4. Partner: When You Lack the Owner, Not the Money

Partner is the leg the build-versus-buy framing forgets, and for many firms it is the one that matters most. You partner when the thing you lack is not the tool and not the budget. It is the owner.

The pattern is common and rarely admitted. The firm has the will and the money. What it does not have is a person who is both able to run an AI effort and available to do it, because the respected, interested candidate already carries a full deal load and nobody in the building has run an adoption before. Buying more tools does not fix that, and a build does not either. A build hands you a capability and still assumes someone owns it. What is missing is the owner, and that is exactly what a partner supplies.

An AI Operating Partner is fractional AI leadership: an outside owner who builds the setups, fixes what breaks, runs the adoption, and shows the partners the number, without adding a full-time seat. It is the path when the gap is execution and ownership, not capability or cash. The full version of why ownership is the scarce resource is in the AI strategy and roadmap for investment firms.

Partnering is not a confession that you cannot do AI. It is the fastest way to get a competent owner in the seat today, while your own people learn the job alongside them.

5. The Three Paths Compared

Side by side, the three paths sort cleanly by what each one is actually for. The table is a starting point, not a verdict: the right path is per workflow, not per firm.

The columns that decide it are usually "best when" and "the risk." If your workflow does not match a path's best-when, that is your answer. If you cannot live with a path's risk, or cannot mitigate it, that is your answer too. Price rarely decides this alone, because the sticker price is not the real cost, which is the next section.

6. The Total Cost Each Path Hides

Every path has a sticker price and a real price, and the gap between them is where firms get surprised. Three hidden costs sit behind the headline number.

Maintenance. A build is not done when it ships. The models change, the firm's process drifts, and the workflow breaks if no one tends it. The cost of a build is the build plus the upkeep, and a firm that budgets only the first has bought a thing that decays. Buying hides far less maintenance, which is part of its quiet appeal.

Adoption. This is the cost every path hides and the one that sinks the most projects. A tool bought and a system built both return nothing until people actually change how they work, and that change is real, unglamorous effort that rarely appears in the budget. The most expensive line item in an AI effort is the adoption that nobody costed, which is why why AI rollouts fail at investment firms is about people, not tools.

Lock-in. Buy too deeply into one vendor and you inherit their roadmap and their pricing power. Build entirely in-house and you are locked into your own maintenance burden. Partner with no plan to transfer the knowledge and you are locked into the partner. Each path has a lock-in shape, and the time to see it is before you commit, not after.

Add the hidden costs back in and the cheapest sticker price is often not the cheapest path. A build that looks dear can be the bargain if it removes recurring hours for years. A cheap tool can be the costly choice if nobody adopts it. Cost the whole thing, not the invoice.

7. The Hybrid Most Firms Land On

In practice almost no firm picks one path and stops. The sensible end state is a hybrid, with each path doing the job it is best at.

The common shape looks like this. Buy for the broad base: good licenses and configured workspaces for the everyday work, which is most of it. Build for the few recurring, high-volume workflows where automation clearly pays, the board pack, the screening memo, the periodic report. Partner to own the whole effort while the firm grows its own capability, so adoption actually happens and the build gets maintained. Three paths, each pointed at what it does best.

The partner leg is often what holds the hybrid together in the early going, because it supplies the owner that buying and building both assume you already have. A frequent and healthy arc: partner to run it now, build the handful of workflows that earn it, buy the broad base, and over time let an internal owner absorb the role the partner started. Speed now, ownership later, with the tool, the build, and the owner each sized to the work.

Do not over-engineer the hybrid up front. It assembles itself if you make each decision per workflow, on evidence, and refuse to force one path to do a job it is bad at. The mix you end with should be the residue of good individual choices, not a grand architecture drawn on day one.

8. Red Flags in Each Direction

Each path has a failure signature, a set of warning signs that you are leaning the wrong way. Learn to spot your own.

Buying, when you should not. You are stacking up tools that no one has adopted, paying for seats that sit unopened, and the answer to every gap is another subscription. Buying more is masking the real problem, which is that no one owns turning any of it into changed work. More tools will not fix an ownership gap.

Building, when you should not. You are scoping a custom build before a configured tool has been tried, for a workflow that is not clearly recurring, with no honest number on the hours it saves. The tell is excitement about building for its own sake. If you cannot say how many times a year the workflow runs, you are not ready to build it.

Partnering, when you should not. You are leaning on a partner with no plan to ever bring the capability in-house, treating fractional leadership as permanent outsourcing of something core. A good partner builds toward a handover. The red flag is a relationship designed so the firm never learns to run its own AI, which is dependence dressed as a service.

The pattern under all three is the same: a path chosen to avoid a harder truth. Buying to avoid naming an owner. Building to avoid the modest work of configuring a tool. Partnering to avoid ever owning the capability. Name the truth and the right path gets clearer.

9. How the Decision Shifts With Firm Size

The same three paths weight differently depending on how big the firm is, because size changes both the volume of recurring work and the pool of people who could own it.

Smaller firms. An emerging manager or a lean family office should lean hard toward buy and partner. The recurring volume rarely justifies a build, and there is usually no spare person to own the effort, so good tools set up well plus an outside owner is the efficient path. A build, if it comes at all, comes later and only for the one workflow that has obviously earned it.

Larger firms. A bigger firm has more high-volume recurring workflows, which makes more builds pay off, and a larger pool of people from which a real internal owner can emerge. The weight shifts toward buy as the base, build for the several workflows that clear the recurring bar, and an internal owner who increasingly runs it, with a partner used to accelerate rather than to substitute.

What does not change with size is the order. Buy and prove first, build on evidence, and make sure someone owns it, whether that owner is internal or a partner. Size moves the mix. It does not move the discipline. A bigger budget is a license to build more, not a license to skip the proof.

The right way to read your own size is by the work, not the headcount. Count the genuinely recurring, high-volume workflows and count the people who could plausibly own AI. Those two numbers, more than your AUM, tell you how far to lean toward build and how much you need a partner.

10. Where to Start

Do not decide build, buy, or partner for "AI." Decide it for one workflow at a time. Take the job in front of you and ask the three questions in order: would a configured tool cover it (buy), is it recurring and high-volume enough to justify automation (build), and do we have an owner to run it (or do we need to partner).

Default to buy and prove the value cheaply. Build only where a real number says a recurring workflow has earned it. And be honest about the owner, because the most common hidden gap is not the tool or the money, it is the person who turns either into changed work. If that person does not exist internally, partnering is the fast path, not a fallback.

If you want the decision made for your firm rather than in the abstract, an AI Readiness Sprint maps each priority workflow to the right path. When the answer is build, a Custom Build scopes the recurring job, and the largest of these grow into an AI Operating System rolled out across the firm. When the answer is partner, an AI Operating Partner is the owner who runs it and a Firm AI Rollout takes the proven setup to the whole team.