A founder asked me last month whether they should train their own model. They had 12,000 historical customer interactions, a small engineering team, and a deadline of 90 days. The honest answer was no, and the reason had nothing to do with whether the model would be good. It had everything to do with what they would be giving up to find out.
This is the build vs buy decision, and almost every founder gets it wrong in one of two directions. They either go too far toward buy, treating their AI strategy as a thin wrapper over a public API, or too far toward build, sinking budget into custom training that produces no measurable advantage over a 200-token prompt. The right answer almost always sits in the middle. Here is how to find it.
Three layers, three decisions
Every AI feature has three layers. The model itself, the data and retrieval that feed the model, and the workflow surrounding the model. You make a build vs buy decision at each layer, and they are independent. You can buy the model, build the retrieval, and buy the workflow tooling. Or build all three. Or buy all three and ship in two weeks.
Layer 1. The model
For 90 percent of startups, the right answer is buy. Anthropic, OpenAI, Google, and the open-weights ecosystem have made foundation models cheap, capable, and constantly improving. If you train your own, you are in a footrace against a thousand-engineer team that ships a better model every quarter. You will lose, and you will lose expensively.
The exceptions are narrow. You handle data that legally cannot leave your infrastructure. You operate at a scale where the per-token cost of public APIs becomes a meaningful line item. You have a domain so specialized that public models routinely fail and you have the labeled data to prove it. None of these apply to most companies. If they do not apply to you, buy the model and stop thinking about it.
Layer 2. Data and retrieval
This is where most of the real value is, and it is where founders chronically underinvest. The model is a commodity. Your data is not. Your customer interactions, your proprietary documents, your domain-specific knowledge graphs, your labeled feedback loops. These are the moat.
The build vs buy decision here is about retrieval infrastructure. Vector databases, chunking strategies, hybrid search, reranking, eval harnesses. A founder running a 12-person team should buy a managed vector database, hire one good engineer to design the retrieval pipeline, and spend the saved time on labeling and evaluation. A founder running a 200-person team with a dedicated platform group can build their own retrieval stack and probably should.
Layer 3. Workflow
This is the surface your customer touches. The dashboard, the in-app chat, the email integration, the approval flow, the audit trail. Workflow is where the product lives, and it is also where the moat shows up to the user. Workflow should almost always be built. Off-the-shelf AI products give you the same workflow as every other startup using the same tool. You will not differentiate that way.
The decision tree
Run through these four questions in order. Stop at the first yes.
- Are you handling data that legally cannot leave your infrastructure? Defense, certain healthcare, certain financial. If yes, you are looking at on-prem or private-cloud deployment with open-weights models. Build the inference layer, buy the workflow tooling.
- Is your monthly token spend on a public API projected above 50,000 euros within 12 months? If yes, the economics start to favor a hybrid approach. Use frontier models for the hardest 10 percent of requests, route the easy 90 percent to a smaller fine-tuned or open-weights model. The savings can fund the engineering team that maintains it.
- Do you have a measurable, repeatable failure mode that prompting cannot fix? If yes, fine-tuning is on the table. Note the words measurable and repeatable. Without an eval harness, you cannot tell whether the fine-tune helped.
- None of the above? Buy the model. Build the retrieval and the workflow. Spend the saved engineering hours on the eval harness and on getting closer to your customer.
The trap that catches sophisticated founders
The trap is not the obvious one of building too much. It is the subtle one of buying too much. A founder hears that AI is a commodity, decides to use a no-code AI workflow tool, and ships a feature in two weeks. The feature works. The customer is happy.
Six months later, a competitor with the same no-code tool ships the same feature. The customer asks why they should pay more. The founder has no answer, because there is nothing about the feature that is theirs. The data lives in a third-party tool. The workflow is templated. The prompts are public. The moat is zero.
The lesson is that buying the model is fine. Buying the workflow and the data is the slow death. Build the layers your customer feels.
What this looks like in real projects
When we built the AI proposal engine for a construction operator, we bought the model and built everything else. The retrieval pipeline indexed 18 years of past proposals, supplier price sheets, and project specs. The workflow lived inside the operator's existing CRM. The eval harness ran on 200 labeled past bids. The result was 800,000 euros in proposals generated for one client and a five-to-tenfold compression of senior estimator time.
None of that came from the model. The model is the same one a competitor could call. The advantage came from the retrieval and the workflow, both of which we built and none of which a competitor can replicate without the customer relationship and the historical data.
The honest summary
Buy the model. Build the moat. Buy the boring infra you do not differentiate on. Build the part your customer pays for. And before any of that, build an eval harness so you can tell whether what you bought and what you built actually works.
If you are looking at a build vs buy decision and you want a second opinion before you commit budget, write to me. I respond within 48 hours.