Build vs buy: What building AI in-house actually costs
By Kumar Ujjwal, Founder and CEO, DwellFi
"Give us a quarter. We'll build the reconciliation engine ourselves."
Every fund-ops leader has sat across the table from an engineer who said some version of that sentence, with total confidence, in a budget meeting. The engineer usually isn't wrong about the code. A talented team can absolutely stand up a working prototype in a quarter. What they're not accounting for is the 18 months after that: the edge cases nobody scoped, the SOC II audit nobody budgeted, the one senior engineer who leaves in month nine and takes the undocumented parts of the system with him.
That gap, between "we can build a version of this" and "we can run this in production, forever, under regulatory scrutiny," is where fund-ops build projects actually die. Not in the demo. In year two.
Why this decision matters more in fund ops specifically
Three things have changed in the last two years that make this call higher-stakes than it used to be.
Specialized platforms now exist. Five years ago, if you wanted AI-driven reconciliation or NAV automation, there was nothing to buy. You built, because building was the only option. That's no longer true. Deterministic, purpose-built platforms for fund operations exist today and can be running inside your environment in weeks.
AI engineering talent is expensive, and it's not your business. A senior AI engineer costs well into six figures loaded, and every hour they spend building an internal reconciliation agent is an hour not spent on whatever your firm actually gets paid for. Fund administration isn't an AI engineering business. It shouldn't start acting like one to solve a middle-office problem.
The gap compounds. A firm that adopts a working AI platform this quarter starts closing NAV faster this quarter. A firm that spends a year building starts a year behind, on a curve that doesn't wait.
The real framework: define your core, then price the rest honestly
Skip the flowchart. Two questions do most of the work.
What actually makes you valuable to a client? For a fund administrator, that's rarely the plumbing. It's accuracy, audit-readiness, and how fast you close. Reconciliation, NAV calculation, capital call processing: none of that is where clients perceive differentiation. It's operational infrastructure. Infrastructure is a strong buy candidate almost by default.
What does building actually cost, all the way down? This is where most build decisions go wrong, because teams price the visible 20% and never price the rest.
The iceberg: what's under the number your engineer gave you
The quote you get in the budget meeting is almost always the tip. Below the waterline sits the engineering team you'll need to hire and retain, LLM licensing and API spend that scales with usage, infrastructure, and the QA and compliance work that doesn't show up until an auditor asks for it.
Run the full stack, and a build project that looked like a few hundred thousand dollars in year one lands closer to $1.5–2.5M. Compounded over three years against a buy-and-integrate path, the gap runs into the millions, not because buying is cheap, but because building was never actually the number in the first slide.
Red flags that mean you should buy, not build
A few signals reliably predict a build project is heading for trouble, months before it shows up in a status report.
- Timeline slippage. In-house AI builds in regulated finance routinely run six to twelve months past the original estimate. It's rarely one big miss. It's compliance sign-off, then an edge case, then a re-architecture, each one reasonable on its own.
- Scope creep dressed as diligence. "We'll just handle this one more edge case" is how a six-month project becomes a fourteen-month one. Governance requirements that demand near-100% accuracy extend QA cycles in ways that are hard to estimate up front.
- Key-person dependency. The engineer who understands the reconciliation logic best is also the one a competitor can hire away. When they leave, the knowledge leaves with them, and rebuilding institutional context costs another quarter.
- Vendor lock-in you didn't notice you took on. Building on top of a foundation model API means your uptime and your roadmap are tied to someone else's release calendar and someone else's infrastructure incidents. Anthropic's own Claude Code had a source-code exposure in March 2026, a packaging mistake that made headlines across the industry. That's the risk you inherit by proxy when your custom build sits on a single vendor's API with no fallback.
When building is actually the right call
None of this means build is always wrong. It's the right call when the thing you're building is the actual reason a client picks you: a proprietary scoring model, a data asset no one else has, a workflow so specific to your book of business that no vendor has built it and none will. If losing exclusive access to it would damage your competitive position, build it. If it's plumbing everyone in the industry needs the same version of, it's not that.
What buying actually gets you
This is the part budget meetings tend to skip past, because "buy a platform" sounds like a smaller decision than "build a team." In practice it's the opposite: a platform like DwellFi already covers most of the ground a build project would spend a year reaching. Roughly 80% of the workflow, prebuilt agents for NAV, reconciliation, expense processing, and fee calculation, already exists rather than needing to be scoped from zero. It runs deterministically, which is what gets QA cycles down to something a compliance team can actually sign off on quickly, and it deploys inside your own environment from day one rather than asking you to trust someone else's cloud with your data. The engineers doing the integration work sit embedded with your team instead of routing every question through a support ticket. And the path in starts with one workflow, proven, before it expands, which is the same discipline a well-run build project would use if it had the year to spare.
Back to that budget meeting
The engineer who says "give us a quarter" isn't lying. They can probably build a working prototype in a quarter. The question a fund-ops leader actually needs answered isn't whether the team is capable. It's whether reconciliation logic is the hill your firm wants to spend the next three years maintaining, when the alternative is live in weeks and never shows up as a line item in next year's engineering headcount plan.
Buy what's already been solved. Build what makes you who you are.
FAQ
Should we build our own AI for fund operations?
Usually no. Building means standing up AI engineering, security, and evaluation capability that isn't your core business, for a worse result than buying.
Isn't building the more ambitious, forward-looking choice?
No. It looks ambitious on a slide. In practice it's a few million dollars and eighteen months spent on a capability you'll never use again.
What is the lowest-risk way to start?
Buy a platform built for the problem, run it in your own environment, and prove it on one high-volume workflow first.
How long does implementation typically take?
With a purpose-built platform like Dwellfi, you can have your first workflow live in 30 days and full production deployment in 8-12 weeks. Compare that to 12-18 months for building in-house.
What about data security and compliance?
A platform designed for fund operations runs in your own environment from day one, so security and residency requirements are satisfied immediately. Building in-house requires 6-9 months just to establish a compliance posture.
Turn this into evidence, not theory
Your board wants proof before committing. We'll show you exactly how to measure impact on day one: accounts per person, not minutes saved.
Book a demo. 15 minutes. Your workflows. Real numbers.
Want the full model first? The full build vs buy cost model, the math behind every chart in this post, is in the white paper.