The build-buy-blend framework
Buy is the default, build needs a differentiation-and-data argument, and most real answers are blend — plus the capability question hiding under every tool question.
Every funded initiative now faces the same fork, and it arrives wearing a tool question: 'which vendor?' or 'should our team build this?' The framework has three honest answers, and the industry's scar tissue says most leaders pick the wrong one for status reasons — building what they should buy (engineering pride) or buying what they should blend (procurement reflex).
- Buy — a finished product that does the job: the default, and the right answer far more often than technical teams volunteer. Buy when the capability is undifferentiating (you need it to work, not to be yours): meeting transcription, document OCR, coding assistants, monitoring and security tooling. The buy test: would a competitor using the identical product erase any advantage? If no advantage existed to erase — buy.
- Build — your team, on model APIs (the paid connections your software makes to a vendor's AI models), owning the system. Justified only when both halves of the argument hold: the capability differentiates (it touches how you win deals or defend margin) and you hold a data or domain advantage no vendor can match (Alder's lane-by-lane history for ETA prediction; your claims history; your support corpus). One half alone is a blend argument wearing ambition.
- Blend — the workhorse: a platform bought, your workflows/prompts/data configured on top. The Automation-course pattern at enterprise scale: support triage on your ticketing platform's AI, document extraction tuned on your tender formats, an assistant grounded in your policy docs. You own the configuration (which is where the value concentrates) without owning the plumbing. When in doubt between build and blend — blend, and revisit in a year with usage data.
The question under the question
Tool decisions are secretly capability-location decisions: where will the organizational knowledge live? Buy locates it in a vendor relationship; build locates it in a team you must retain; blend locates it in configuration your people own. That's why serial buying of point solutions quietly hollows out a company's ability to do the next initiative, and why Module 1's cluster observation matters here: Alder's documents-in-motion cluster argues for one blended document-AI capability serving the three funded document initiatives (six candidates surfaced in the inventory), not separate purchases. Portfolio thinking, applied to plumbing.
Build trap: 'we're basically a tech company' — eighteen months later you own an undifferentiated internal product with one maintainer and no roadmap. Antidote: the two-part test, applied out loud. Buy trap: 'the vendor demo did exactly this' — six months later the demo's 90% is your 60%, integration doubled the cost, and switching means re-training everyone. Antidote: the vendor-evaluation discipline in the next lesson, especially the eval-on-your-data clause.
Data observability — monitoring whether the warehouses feeding your AI are fresh, complete, and sane — is a canonical buy: undifferentiating, product category mature, error cost of DIY high. (Edova builds Vigil in exactly this category, and Meld in entity resolution — another canonical buy.) The point isn't our products; it's the pattern: infrastructure that must simply work, where a vendor's thousandth customer made the product better than your first internal version would be, is what buy is for.