Build or buy AI for your product: a decision guide
Most AI features come in three shapes: an off-the-shelf tool, a feature built on a foundation model, or a custom model. How to choose between them on value, data, cost over five years and the risk of being wrong.
by Saif Eddine Halila, Head of Cloud Engineering
Three options, not two
"Build or buy" undersells the choice, because there are three shapes an AI capability can take. You can buy a tool: a subscription that does one thing, transcription, support chat, document extraction. You can build a feature on a foundation model: Claude, GPT, Gemini or an open model, with your data and your workflow around it. Or you can train a custom model on your own data. Most of the debate happens between the first two; the third is rarer than the marketing suggests, and this post explains why.
Start from the workflow, not the technology
The most common mistake is choosing a technology and then looking for a place to put it. The better order is to find the workflow where time or money is leaking, measure the leak, and only then ask what would stop it. Fifteen minutes of friction per job, for thirty people doing one job a day, is close to two thousand hours a year, and once you have that number the decision is arithmetic rather than opinion.
The uncomfortable corollary is that many AI projects have no such number. In McKinsey's 2025 State of AI survey, only 39% of organizations report any effect on enterprise profit from AI, most of those put it under 5%, and the 6% that see real value are the ones that redesigned workflows rather than adding a chatbot to them.
When to buy
Buy when the capability is a commodity and your data is not the point. Transcribing calls, extracting fields from invoices, answering generic questions about your public documentation: a subscription does these well, today, for less than an engineer's week. Buy when speed matters more than fit, when the cost of being wrong is low, and when the vendor's roadmap is likely to get better faster than yours would.
Know what you are accepting. Your data goes to the vendor under their terms. The feature looks like everyone else's. Switching later means re-implementing whatever you built around the tool. None of this is disqualifying; it is the price of not building.
When to build on a foundation model
Build when the AI feature is part of what your product is for, when your own data is the thing that makes the answers good, when the workflow is specific to how you operate, or when permissions matter: who may see what, which is exactly where generic tools fail.
Building in 2026 rarely means training anything. It means integrating a model, giving it your data through retrieval, wrapping it in the guardrails your workflow needs, measuring it against real examples, and monitoring it after launch. The model is a component you can swap; the value is in everything around it. For a startup that means building on existing foundation models, and the scarce resource is the engineering to do it properly, not the model.
The cost is engineering time up front and usage-based model costs after, both of which are controllable: the first by scoping to one feature, the second by choosing the model per use case rather than defaulting to the largest one.
When to train a custom model
Almost never, and specifically only when three things are true at once: you have a large, labeled dataset that nobody else has; the task is one foundation models measurably do badly at; and the accuracy gain is worth months of specialist work plus the ongoing cost of keeping a model current. Fraud patterns unique to your platform, a visual inspection task with thousands of labeled examples, a domain where the general models are demonstrably wrong. If you cannot state the accuracy gap in numbers, you do not yet have a case for training.
The five-year view
Compare options over five years, not one. A subscription looks cheap in year one and is still there in year five, per seat, per document, per call, with a price that follows the vendor's growth rather than yours. A built feature costs more in year one and then costs what it uses. The crossover point depends on volume, and it is worth computing before deciding rather than after.
Add the cost of switching to each column. Leaving a tool means rebuilding integrations. Leaving a model, if the feature was built with switching in mind, means changing a configuration and re-running the evaluation set. That asymmetry is the strongest argument for building the features that sit close to your core.
A checklist
- What workflow leaks time or money, and how much per month?
- Is the capability a commodity, or does your data make it better?
- Who is allowed to see what, and can a tool enforce that?
- What does "good enough" look like, in a number you can measure?
- What does each option cost over five years, including usage?
- What does it cost to leave each option?
- What happens if the model or the vendor changes?
Two or more answers pointing at your data, your permissions or your core product: build. Otherwise: buy, and spend the engineering somewhere it changes the product.
How we approach it
When a client brings us an AI idea, the first session at WeaveLines is the checklist above, and its most useful outcome is sometimes "buy this" or "this does not need AI". When the answer is build, we build on foundation models, with an evaluation set from real examples before anything ships, retrieval over the client's own data in their own accounts, and a model chosen per use case so that switching later is a small change rather than a rewrite. The decision is made once, in writing, with the numbers that justified it, so it can be revisited when those numbers change.