Decide What AI to Build and What to Buy Before You Waste

A founder gets excited about AI and makes one of two mistakes. The first is building everything from scratch, standing up custom transcription, custom embeddings, custom model serving, and burning a quarter on infrastructure that a hundred companies already sell as a commodity. The second is the opposite: assembling the whole product out of third-party APIs and calling it an AI company, with no part of the stack that a competitor could not replicate in a weekend. Both mistakes spend your scarcest resource, engineering time, on the wrong thing. The first wastes it on plumbing nobody will pay extra for. The second leaves you with nothing defensible to show for it.

The decision of what to build and what to buy is, at its core, a question about where your moat lives. Get that question answered honestly and the rest of the build-versus-buy calls fall out almost automatically. Get it wrong and you can spend a quarter, or half a million dollars, producing something that is either undifferentiated or unfinished.

The principle: build where the advantage is, buy everything else

Strip the AI hype away and the rule is the same one that has always governed build-versus-buy. Build where you have a genuine, durable advantage. Buy where you do not. The only thing AI changes is which components are commodity and which are differentiation, and that line has moved fast.

Today, a large and growing category of AI capability is infrastructure, not differentiation. Speech-to-text, embedding generation, vector database hosting, general-purpose model inference, these are commodities now, sold by mature vendors, and the engineering cost of building them yourself would not pay back for years. The same logic governs whether to fine-tune or just prompt: reach for the heavy custom tool last, not first. It is the same disciplined trade-off as the broader build-versus-buy software decision, where buying off the shelf wins unless the thing is genuinely your moat. There is no moat in a transcription pipeline you built when three providers sell a better one per minute. Building commodity AI infrastructure is the modern equivalent of building your own database server: technically possible, almost always a mistake. The market has voted on this clearly, with the majority of AI use cases now purchased rather than built internally, a sharp shift from just a year or two earlier.

So the default is buy. You rent the frontier model APIs as commodity infrastructure, and you spend your build budget only where something proprietary makes a custom piece genuinely better than anything you could buy.

What "the value lives in the last 30 percent" actually means

The most common and most important scenario for a founder is this: an off-the-shelf solution gets you 70 percent of the way there, but the last 30 percent is where the actual value lives. That last stretch is almost always where you build, and recognizing it is the whole skill.

The 70 percent is the generic capability, the model can summarize, classify, generate, converse. The 30 percent is what makes it work for your specific customers and your specific data: the domain-specific behavior, the integration with your proprietary information, the workflow that matches how your users actually operate, the edge cases that a general tool will never handle because it does not know your business. That 30 percent is where proprietary data, domain expertise, and specific customer requirements create something off-the-shelf cannot match, and it is exactly the part worth your engineers' time. Buy the 70 percent that is commodity. Build the 30 percent that is yours.

The two cases where building is clearly right

Two situations make the build decision unambiguous, and they share a quality: the AI is not assisting your product, it is the product, or it is fed by data nobody else has.

The first is when the AI itself is the product. If your differentiation is a model or a system that does something materially better than the general tools, and that capability is the reason customers choose you, then building it is not optional, it is the company. You cannot rent your core.

The second is when your data is the moat. If you have proprietary data, your own customers' behavior, a domain corpus nobody else can assemble, the accumulated labeled examples from years of operation, then a model trained or tuned on that data does something no off-the-shelf tool can, precisely because the tool does not have your data. Here, building is how you turn an asset you already own into a product advantage. This is also where a small, focused model trained on your own data can outperform a giant general API on your specific task while costing far less to run, which is its own strong reason to build that one piece.

The trap investors will catch: the pure wrapper

There is a failure mode worth naming directly because it is so common right now. A founder assembles a product entirely out of third-party APIs, a model API here, a transcription API there, a vector database service, glued together, and presents it as an AI startup. The product might even be good. But when an investor or a serious competitor looks at it, the question they ask is: where is the technical moat? If the entire stack is third-party APIs assembled together, that is a product bet, not a technology bet, and a pure product bet needs a different and stronger kind of moat to survive, real distribution advantages, network effects, switching costs, exclusive partnerships, because a competitor can assemble the same APIs.

This is not a reason to never use third-party APIs; almost every smart AI company does, heavily. It is a reason to be honest about what your defensibility actually is. If you are buying all the AI, your moat has to come from somewhere else, your distribution, your data flywheel, your customer relationships, and you had better have that answer ready, because the assembled-APIs part is not it.

The hybrid path, and how to sequence it

For most founders the right answer is a deliberate hybrid: buy the frontier model APIs and the commodity infrastructure, and build the application layer where your business logic and your data create the real differentiation. That keeps your engineering spend focused on the part that is actually yours while you get the commodity capabilities instantly and cheaply from vendors who have already solved them. When you do rent those APIs, pricing your AI feature so token costs never eat your margin is the discipline that keeps the bought part from quietly draining the business.

The sequencing matters too, because building too early is its own waste. A sensible play is to launch fast on bought or white-label components to prove the demand and the unit economics, then build custom only once you have validated that customers want it and the numbers work, the same MVP-scoping discipline that ships in six weeks. A full custom AI platform build can run well into six figures with significant ongoing maintenance, and many companies struggle even to hire the talent for it, so you do not want to commit that until you know what you are building is wanted. This is also where you can prove an automation project paid for itself in hours saved before spending more. Prove it cheap, then build the part that is the moat.

Decide where your moat is, then the rest is obvious

Run any AI feature through one question before you decide to build it: is this a commodity capability that vendors already sell well, or is it the part where my proprietary data, domain expertise, or core product creates an advantage nobody can copy? Commodity, buy it, instantly and without guilt. Your advantage, build it, and spend your best engineers there. Most of your stack will be bought. The small part you build is the part that is actually your company.

This is the judgment we bring to the AI and automation work we do with founders, helping them spend a quarter on the AI that is genuinely their moat instead of on plumbing they could have rented, and we have lived it ourselves: LadenX, our AI site-reliability engineer, buys the commodity model capability and builds the part that is the real product, the command classification and safety system that refuses destructive actions without human sign-off, because that judgment layer is the thing no general tool provides. Decide where your moat lives, build there and only there, buy the rest, and you will reach revenue with something defensible instead of something either unfinished or undifferentiated.