The AI tooling babysitter tax
Tools that need constant supervision do not save an analyst any time. What has to be true before a team stops checking every output.
A four-person firm with a sharp analyst and an LLM can absolutely build something that works. The real question is what it costs to turn that weekend demo into something your associates still trust six months later, and what you give up in the meantime to make that happen. Every hour your most capable person spends debugging a data pipeline is an hour they are not spending on a thesis, a relationship, or a deal.
What does it actually cost to build in-house?
A realistic build runs two to three engineers for twelve to eighteen months, the data-provider contracts you needed anyway, LLM usage bills that grow with every query, and a maintenance load that never ends. Loaded with benefits, payroll taxes, equipment, and overhead, $180,000 to $200,000 per person per year is conservative — two or three of those people is $400,000 to $600,000 a year before a line of code touches a deal. And that buys a first version, not parity with a tool a vendor has been refining for years.
Why do in-house tools fall apart a year after launch?
Launching the tool is the start of the cost, not the end of it. Roughly 65% of a software system's total cost lands after deployment, and for AI tools the running cost passes the original build cost within eighteen to twenty-four months. Three kinds of ownership never get staffed for: IT (APIs change, models get deprecated, pipelines break at 2am before an IC meeting), product (someone has to own what the thing does next, or it drifts toward underfunded and underused), and security (the tool routes target financials and your relationship graph through third-party endpoints, and someone owns what's allowed to leave your walls).
Does it actually create an edge?
For most lower middle market firms, no. Your edge is your thesis, your judgment, and your relationships — not the data pipeline every firm in your category needs and none of them differentiate on. Understanding the sourcing problem better than any vendor is real and necessary, but it is not sufficient. Building something that stays competitive is a separate craft from understanding the problem it solves.
When does building in-house make sense?
When sourcing infrastructure is genuinely core intellectual property and you have a real engineering organization to own it for years, not ship a version one and move on. Even then, the smartest version is usually a hybrid: buy the commodity infrastructure every firm needs, and build only the thin proprietary layer that's actually yours.
How to decide
- Is this capability your competitive edge, or table stakes every firm in your category needs?
- Do you have an engineer who can own it for years, not just build a version one?
- Who owns it on the product side when the market moves and the tool needs to keep up?
- Who owns it on the security side when it's routing confidential deal data through outside endpoints?
- If two or more of those answers are shaky, you're describing a buy, not a build.
Build versus buy is a focus decision, not a capability one. For most lean lower middle market firms, the edge was never the tool. It was the judgment and the relationships, and those are the things worth protecting your team's time to do.
Prefer to see it than read about it?
Send a sector and we build the universe before the call.