Buy when a mature product solves a common problem, build when the workflow is proprietary and strategic, use no-code workflows for fast experiments, and wait when the market is moving quickly and stakes are low. Weigh cost, data security, vendor stability and your team's technical capacity.
This question lands on the platform or ops lead's desk more than anyone else's. A partner sees a demo, or hears that another firm "built their own AI," and asks whether you should too. And you're the one who has to scope it, run it and keep it alive after the excitement fades.
Honestly, I think most firms should buy more and build less than they expect. I don't meet a lot of people who are happy about having built everything in-house a few months later, as they're maintaining it. My short version: buy the plumbing, build on top. "Wait" fits a narrow set of cases. But waiting on everything is how firms fall behind, because AI is cheap for what it does. And no-code is the best way to find out what you actually need before you commit.
Buy the plumbing, build on top
The plumbing is the data layer: collecting portfolio data, extracting it, keeping one clean record per company, and tracing every number to its source. Every fund needs it, and it's where the hard, boring edge cases live. The layer on top is where your firm is actually different: how partners prep for a board meeting, how you score a deal, the Claude skills your team writes for its own questions.
In-house plumbing goes stale. Maintenance never went away, and a vibe-coded tool can be silently wrong for months. I've heard about FX conversions that nobody noticed were off until someone checked by hand. Once a partner catches one wrong number, they stop trusting the whole tool.
There's one argument I don't buy: "we need internal software so we can tell LPs we have a differentiated process." LPs care about outcomes. What sets you apart is what your team does with good data, not who wrote the pipeline.
The four options, side by side
| Option | Use it when | Typical example | Main risk |
|---|---|---|---|
| Buy | The problem is common to most funds and a product already handles the edge cases | Portfolio metric collection, CRM, meeting notes | Vendor lock-in, data access |
| Build | The workflow is unique to your firm and part of your edge | A sourcing model built on your own thesis and network data | Maintenance falls on one person |
| No-code | You want to test a workflow in days, not months | Zapier flow that summarizes founder emails into Slack | Breaks silently, nobody owns it |
| Wait | The category changes every quarter and getting it wrong costs little | Fully autonomous agents that email LPs | Falling behind if you wait forever |
Most platform teams end up with all four at once, across different workflows. That's normal. The mistake is picking one stance ("we're a build shop") and applying it to everything.
A scoring rubric you can use in one meeting
When a request comes in, score it on five questions. Give each a 1, 2 or 3.
- How common is this problem across funds? 3 means every fund has it. 1 means only you do.
- How strategic is it to your edge? 3 means it's core to how you win deals or support founders. 1 means it's admin.
- How sensitive is the data? 3 means LP data, cap tables or unreleased financials. 1 means public information.
- How fast is the category changing? 3 means new products every month. 1 means it's settled.
- How much technical capacity do you have? 3 means an engineer on staff with time. 1 means nobody.
Then read the pattern:
- High on question 1, low on question 2: buy.
- High on questions 2 and 5: build is on the table.
- High on question 4, low stakes: wait, or run a no-code test.
- High on question 3: whatever you choose, security review comes first.
It's blunt on purpose. It turns "should we build an AI thing?" into a ten-minute conversation with a clear default.
What building really costs
Building looks cheap at the start. Someone capable with Claude or ChatGPT and an API key can have a working prototype in a weekend. But the prototype isn't the cost. Everything after it is:
- Maintenance. Model APIs change, vendors deprecate endpoints, and the data you feed the tool changes shape.
- The last 30%. In my experience a prototype gets you 60–70% of the way, and the rest takes months. The prototype handles the clean example. Production has to handle the founder who sends metrics as a phone photo of a whiteboard.
- The key person problem. If the person who built it leaves, the tool usually dies with them. With a two-person platform team, that's a real risk.
- Security. Internal tools rarely get the access controls and audit logs a vendor has to offer.
Try this before you build. Write down who's on call when it breaks, and how many hours a month you expect to spend on it after launch. If you can't name the person, buy.
Worked example: one fund, four decisions
Say your fund has 30 portfolio companies and a two-person platform team. Partners have asked for four things this year.
Quarterly metric collection from founders. Every fund has this problem, it isn't your edge, and the edge cases never end. Buy. Tools like Cura send metric requests from your own inbox, pre-fill what they already have, follow up automatically and extract numbers from replies and documents. You don't want to maintain that yourself. Cura also works inside Claude through its MCP server, so your team can build its own workflows on top without collecting the data twice. More on that in automatic metrics.
Scoring inbound deals against the fund's thesis. This one is strategic and specific to your firm. If you have someone technical, a light internal build on top of your CRM data can make sense. If you don't, start with no-code and a scoring sheet, and build only once the rubric has held steady for a quarter.
Turning partner meeting notes into CRM updates. Common problem, low stakes, and you want to see if partners will actually use it. Build a no-code flow in an afternoon and run it for a month.
An AI agent that answers LP questions by email. High stakes, a fast-moving category, and LP trust is hard to win back. Wait, and look again in six months.
None of these calls are permanent. The no-code flow may graduate to a bought product, and the "wait" may turn into a buy next year.
No-code is for learning
No-code tools like Zapier or Make, plus a general AI assistant, are the best way to learn what a workflow actually needs before you buy or build. Treat each one as an experiment with an end date.
A crawl → walk → run approach works well:
- Crawl: Run the workflow by hand with an AI assistant for two weeks. Note where it helps and where it fails.
- Walk: Automate the steps that worked with a no-code flow. Name an owner and add an alert that pings someone when it fails.
- Run: If people start to depend on the flow, decide whether to buy a product or build it properly.
The failure mode here is the tenth Zapier flow that nobody remembers setting up (almost every firm I talk to has one). Keep a simple list of every automation, its owner and what it touches.
For the wider picture of what funds are running today, see the VC software stack in 2026 and the earlier post on what has worked in AI fund operations.
How do VC firms evaluate AI vendors?
Run a short pilot on your own data, not the vendor's demo dataset. Check where your data goes, whether it trains anyone's models, who can access it, how the product handles errors, and whether you can export everything if you leave.
Here's the checklist I'd use:
- Data handling. Where is data stored? Is it used to train models? Can you get that in writing?
- Access controls. Can you limit which team members see which companies or LP records?
- Error behavior. When the AI is unsure, does the product say so, or does it guess? Ask to see a wrong answer.
- Ownership. Can you get all your data out in a usable format, or pipe it into your own warehouse? You should own your data, not rent access to it.
- Provenance. Does every number link back to the document or email it came from? If you can't check a figure, you can't trust it.
- Integration. Does it have an API, and does it connect to the tools you already use?
- Vendor stability. Who else uses it, how long has the company been around, and what happens to your data if they shut down?
- Scope. Be wary of vendors who promise to do everything, or who sell offshore humans as AI. I'd rather go deep than wide, and I'd want the same from a vendor.
Two weeks on your real data will tell you more than any number of demos.
When does building internal AI tools make sense?
Build when the workflow encodes something only your firm does, such as a proprietary sourcing thesis, and you have a person who will own and maintain it. If nobody on staff can fix the tool when it breaks, buy instead.
The good candidates I've seen share three traits. The workflow is close to how the fund wins, the data is mostly your own, and no product on the market fits without heavy changes. Even then, I'd build on top of a bought data layer, not from scratch. Many vendors offer an API or an MCP server. A thin internal layer over a product someone else maintains is much easier to keep alive than a tool you built from the ground up.