Build, buy, or partner: an honest decision tree for SMB AI

Every SMB AI conversation eventually arrives at the same fork: do we buy something off the shelf, build it ourselves, or bring in outside help? Most of the advice on this question is written by people selling one of the three branches, and it reads like it.

We’re going to try to do better, with one disclosure up front: we’re a partner-side business. AI enablement is what we sell. Discount everything below accordingly, and then check the numbers anyway, because the most useful data point in this debate doesn’t come from a consultancy. It comes from MIT.

Start with the failure data

MIT’s NANDA group published “The GenAI Divide: State of AI in Business 2025”, and its headline finding is brutal: 95% of enterprise GenAI pilots deliver no measurable P&L impact, despite an estimated $30–40 billion poured in. The root cause they identify is a learning gap: tools that don’t fit workflows, and organisations that don’t redesign processes around them.

Buried in the same study is the finding that matters for this decision: projects bought from specialised external partners succeeded roughly 67% of the time, versus roughly 33% for internal builds. Two to one.

That doesn’t mean “always partner”. It means the default intuition (“we know our business best, so we should build it ourselves”) has a measured failure rate attached, and it’s worse than most owners assume. Knowing your business is necessary. It turns out not to be sufficient.

With that on the table, here’s when each branch is actually right.

Buy: when the workflow is generic

Buy off-the-shelf software with AI built in when the workflow you’re improving is one that thousands of businesses share in roughly the same shape. Accounting, scheduling, CRM, support desks, email marketing. The vendor has seen ten thousand versions of your problem; their AI features are trained on the aggregate; you benefit from every other customer’s edge cases.

The test is roadmap alignment. If the vendor’s product direction matches where your workflow is heading, buying is almost always the right call: you get continuous improvement for a subscription fee, and someone else carries the maintenance burden forever.

Buy when: the workflow is generic, a credible vendor exists, and you’d struggle to articulate what’s unique about how you do it. If your honest answer to “what’s special about our invoicing?” is “nothing, really”, do not let anyone build you custom invoicing AI. Including us.

The discipline buying requires is different: actually switching the features on. More on that below, because the data here is embarrassing.

Build: when AI is the product, or the workflow is the moat

Build in-house when one of two things is true.

First, AI is your product. If you’re selling AI-powered software, the capability is your business and outsourcing it makes no sense. We run a SaaS company; the AI in that product is built and owned in-house, because it is the company.

Second, you have genuine engineering depth and the workflow is genuinely your moat: the thing you do differently that customers pay for. If your competitive advantage lives in a process nobody else runs, an off-the-shelf tool will sand off exactly the edges that make you money, and a partner will need so much of your context that you might as well own the result.

But be honest about both conditions. “Genuine engineering depth” means engineers who will still be there in two years to maintain it, not one keen developer (see traps, below). And “the workflow is the moat” is rarer than founders believe. Most workflows feel unique from the inside and look standard from the outside. The 33% success rate for internal builds is mostly companies that failed this honesty test.

Partner: when the workflow is yours but the capability isn’t

Partner when the workflow genuinely is specific to your business, but the capability to automate it isn’t something you have or sensibly want to hire for.

This is the middle case the build/buy binary misses. Your close process, your quoting logic, your customer onboarding: too specific for off-the-shelf, too small to justify a permanent engineering function. A good partner brings the capability, embeds it in your workflow rather than a generic one, and (this is the part to insist on) hands it over. You should own the system, the documentation, and the ability to run it without them.

The handover is the tell. A partner whose model requires you to keep paying them forever to operate the thing has built themselves an annuity, not you a capability. Ask directly: what does month thirteen look like if we never call you again? The answer should be “it keeps running, here’s the runbook”. (Yes, retainers exist and are often sensible, but they should be a choice, not a hostage situation.)

Partner when: the workflow matters and is yours, the capability gap is real, and you want it embedded then handed over, with your own people trained to run it as part of the engagement, not as an upsell.

The trap cases

Each branch has a characteristic way of going wrong. We’ve seen all three; we’ve committed at least one.

Building because a developer was keen. The most expensive sentence in SMB software is “our developer reckons he could build that in a weekend”. He probably can: a demo. What he can’t build in a weekend is the error handling, the edge cases, the documentation, and the succession plan for when he leaves. The build cost is the deposit; maintenance is the mortgage, and it falls due forever. If the keen developer is the only reason the build option is on the table, it shouldn’t be.

Buying AI features you never switch on. Shibumi’s 2026 AI fatigue research found 52% of software licences sit unused. Half. Most SMBs already own AI capability (inside the accounting platform, the CRM, the support desk) that nobody has configured, trained on, or turned on. Before you buy, build, or partner anything, audit what you’re already paying for. The cheapest AI project available to most businesses is an afternoon in the settings of software they already own. (We’ll happily say it: you don’t need us for that.)

Partnering with deck-sellers. The consulting market is full of firms whose deliverable is a roadmap for things other people will have to build later. Gartner has flagged “agent washing”: of thousands of vendors describing themselves as agentic AI providers, they count only around 130 doing it for real. Your defence is to ask for proof-of-work: show me a system you built that’s running in production today, what it costs to operate, and what broke in the first three months. Anyone who’s actually shipped will answer with specifics, including the failures. Anyone who answers with a framework diagram is selling decks. The “what broke” question is the sharpest filter we know: real operators always have war stories, and tell them a little too readily.

Our bias, declared and checked

To say it plainly: we make money when you choose “partner”. You should weight our enthusiasm for that branch accordingly.

Here’s what we’d offer against our own interest. If your workflow is generic, buy; we will tell you this in a discovery call and it will be a short call. If AI is your product, build; hiring us to build your core product would be bad for both of us. If you already own unused AI features, switch them on first; that’s free and might be enough. And the MIT 67/33 finding cuts both ways: it’s evidence for external partners in aggregate, not evidence for any particular partner. A bad partner gets you into the 95% with invoices attached.

The honest summary of the data is narrower than any sales pitch: external specialised help roughly doubles your odds when the project genuinely needs building and the partner has actually shipped before. Both conditions carry weight.

The five-question self-diagnostic

Answer these honestly and the tree mostly resolves itself:

1. Is this workflow genuinely different from how a thousand similar businesses do it? If no → buy. If you’re not sure, it’s a no.
2. Is AI capability the thing you sell, or want to sell? If yes → build, and staff it properly.
3. Do you have engineers who will own this in two years, not just build it this quarter? If no, the build branch is closed regardless of how keen anyone is.
4. Are there AI features already in your existing software that you’ve never switched on? If yes → do that first. Revisit this list afterwards; the answer may change.
5. If a partner built it and then vanished, could your team run what they left behind? If a candidate partner can’t make that answer “yes”, different partner.

Do this next week

Before any build, buy or partner conversation: spend one afternoon listing every piece of software you currently pay for, and next to each, the AI features it already includes and whether anyone has turned them on. Most businesses we meet find at least one capability they’re already paying for and not using.

Take whatever’s left over (the workflows no existing tool covers) and run them through the five questions. That one-page document will make every subsequent vendor conversation shorter, cheaper, and considerably harder for anyone to bluff through. Including us.