"Don't build what you can buy" is good advice — until it quietly caps your business. With AI now a credible third option, the honest version is: buy your commodities, build your differentiators, and use AI where the problem is genuinely fuzzy. The hard part isn't the principle; it's being honest about which of your problems is which.
A simple framework
- Buy when the capability is undifferentiated — payroll, auth, payments, email delivery. Vendors do it better, cheaper and more securely than you will, and your customers don't care who built it.
- Build when the capability is the business — the workflow, the data model, or the experience customers actually pay you for. Outsourcing your differentiator to a vendor means competing on someone else's roadmap.
- Use AI when the task is high-variance and hard to specify in rules — summarisation, classification, extraction, natural-language interfaces — not when a deterministic system would do it better, cheaper and more predictably forever.
The trap isn't building too much. It's buying your differentiator, building your commodities, and using AI for things plain code should own — all at once.
Why this matters
These decisions compound. Buy your differentiator and you've capped your ceiling on day one — the best you can ever be is the vendor's roadmap. Build a commodity like authentication and you've signed up to maintain, secure and patch it forever, for no competitive return. And reaching for AI on a problem that a simple rule would solve adds cost, latency and unpredictability where you wanted reliability. Each mistake is survivable; making all three at once is how teams end up with an expensive system that's worse than what they replaced.
A concrete example
A logistics company wants to flag invoices that don't match a delivery. The "AI everything" instinct says train a model. But the rule is crisp — amount, date and reference must match within tolerance — so deterministic code does it perfectly, instantly and for free. AI earns its place one step earlier: reading the unstructured PDF invoice and pulling out those fields, a genuinely fuzzy task that rules handle badly. Buy the document-storage layer, build the matching logic that's specific to your business, and use AI only on the messy extraction. That's the blend working as intended.
What this means for your team
Audit your roadmap against the three buckets before you commit budget. For each capability, ask: does this differentiate us, or just need to exist? Is the logic specifiable, or genuinely ambiguous? Most strong systems end up a deliberate blend — bought components for the undifferentiated 80%, custom code for the 20% that makes you you, and AI carefully placed where it earns its ongoing cost rather than sprinkled on for the demo. If you want a second opinion on a build-buy-AI call, let's talk.
Sources
- MIT NANDA — The GenAI Divide