Author: Eric Hawkins, CTO
I run engineering at a company that builds AI software for private markets. My team ships products that GPs, LPs, investment banks, and law firms use every day. We also use Anthropic, OpenAI, and Google models internally to write code and automate the boring parts of our own engineering work. So when someone tells me that building software has gotten dramatically cheaper, I’m not arguing.
It has. Retool’s 2026 Build vs. Buy report says 35% of enterprises already replaced at least one SaaS tool with a custom build, and 78% expect to build more this year. That tracks with what I see. A capable engineer with Claude Code or Codex can scaffold in a few days what used to take a quarter. The build side of build vs. buy has genuinely changed.
The part that remains the same is the part nobody puts in the prototype demo: maintaining software is expensive in ways that don’t show up until later.
Where I tell people to build
Let me start where I agree with the build-it-yourself impulse. There are real cases where you should write the code yourself.
Build internal dashboards that stitch together data from your existing systems in ways unique to how your firm works. Build deal-sourcing tools that encode your investment thesis, because your sourcing logic is your edge, and you shouldn’t outsource it. Build custom analytics layers on top of your portfolio data that reflect how your team actually makes decisions.
The common threads are:
- Contained scope,
- Logic that is uniquely yours, and
- A maintenance burden you can actually sustain.
If the code reflects your judgment and the outside world doesn’t shift the requirements on you every quarter, building it makes sense. AI accelerants make this whole category more accessible than it was two years ago. Go.
Where the math gets ugly
The calculus changes the moment your workflow depends on the outside world. There are three signals I look for, and when all three fire, building in-house is almost always a mistake:
- Cross-team operational complexity. If the workflow requires coordination across legal, tax, compliance, finance, and IR, you do not have a software problem. You have a shared data layer, plus role-based access, plus an audit trail problem. A single team’s internal tool rarely survives contact with that reality, and the team that built it doesn’t have the organizational mandate to fix the parts that live in the next department over.
- High cost of error. If the consequence of getting it wrong is a missed regulatory filing, a breached covenant, or a misrepresented investor obligation, the margin for “good enough” disappears. These workflows need traceability and verification, not just outputs. Prototype-grade software rarely has either.
- Institutional knowledge that isn’t written down. Working with a vendor forces you to get your data organized and encode the tribal knowledge that exists across the firm. A good software partner’s implementation process provides the missing structure that causes most in-house builds to fail.
In private markets specifically, there’s an additional dynamic that compounds all three: the regulatory environment doesn’t sit still. The SEC’s amended Form PF has an October 2026 compliance deadline. ILPA’s 2026 reporting template update increases granularity. AIFMD II keeps moving. An internal tool built to this year’s requirements is already behind on next year’s.
All three of the core signals fire across the workflows we solve, and the regulatory concern compounds the first three. Yet I continually see firms tempted to build solutions for investor obligations, credit agreement management, KYC, DDQs, contract negotiation, and entity management. These are textbook bad candidates for in-house builds, not because they’re difficult to prototype, but because they keep being difficult in ways your team can’t predict and won’t fully resource for.
The “upload and prompt” trap
There is a lighter version of build-it-yourself that I see more often, and it’s the one that worries me most: the upload and prompt illusion.
A team drops 10 side letters into Claude or ChatGPT, asks for a summary of investor obligations, and gets a remarkably good answer. The output looks right. The exercise took five minutes. Someone declares the AI question solved.
I’ve been writing code that uses these models for years. I’ll be the first to tell you they’re impressive at this. I’ll also tell you that “looks right” is a verdict you can only render when you already know the right answer. For 10 documents your team has read closely, that works. For 300 they haven’t, it isn’t verification. It’s a vibe.
The structural problems are worse than they appear. Context windows are finite. The session isn’t durable. The analyst who uploaded those side letters on Tuesday has a chat thread. The compliance lead preparing for Wednesday’s audit is starting from scratch. There is no audit trail, no version control, no permanence. A prompt is not a repository.
And the model doesn’t know your firm’s logic. It will extract terms with confidence, but it can’t distinguish your standard position from a one-off exception you should never replicate. When you start automating workflows on top of those extractions, errors propagate silently through the very processes you put in place to remove manual review. That is the worst kind of failure mode: confident, scaled, and invisible until it shows up in something you have to disclose.
What I actually think the play is
I’m not arguing against building. I’m a CTO. I’m arguing that the real question is more complex than build-or-buy makes it sound.
The right framing is: where in our stack does building create a durable advantage, and where does it create a maintenance treadmill we’ll regret in 18 months?
Build the things that encode your judgment. Buy the things where someone else is going to spend the next decade keeping pace with a regulatory environment and a model landscape that will not sit still. Buy the things where the work isn’t just software, where the operational coordination layer is half the value, and a vendor is already running it at scale.
If you’re sitting at a firm right now thinking about which AI bets to make, be honest about the asymmetry. The cost of building dropped. The cost of maintenance didn’t. Don’t confuse the two.
