Build, Buy, or Partner: The AI Capability Decision

Most build-versus-buy decisions get made backwards. They start with a vendor demo that impressed someone, or an engineer who wants to build it, and the reasoning gets assembled afterwards to fit. The decision deserves better than that: it sets your cost base, your hiring plan, and your speed for the next several years.

Here is the honest version. Six questions decide it. Answer them first, before you sit through a single vendor demo. The one-page version is downloadable at the bottom — take it into the room where the decision actually gets made.

• Build if it's the thing customers actually pay you for.
• Buy if it's commodity or table-stakes.
• Partner if it matters but isn't your differentiation.

• Build — a strong, proven in-house team.
• Buy — none, or close to none.
• Partner — some capability, but stretched thin.

• Build — high exposure; the data can't leave your walls (KRITIS, health, regulated finance).
• Buy — low; standard handling is fine.
• Partner — moderate; it needs care, not a fortress.

• Build — strategic; nine months or more is acceptable.
• Buy — yesterday; under a quarter.
• Partner — this year; three to nine months.

• Build — no real fit; it's genuinely bespoke.
• Buy — mature vendors cover the real workflow, not just the demo.
• Partner — partial fit that needs heavy customization.

• Build — capex; a long-term asset.
• Buy — opex; a predictable subscription.
• Partner — mixed.

Count where your answers land. The column with the most marks is your answer. It will not be unanimous — real decisions rarely are — and the split is the useful part, because it tells you exactly which risk you are accepting.

Most AI capabilities are not your differentiator. Fraud scoring, transcription, document extraction, standard forecasting — mature vendors do these better than you will, and they maintain them while you sleep. If a real vendor fits, buy it, integrate it properly, and put your engineers on the twenty percent that is actually yours. Buying the solved parts is not the timid choice. Rebuilding a solved problem is the expensive one.

Build the part that is your differentiation — the thing the business is actually paying you for. Build when no vendor fits the real workflow, when the data cannot leave your walls (KRITIS, health, regulated finance), or when the capability compounds into a moat the longer you own it. One honest caveat: budget the maintenance tail. The build is the cheap part; owning, staffing, and evolving it for five years is the real cost, and it belongs in the business case from day one.

Partner is the specific in-between: you have the ambition and the stakes, but not the team or the timeline. A partner de-risks the first version — proving the concept before you commit a hiring plan to it — or brings a capability in-house on a schedule you could not hit alone. The test of a good partner engagement is simple: it ends with your team more capable than it started, and the capability living with you, not with the partner.

Whatever you land on, write the reasoning next to it. In eighteen months someone will ask why, and "it seemed right at the time" is not an answer that survives an audit. The six-question version is.

---

If your answers are split down the middle — and for regulated, enterprise-scale AI they often are — that is usually the moment an outside read pays for itself. Download the one-page matrix to run it with your team, or book a call and we will work it through against your specifics.