Business · Nº 18 · 3 min read

Build, Buy, or Managed? An Honest Framework

Three ways to get AI working in your business, the real trade offs of each, and the questions that decide it, bias declared up front.

Declaration first: I run a managed AI provider, so I have a horse in this race. I am going to give you the framework I would want my own family to use anyway, because the fastest way to lose trust is to pretend every problem needs what I sell. Plenty do not.

You have three ways to get AI capability into a business. Buy an off the shelf product. Build something yourself. Or have a managed provider build and run it for you. Each is right somewhere.

Buy, when the problem is a commodity

If thousands of businesses share your exact problem, someone has productised it. Transcription, meeting notes, grammar and writing help, generic chat assistants, accounting add ons. Buying wins when the problem is standard, when configuration beats customisation, and when you would gain nothing from owning the plumbing.

The trap: buying a dozen point solutions that do not talk to each other, each with a subscription and a login, until your stack is a junk drawer. Buy deliberately, review quarterly, and delete ruthlessly.

Build, when the workflow is your edge

Coding harnesses have genuinely changed this category. Work that needed a development team three years ago is now within reach of a determined operator with Claude Code and a spare weekend, and some of the most impressive systems I see are owner built.

Build when the workflow you are automating is specific to how you win, when off the shelf tools keep almost fitting, and when someone in the business genuinely enjoys this and will still be maintaining it in a year. That last clause is the whole game. Building is a boat purchase: the sticker price is the beginning. Software that touches your real operations needs updating, monitoring, and fixing when an API changes at 7am on invoice day. The build cost has collapsed. The ownership cost has not.

Managed, when you want outcomes rather than projects

Managed makes sense when the value is high, the integration is real, phones, inboxes, practice management systems, and nobody internal can own it properly. You are paying for the outcome and the ongoing operation: monitoring, maintenance, improvement, and a throat to choke when something misbehaves. It costs more than a subscription, and it should, because you are buying the absence of the ownership burden described above.

The trap here is providers who install and vanish, which is just building with extra steps. Interrogate the "managed" claim: who watches it, how do you reach them, what does improvement look like after month one, and can you exit with your data and your dignity.

The four questions that decide it

  1. Is this workflow differentiating? Commodity problem, buy. Your secret sauce, build or managed, because off the shelf will flatten what makes you different
  2. Who owns this in twelve months? A name, with hours. No honest answer, then managed, or do not start
  3. What breaks if the person who set it up leaves? If the answer is everything, you have a hobby, not infrastructure
  4. What is an hour of your attention worth? Founders systematically undervalue this. Building can be cheap in dollars and ruinous in focus

The honest summary

Buy the commodities. Build where the workflow is your edge and a real owner exists, and enjoy how far that now goes. Go managed where the value is high and the ownership answer is nobody. Most businesses end up with a sensible mix of all three, and the mix shifts as your capability grows.

Whichever route you pick, one thing decides whether it works: the humans who have to live with it. That is next.