Build, Buy, or Call an API: How We Actually Decide

Clients ask me why we don't just build our own model. It's a fair question, and most of the time the honest answer is that building our own would be the slowest and priciest route to a result slightly worse than an API hands us on day one. Engineers like building, and 'we made our own' reads well in a pitch. So I put every AI capability through the same three gates before we commit: whether it's our actual edge, how fast it's changing, and what it costs at our real volume. Call the API when the capability is a commodity Text generation, transcription, translation, OCR, embeddings, general chat. These are commodities now. A hosted API from OpenAI, Anthropic, or Google gives you a better result on day one than a small team builds in a quarter, and someone else pays to keep it current. We reach for an API when the capability isn't our differentiator and the vendor improves faster than we could. The trade you accept is a per-call price, a dependency on their uptime, and data leaving your walls. For most features that trade is worth it. Both risks are manageable: put the provider behind one interface so you can switch, and read the data-handling terms before anything sensitive goes over the wire. Buy when it's already someone's whole product Some things are a company, not a feature. A mature vector database. A full observability stack for LLM apps. A content-moderation service. When a vendor's entire business is the thing you need, and it's a solved, unexciting problem, buying beats shipping a worse version and maintaining it forever. The question here is whether owning it would be a distraction. If maintaining the thing pulls the team off the product the client is actually paying for, we buy. Build when it's the reason they hired you Building earns its cost in a narrow band. When the capability is your real differentiator, when your proprietary data changes the outcome, or when the per-call math at your volume finally beats a subscription, owning it makes sense. Even then, building rarely means training a model from scratch. It usually means orchestration, our own data pipeline, retrieval tuned to the domain, and evaluation nobody else has. The base model still comes from an API. The edge lives in the plumbing around it. Design the exit before you commit Whatever we choose, we design the switch first. The provider sits behind an interface. Prompts and data stay ours, in a format we control. Costs get an alert, because the math that made an API cheap at 10,000 calls a day can flip at a million. A build-or-buy call isn't permanent. Volume grows, prices fall, a vendor rewrites its terms, and last year's right answer becomes this year's migration. Choosing well once matters less than being able to change your mind cheaply. On AI work at Shanti Infosoft, most capabilities end up as an API call wrapped in a thin, switchable layer, and only the genuine differentiator gets built in-house. If you want to see how we draw that line on real projects, it's at https://shantiinfosoft.com. We drew this exact line in how the build-vs-buy decision moved. Which capability did you build that you'd call an API for if you were starting over today?