Build vs Buy for AI Features: A Decision Framework

The build or buy question used to be about writing your own software or licensing someone else's. With AI it has a third layer, because almost nobody builds the model itself. You are choosing how much of the stack around the model you own. Below is the framework I use with clients, a scoring sheet you can fill in for your own feature, and three worked examples.

What does the data say about build vs buy for AI?

Recent survey data leans towards buying, especially for a first project. Menlo Ventures' 2025 enterprise survey found that 76% of AI solutions were purchased rather than built in 2025, up from 53% in 2024, because off-the-shelf tools were reaching production faster and showing value sooner. The same report notes continued strong investment in internal builds.

The MIT NANDA "GenAI Divide" research points the same way. In press coverage of the study, purchasing AI tools from specialised vendors and building partnerships succeeded about 67% of the time, while internal builds succeeded about one-third as often. The study drew on 150 leader interviews, a survey of 350 employees and 300 public deployments.

Two cautions before you take that as "always buy". First, both are about large organisations, where internal builds often mean a central team far from the people doing the work. Second, a high success rate for bought tools partly reflects that teams buy for common, well-understood jobs. The data tells you to buy the commodity parts. It does not tell you to buy the part your customers pay you for.

The five factors that decide build vs buy

Five factors decide nearly every AI build or buy choice: cost over time, control, data, speed and lock-in. Score each one for your feature before anyone talks to a vendor or writes code.

Add a sixth question on top: is this feature part of why customers choose you? If yes, it leans strongly towards build, because a vendor will sell the same feature to your competitors.

How to score your AI feature

Score each factor from 1 to 5, where 1 means strongly buy and 5 means strongly build, then add them up.

• 5 to 11: buy. Pick the vendor with the cleanest data export and the business-tier data terms you need.
• 12 to 18: hybrid. Buy the model and any commodity pieces, build the workflow, prompts and integrations yourself.
• 19 to 25: build, on top of a model API. You still do not train a model; you own everything around it.

Then apply the differentiation question as a tiebreaker. A score of 17 on a feature that customers choose you for should be treated as a build.

The scoring is deliberately crude. Its value is that it forces the conversation into specifics. "We should build it" becomes "we scored data at 5 because client contracts forbid sending records to a third-party SaaS", which is something a team can check.

Write the answers down before you start. My AI feature brief template has room for exactly this.

Three worked examples

These are made-up companies, to show how the scoring plays out.

A support inbox for a 20-person online shop: buy. Volume is modest, the help desk vendor already has an AI reply feature, data is order details the vendor already holds, and the shop needs it this quarter. Cost 2, control 2, data 1, speed 1, lock-in 2: total 8. Buy, and check the export.

Document extraction for an insurance broker: hybrid. Off-the-shelf tools handle common forms, but this broker's schedules come in many layouts and feed an in-house system. Cost 3, control 4, data 4, speed 2, lock-in 3: total 16. Use a model API for extraction and build the validation rules, review screen and integration in-house.

An AI planning assistant inside a SaaS product: build. It is the feature in the sales demo, it uses the customer's data from inside the product, and the team iterates on it weekly. Cost 4, control 5, data 4, speed 3, lock-in 5: total 21, plus it differentiates. Build on a model API, with evaluation tests from day one.

What does hybrid look like in practice?

Hybrid means you rent the intelligence and own the workflow. Typically:

• Bought: the language model via API, plus commodity services such as speech-to-text, vector search or an automation platform.
• Built: the prompts, the business rules, the data connections, the review steps, the test set and the user interface.

This keeps switching costs low. If a better model arrives, you change one integration and rerun your tests. If you outgrow an automation platform, the logic is documented and portable. My comparison of n8n, Zapier and Make covers which automation tools make that easiest.

The lock-in to watch is not the model. It is your workflow and history living inside a vendor's product with no export. Before you buy, ask the vendor to show you a full data export, and make sure accounts sit in your company's name; the same ownership checks apply as in who owns your automations.

Common mistakes in build vs buy decisions

The most common mistakes are counting only the first-month cost and forgetting who will own the feature next year.

• Comparing licence price with build price only. Include running costs on both sides: model usage, hosting, monitoring and someone's time to maintain it.
• Building because the team wants to. Interesting is not a reason. Run the score.
• Buying a tool for a differentiator. If a vendor can sell it to you, it can sell it to your competitor.
• No owner after launch. A built feature with nobody responsible decays. A bought one with nobody responsible gets misconfigured.
• Ignoring data terms. Check what the vendor does with your data, and whether your AI usage policy allows it.

Work with me

I help teams make the build or buy call, then build the parts worth owning on top of model APIs. See AI integration and SaaS MVP development, browse my work, and book a scoping call to score your feature together.