Why this decision got harder
The old build vs buy debate ran on stable ground. You knew what a CRM did. You knew what a payment gateway cost. You could reason about it for a year, and the facts will remain the same.
AI broke that stability. The tools change every quarter. Prices fall. Open models catch up to closed ones, then fall behind again.
A model you build today can look old in six months. A vendor you trust can get acquired or shut down. The stakes feel higher, and the ground keeps moving under the decision.
This is why a gut call fails here. You need a repeatable way to think.
First, define what you are actually deciding
People say build vs buy AI and mean five different things. The argument goes in circles because two people are deciding two different questions.
You might be choosing between a vendor API and your own fine-tuned model. You might be picking a full AI platform over internal tooling. You might be deciding whether AI belongs in the product at all. Each version has a different answer.
So name the layer first. There is the model layer, where you use a hosted API or train and host your own. There is the application layer, where you buy a finished AI product or build the app on top of a model. There is the infrastructure layer, where you rent managed serving and vector search, or run it yourself. And there is the workflow layer, where you adopt a packaged agent or assemble your own.
Most teams mix these. You might buy the model and build the app. You might build the model and rent the infrastructure. Decide layer by layer, because one answer for all of it is almost always wrong.
The five questions that settle it
Run any AI choice through five questions. Each one pushes you toward build or buy. Count the leans at the end.
Is this your core differentiator?
Ask what makes your product worth paying for. If the AI capability is that thing, lean build. If it is plumbing, buy.
A fraud team's detection model is core. Their support chatbot is not. Spend your hardest engineering on the part that customers choose you for.
The trap here is ego. Teams call something core because building it sounds fun, not because it matters. So run a clean test. Imagine you handed this exact capability to a rival to run. Would your customers leave? If yes, build it. If they do not notice, buy it and move on.
Do you have the data?
The data does most of the work here. Train a model on thin or generic data, and it stays thin, no matter how clever the code around it is. Buying hands you a vendor's general training. Building lets you use data that only you have.
If you sit on rare, labeled, domain data, a building can win big. That data is the real asset, not the model code. It is the part that a competitor cannot copy.
If your data is thin or generic, the calculation flips. A vendor model already beats what you could train. You will not out-train a frontier lab with a spreadsheet, so do not try.
What is the rush?
Buying ships in days. An API key and a weekend get you a working feature. Building takes months and a team you may not have.
Speed matters most when you are still testing demand. The instinct is to build the proper version from the start. The proper version is a bet on an idea no one has validated yet.
So buy to learn. Build once you know the feature sticks and the volume justifies the effort. Premature building is the most expensive form of guessing.
What does it really cost?
Vendor pricing looks clean, so teams assume buying is the cheap path. The bill tells a different story at scale. A cent per call feels free at ten thousand calls. It hurts at ten million.
The building looks cheap for the opposite reason. The real cost hides off the invoice: the salaries, the GPUs, the on-call rotation, and the retraining.
Run the math at your real expected volume, not today's volume. Say a vendor charges 2000 dollars a month for your current usage. Building the same thing means two engineers, GPUs, and serving, which might run 60000 dollars a month, all in. The vendor wins until your usage grows 30 times over. Most features never get there. Find your crossover point before you assume building saves money.
How much control do you need?
Some teams need full control for real reasons. Strict privacy rules. Air-gapped environments. Regulated data that cannot leave the building.
If that is you, building or self-hosting may be the only path, and the cost is worth the compliance.
If your needs are normal, vendor controls are usually enough. The major providers check most data residency and security boxes now. Building a fortress you do not need is just a slower way to ship the same feature.
Scoring your answers
Now tally the five. Give each a simple lean: build or buy. Three or more leaning buy means buy. Three or more leaning buildings mean a build. A near tie puts you in the middle ground, which is its own answer.
This is not arithmetic. It is a forcing function. The value is in arguing each question out loud with your team and writing down why you landed where you did.
A worked example
Say your team wants an AI support agent for your app. Run it through the five.
Is it your differentiator? No. Customers buy your product, not your help desk. That's a clear buy. Do you have the data? You have years of support tickets, which could make a custom agent sharper. That lean build.
And the rush? Support is drowning right now and needs relief this month. That means buy. What does it cost? Volume is moderate and steady, so a vendor stays cheap at this scale. That is a buy. How much control do you need? Tickets hold some private data, but vendors handle that fine. That means buy.
The tally is four buys, one build. So buy a vendor agent. Then feed it your tickets through retrieval to use the data you own. You bought the hard part and built the edge that fits you.
The middle ground is real and often best
The build-versus-buy frame hides a third option. You can buy the hard part and build the part that fits you.
Use a vendor model. Build your own prompts, retrieval, guardrails, and product logic on top. You get the speed of buying plus a layer that competitors cannot copy.
This pattern wins for most teams right now. The model is a commodity. Your application of it is not. Start here when the answer is unclear: buy the foundation, build the edges, and swap the foundation later if a better one appears.
Keep your options open
The teams that handle this well treat the choice as reversible. They design so they can switch later without a rewrite.
A few habits make that possible. Wrap every vendor call behind your own interface, so swapping models means changing one layer instead of the whole app. Keep your prompts, evals, and data in a store you own. Rent the parts anyone can buy, and hang onto the parts that carry what your team actually knows.
It also pays to put together a small test set early. Then you can throw any model you are weighing at it and see how it actually does. When something new shows up, you size it up in an afternoon instead of a whole quarter. A buy stops being a trap, and a build stops being a prison.
The traps that wreck the decision
The same mistakes show up across teams, and each one wears a reasonable disguise.
The first is the resume-driven build. An engineer wants to train a model for the challenge of it. The company pays for that ambition in delays. The fix is one question: would the user notice the difference?
The second is the lock-in blind spot. Buying feels safe until the vendor doubles its prices in one quarter. So keep your prompts and data easy to move. If the price jumps, you can just pack up and go.
The third is the sunk-cost build. Six months in, the custom model still loses to a cheap API. The team keeps going because it has already spent so much. Set a kill date before you start, while you can still think clearly.
The fourth is the magic tool for buy. A team buys a flashy product that never fits the workflow. A demo on clean data tells you nothing about your mess, so pilot on your own messy data first.
The last is ignoring maintenance. A built model is not done at launch. It drifts. You will be feeding it fresh data, retraining it, and watching it for problems long after the launch party. Plan for that second year, too, or the cost shows up when you least expect it.
When you just need to decide
If you need a default in five minutes, use this rule. Buy first. Ship the vendor version. Watch what users actually do with it.
Build only when one of three things proves true. The cost at your scale clearly beats vendor pricing. The capability becomes your real differentiator. Or a rule forces you to keep the data and model in-house.
Until one of those holds, building is a bet against your own speed. Most teams lose that bet and spend a quarter learning what an API key would have taught them in a day.
How does this shift with team size?
The right answer moves with your stage. A startup and a bank should not decide the same way, even about the same feature.
Early startups should buy almost everything. The job is to find product fit, not to run GPUs. Speed beats control until you have customers to keep.
Scale-ups start to build at the edges. They now have data and volume. The move is to pick one or two AI features that drive revenue and own those, while buying the rest.
Large companies split the call by team. They buy internal tools and generic features and build where regulation, scale, or differentiation demands it. Size does not dictate the answer. It just sets the default you start from.
Make the call and write it down
The worst outcome is no call at all. Teams that debate forever ship nothing while the market moves past them.
So run the five questions. Pick build, buy, or the middle. Then write a short doc with the reasoning and a date to review it. When someone questions the choice in six months, the answer is ready. When the facts change, you know exactly what to revisit.
The smart decision is not the one that stays right forever. It is the one you made on purpose, for clear reasons, with a plan to change your mind.
The underlying pattern
AI moves too fast for permanent choices. The teams that handle it well are not better resourced or more technically advanced. They are more honest about what they are deciding and more willing to revisit it.
Buy to move fast. Build to win where it counts.
