TL;DR

Most small businesses should buy off-the-shelf where they can, build custom where they must, and use a hybrid approach (pre-trained models + your data and rules) for everything in between. The hybrid route is where I spend most of my time with clients. It's faster, cheaper, and you keep control.

I get asked this question constantly. A founder or ops director sits across from me and says: “Should we build our own AI thing, or just buy something?” And they're usually hoping I'll give them a clean answer.

I can't. It depends. But after doing this for a while, I've got a pretty reliable way of working through it. So here's the honest version — not the consultant-speak version.

When Buying Is the Right Call

If you're solving a problem that thousands of other businesses also have, someone's already built a tool for it. Customer support, meeting transcription, document processing, email triage — these are solved problems. You don't need to reinvent the wheel.

I had a property management client last year who wanted to build a custom AI system for tenant enquiry handling. They'd specced out a three-month project. I set them up with a simple chatbot using Claude's API and a few well-written prompts. They were live in two days. It handled 60% of their inbound messages without any custom code. Done.

Buy when:

  • The problem is common — if you can Google “AI for [your problem]” and get 10 SaaS products, buy one
  • You need it working this month — off-the-shelf is days, not quarters
  • You don't have developers on staff — and hiring a contractor for a custom build you can't maintain later is a trap
  • Good enough is good enough — not every process needs a perfect solution. 80% automated is often transformational

When You Actually Need to Build

This is rarer than most people think. I'd say maybe 1 in 5 client conversations ends with “yeah, you need something custom.” But when you do, you really do.

I'm working with a jewellery business right now that has a genuinely unique product catalogue system. Their categorisation, pricing rules, and supplier relationships don't fit into any off-the-shelf tool I've seen. We're building a custom agent that understands their specific domain — and it has to be custom, because the business logic is the product.

Build when:

  • Your competitive edge depends on it — the AI is doing something that differentiates your business, not just saving admin time
  • Your data or workflow is genuinely unusual — and I mean genuinely, not “we use spreadsheets slightly differently”
  • Off-the-shelf tools can't integrate with your stack — legacy systems, weird APIs, data that lives in odd places
  • You need full control over the data — regulated industries, sensitive customer data, on-premise requirements
A word of caution: “We're unique” is the most expensive sentence in business. Before you commit to a custom build, stress-test the assumption. I've seen companies spend six figures building something that a Zapier integration and a well-prompted Claude API call could have handled.

The Hybrid Approach (Where I Spend Most of My Time)

The reality is most projects land in the middle. You take a pre-trained model — Claude, GPT, whatever fits — and you give it your data, your rules, and your tools. You're not building from scratch, but you're not using an off-the-shelf product either.

This is what I do for most of my clients. A recent example: I built an operations portal for my own consultancy that uses Claude's Agent SDK with custom tools plugged in — it can query my database, check deployments, manage alerts, send emails. The AI is off-the-shelf (Claude). The tools and rules are mine. Took weeks, not months.

Other hybrid setups I've used with clients:

  • Claude API + custom system prompts + tool integrations — this is my go-to. Fast, flexible, you own the logic
  • n8n or Make for workflow orchestration — visual workflow builders that connect AI to your existing systems without code
  • AI trained on your own documents — point a model at your knowledge base so it answers questions using your data, not the internet

Hybrid gets you live in 2-4 weeks, costs a fraction of a full custom build, and you keep ownership of the important bits — your data, your business logic, your prompts.

The Comparison

DimensionBuyBuildHybrid
Time to valueDays to weeks3-6 months2-4 weeks
Upfront costLow (SaaS subscription)High (dev time + infra)Medium (consulting + API costs)
CustomisationWhat the vendor gives youTotal controlHigh where it matters
Ongoing maintenanceVendor handles itAll on youShared — vendor maintains the model, you maintain the config
Lock-in riskHigh (hard to leave)Low (you own everything)Medium (but your logic is portable)

How I'd Work Through the Decision

When a client asks me this, I run through four questions:

  1. Is this problem common or unique? If I can name three SaaS tools that do roughly this thing, we're probably buying. If I can't, we're building or going hybrid.
  2. Do you have anyone who can maintain a custom system? If the answer is no, building is risky. You'll ship something and then it'll rot. Hybrid with a consultant (hi) works better.
  3. Is your data the advantage? If your data or business rules are the thing that makes your service special, you need control over them. That's build or hybrid territory.
  4. How quickly do you need this? If the answer is “yesterday”, buy something now and evolve to hybrid later. Shipping something imperfect beats planning something perfect.

The Costs Nobody Tells You About

Whichever route you pick, budget for the stuff that doesn't show up in the pitch deck:

  • Vendor lock-in is real — I've seen businesses spend more migrating off a tool than they spent adopting it. Ask about data export on day one.
  • API costs scale non-linearly — that Claude API bill looks fine at 100 calls a day. At 10,000 it's a different conversation. I recently had to build a cost tracking system for my own portal because the SDK was underreporting by 3x.
  • Custom code needs babysitting — if you build it, you maintain it. Models update, APIs change, dependencies break. Factor in at least 20% of the build cost per year for maintenance.
  • Integration always takes longer than you think — connecting your AI to your existing systems is where projects go sideways. Double your estimate for this bit.

What I'd Actually Do

If you're an SME with no AI in production yet: start by buying. Pick the most painful manual process in your business, find a SaaS tool that handles it, and get it live. Learn what works, what doesn't, and what you actually need AI to do differently.

Then, when you've got a specific, validated need that off-the-shelf can't handle, go hybrid. Take a model API, connect it to your systems, give it your rules. That's where the real value is for most businesses — and it's not as expensive or complicated as you'd think.

Full custom builds are for when you've exhausted the first two options and the business case is strong enough to justify months of development. For most of the businesses I work with, that's the exception, not the rule.