Build vs. Buy Is a Spectrum, Not a Switch
“Build vs. buy” makes it sound like a switch with two positions. In AI it is closer to a dial with three settings. You can buy a finished product and use it as it comes. You can build a system from scratch. Or — the option most people forget — you can build on top of models someone else has already trained, assembling the specific parts you need around a foundation you rent by the token. Almost no mid-sized company should be training its own large model; that part is a solved and enormously expensive commodity, best left to the handful of labs that do nothing else. So the real question is narrower than “build or buy.” It is: how much of this do we assemble ourselves, and how much do we take off the shelf?
Framing it as all-or-nothing produces the two classic mistakes. One is buying a tool that almost fits and quietly bending your process around it, until the tool — not you — decides how the work gets done. The other is commissioning a bespoke build for something a forty-euro-a-month product already does well, and paying for the privilege of maintaining it forever. Both are expensive, and both are avoidable once you stop treating this as a single yes-or-no.
When Off-the-Shelf Wins
Buy when the task is a commodity — something where the way you do it gives you no advantage, and no one, customer or competitor, would notice if you swapped one vendor for another. Transcription, translation, meeting summaries, grammar checking, a coding assistant for your developers, a chatbot answering questions from a public help page: these are solved products. Dozens of vendors do them well, the quality is good enough, and building your own version would burn months to arrive somewhere slightly worse.
Two other signals point to buy. The first is speed: a SaaS tool is running this afternoon, a custom build is running in weeks. If the value is in having something now, buy now and revisit later. The second is volume. Custom engineering has a fixed cost floor it has to clear before it makes sense; if you process fifty documents a month, a per-seat product will be cheaper than anything bespoke for years. The instinct to build “for control” over a commodity task is usually a false economy — you take on maintenance, hosting, and a constantly moving model landscape in order to own something that was never going to differentiate you in the first place.
When Custom Pays Off
Custom earns its keep when the thing you are automating sits close to how you actually compete, or when no product on the market can touch your specific data, process, or constraints. That covers more of the interesting German-Mittelstand use cases than the SaaS marketing would suggest — and far fewer than the in-house “let’s build our own AI” enthusiasm would.
When your data or process is the edge
The strongest case for building is proprietary data. Your twenty years of service tickets, your contract archive, your ERP records, the accumulated judgement in how your best estimator prices a job — no off-the-shelf tool has seen any of it, and none ever will. A custom retrieval or agent system that reasons over your own corpus does something a generic product structurally cannot, and that is exactly where AI tends to pay off in a mid-sized business rather than in the demos (there is more on where it reliably lands). The same holds when your process is idiosyncratic. A packaged tool encodes one company’s idea of how the work should flow — usually not yours. If your particular way of doing it is part of why customers stay, forcing it into someone else’s workflow throws away the very thing worth keeping. Concretely: a machine builder whose quoting logic lives in the heads of two senior engineers has something worth encoding; a firm that just wants its meeting notes tidied does not.
The hidden costs on both sides
Neither option is as cheap as its headline. Buying looks cheap until you add the integration glue you still have to write yourself, per-seat pricing that scales badly as adoption grows, a roadmap you do not control, price increases you cannot refuse, and the quiet risk that your data leaves your building for a vendor’s cloud — a real problem under the DSGVO when you cannot audit their sub-processors. Building looks expensive up front and then keeps costing: someone has to maintain it, monitor it, and absorb the model provider changing under them. I have written separately about what an AI project actually costs; the short version is that the hidden line items, not the visible ones, decide whether either path was a good idea. For regulated or sensitive data the whole calculation can collapse to a single factor: if a compliant SaaS option simply does not exist, an on-premise or German-hosted build is not the expensive choice — it is the only one.
The middle path: build on top, not from scratch
For most companies the right answer is neither extreme. You rent the hard, generic part — a foundation model, via API or self-hosted open weights — and build only the thin, valuable layer that is genuinely yours: retrieval over your data, the integrations into the systems you already run, the guardrails that keep it safe, and an interface your people will actually use. This is where the economics work. You get most of what “custom” promises without paying to reinvent the part a lab spent hundreds of millions of euros getting right. It is also the most defensible position over time: when the underlying models improve — and they will, on someone else’s budget — you swap the engine and keep everything you built around it. Building from scratch, by contrast, means personally owning problems the entire industry is already solving for you.
A Decision Framework
You can get most of the way to an answer with five questions. Is this core to how we compete, or a commodity anyone could buy? Does doing it well require our proprietary data or process? Is our volume high enough to beat per-seat pricing? Do we have a compliance constraint — on-premise, DSGVO, data residency — that rules out the obvious tools? And how much does it need to integrate with systems we already run? Mostly “commodity, low volume, no constraints” points cleanly to buy. “Core, proprietary data, real integration, a compliance line to hold” points to build — and in practice that means build on top of a model, rarely from scratch. Getting the build safely into daily use afterwards is its own discipline; that is the subject of deploying AI in the enterprise.
A quick example. A regional insurer wants to draft first-response emails to policy questions. If that means answering generic questions from the public terms and conditions, it is close to a bought chatbot and should probably stay one. If it means pulling the specific clauses from this customer’s contract and the notes from their last three claims, no product can do it — and building on top of a model, with retrieval over the policy archive kept on the insurer’s own servers for DSGVO reasons, is the honest answer. Same department, same afternoon, two different verdicts. That is why the question has to be asked per use case, not per company.
This is exactly the decision the AI Readiness Check is built to make. Rather than argue build vs. buy in the abstract, it runs your real use case against your real data and comes back with a grounded recommendation — buy this, build that, or build on top of this — from someone who has taken all three to production and has no product to sell you. If you would rather talk the trade-off through first, get in touch.