Build vs. Buy: When an SME Should Wire Its Own AI

Every SME founder I talk to eventually hits the same fork: a vendor is quoting them a monthly fee for an AI tool, and a voice in the back of their head says I could just wire this myself in a weekend. Both instincts are usually wrong. The cost of getting it wrong is not the subscription price — it is the months you spend maintaining something you should never have owned, or the leverage you leave on the table by renting something you should have built.

I have lived the expensive version of this decision. So instead of a generic "it depends," here is the framework I actually use, and the four questions that decide it.

The only four questions that matter

Strip away the noise and a build-vs-buy decision for an AI workflow comes down to four factors. Run any candidate automation through them before you write a line of code or sign a contract.

The trap is treating these as a checklist where three out of four means "build." They are not equal. The two that carry the most weight are core to the business and frequency, and most automations an SME is tempted to build score low on at least one of them. A monthly report generator is not core and runs twelve times a year. Build that and you have manufactured a maintenance liability to save yourself an afternoon a month.

Why "I could build this in a weekend" is the wrong frame

The cost of assembling a workflow has collapsed. With a capable model and a tool like n8n or Make, a competent operator can stand up a passable automation in hours. That is real, and it is why the build option looks more attractive every quarter.

But the build cost was never the number that mattered. The number that matters is the cost to own it forever. The moment you wire something yourself, you have signed up for the model deprecations, the API that changes its auth scheme, the edge case that surfaces at 2 a.m., and the fact that the whole thing lives in one person's head until that person leaves. Cheap-to-start and cheap-to-own are different universes, and the distance between them is where most SME automation projects quietly die.

This is also where I have to give you the warning I give myself. When building gets easy, you build too much. You end up with eleven half-finished internal tools, each one technically working, none of them maintained, your attention sprayed across all of them. I have a line I repeat from a PARP interview I did in 2024 — "a company doing everything is a company doing nothing." It was about strategic focus, but it applies precisely here. The constraint on building is not whether you can. It is whether building this specific thing is the best use of the one resource you can't buy back: your team's attention.

The expensive lesson I paid for myself

In 2020 I had to make a real version of this decision, and the price of getting it right was turning down roughly €3M.

At the time my company — then Cervi Robotics — could have kept taking outsourcing contracts. There was around €3M of that work available: real revenue, the safe path. The alternative was to turn it all down and bet everything on building one autonomous platform — the drone-in-a-box system that became Dronehub. Outsourcing was buy-mode thinking: sell your hours, serve other people's roadmaps. Building the platform was the bet that the core thing was worth owning end to end, even though it meant walking away from money that was already on the table.

I turned the outsourcing down. The reason wasn't bravery; it was the framework above. Outsourcing scored low on defensibility — anyone with engineers could do it — and it wasn't core to where I wanted the company to go. The platform scored high on all four. That clarity is the only thing that makes a decision like that survivable, because in the short term the spreadsheet says take the €3M.

The transferable lesson for an SME isn't "always make the bold bet." It's the opposite of bold. It's that build is the right call only on the few things that are genuinely core and defensible — and on everything else, the discipline is to buy, rent, or skip, and protect your focus for the one or two builds that actually compound.

Let time and money verify the tool, not your gut

Here is the part founders skip. You do not have to decide build-vs-buy permanently on day one. You can run a cheap experiment and let reality settle it.

Another line I keep from that same 2024 conversation is "time and money verify people." I have started applying it to tools and processes too. Time and money verify tooling. A vendor tool that you have actually paid for and run for two quarters has proven something a demo never can. A home-built workflow that has survived real use — real edge cases, a model upgrade, a team member's vacation — has earned the right to keep existing. Most candidates on both sides never survive that test, and that's the point: the test is cheap, and it kills bad decisions before they cost you.

So the practical move is to buy first by default, even if you suspect you'll eventually build. Subscribe to the vendor tool for a quarter. You learn the actual shape of the problem, the real frequency, the edge cases you'd never have predicted. If the tool earns its keep, you've saved yourself a build. If it fails you in a specific, nameable way, that failure is now the spec for the thin slice you build yourself. You build with knowledge instead of with optimism, which is the difference between a tool that lasts and a weekend project you abandon.

There's a related rule I teach constantly: if I do something twice, I think about automating it; if three times, I automate it. The same threshold applies to building. Don't build for a hypothetical future frequency. Build when the frequency is already real and proven, because then the maintenance cost has something concrete to pay for. I've written more about that trigger in Do It Twice, Think About Automating; Three Times, Automate.

Build thin, buy the commodity underneath

For most SMEs the answer is not build-or-buy. It is build the thin layer that's yours, buy everything underneath it.

Almost any AI workflow decomposes into layers: a model, an orchestration tool, connectors to your other systems, and — on top — the specific logic that encodes how your business actually operates. The bottom layers are commodities. You should not be building your own model, your own queue, or your own retry logic. Rent those. The only layer worth owning is the top one, and even there, build only the part a competitor couldn't replicate by signing up for the same vendor you did.

A concrete way to see it: a generic support autoresponder is a commodity — buy it. But the routing logic that reflects how your particular business triages and prioritizes its customers might be genuinely yours, worth owning as a thin layer on top of a bought foundation. Separate those two things. Most teams build the whole stack when 90% of it was available to rent, and they end up maintaining commodity plumbing instead of the 10% that was actually differentiating.

This is the practical reconciliation of "build is for the core" and "don't over-build." You are not choosing one mode for the whole company. You are choosing per-layer, and the bias is to buy until you hit the part that's defensibly yours.

What this means, and where I'd start

If you're staring at this decision right now, here's the order I'd run it in.

First, count the frequency honestly — not the frequency you imagine, the one in your logs. If it's not at least the "three times and it's a pattern" threshold, you probably shouldn't be automating it at all yet, let alone building it.

Second, ask whether this process is core. Not "important" — core. The test: would a competitor copying it hurt you? If the answer is no, buy or rent and move on. Spend your scarce build attention elsewhere.

Third, for the few things that pass both, still buy first for a quarter if a credible vendor exists. Let time and money verify the tool. Build only the slice the vendor demonstrably can't serve, and build it thin on top of bought infrastructure.

And fourth — the discipline that's hardest and matters most — resist building the other ten things just because you now can. A company doing everything is a company doing nothing. The leverage isn't in how many automations you wire. It's in choosing the one or two that compound and refusing the rest.

If you want the more hands-on version of this, I've laid out how I'd choose a first automation in How to Build Your First Useful AI Agent for a Small Business, and the broader trap of mistaking AI activity for AI value in What Most Entrepreneurs Get Wrong About AI. I teach this framework, hands-on and without the hype, through my AI education work — because the founders who win with automation aren't the ones who build the most. They're the ones who build the right two things and rent everything else.