AI

Build vs Buy: When NOT to Use AI (and When You Should)

AI is in every pitch deck and every sales call. But for most founder problems, the right answer is boring off-the-shelf software, and sometimes no software at all. Here's a plain-English framework for deciding.

James Levine6 min read

Build vs Buy: When NOT to Use AI (and When You Should)

Every founder I speak to right now has been told they need AI. By an investor, a competitor's landing page, or a LinkedIn post at 11pm. The pressure is real, and it pushes people to bolt AI onto problems that never needed it, while spending nothing on the boring decision that actually matters: should you build this at all, or just buy it?

Let me give you two frameworks. First, build vs buy. Then, within "build", when AI genuinely earns its place.

Framework one: build vs buy

The instinct of most technical founders is to build. The instinct of most business-first founders is to buy the shiniest thing. Both are wrong as defaults. The real question is: is this thing your competitive edge, or is it plumbing?

Buy it (or use off-the-shelf) when:

  • It's a solved problem. Auth, payments, email, CRM, scheduling, invoicing. Thousands of companies do these. You will not do them better, and you'll spend a fortune trying. Use Stripe. Use an existing CRM.
  • It's not your differentiator. Customers don't choose you because your internal analytics dashboard is bespoke. Buy the dashboard.
  • Speed matters more than fit. A 90%-fit tool you can switch on tomorrow usually beats a perfect tool six months away.
  • The total cost of ownership is hidden. Building means building and maintaining, forever. Every line of code you own is a line you have to secure, update, and debug at 2am.

Build it when:

  • It is your differentiator. If the thing is the reason customers pick you, own it. This is the workflow, the model, the experience nobody else has.
  • Nothing off-the-shelf actually fits. You've genuinely looked, and the tools force your customers through a process that breaks your business.
  • Integration glue is the whole point. Sometimes the value is in how existing tools connect. That connective tissue is often worth building even when the pieces aren't.

A good rule: buy the plumbing, build the thing that makes you special. Most founders have this backwards: they build custom auth and buy a generic version of their actual product.

I've built plenty of genuinely custom applications where "build" was clearly right (see what I build). But I've also talked founders out of building things they could rent for £40/month. That conversation saves more money than any code I could write.

Framework two: when AI actually helps

Say you've decided to build. Now: does AI belong in it? Here's the honest test.

AI genuinely helps when:

  • The task is fuzzy and language-shaped. Summarising documents, drafting text, classifying messy free-text, semantic search where keywords fail. This is where AI is genuinely magical rather than marketing. I built exactly this kind of thing with AWS Bedrock, semantic search and summarisation over large content libraries, and it was the right tool for a problem traditional code handles badly.
  • Perfect accuracy isn't required. AI is probabilistic. If a 95%-right answer that a human can quickly check is useful, great. If you need 100%, be very careful.
  • The alternative is worse. Sometimes the non-AI version is a team of people doing tedious manual triage. AI that gets them 80% of the way there is a real win.
  • You have the data. AI features live or die on the data you feed them. No data, no useful AI.

AI is hype or overkill when:

  • A simple rule would do. "If order value > £500, flag for review" does not need a large language model. It needs an if statement. I've seen founders quote for "AI-powered" features that were three lines of ordinary logic.
  • You need exact, repeatable results you can stand behind. Financial calculations, billing, anything where a wrong number costs real money or trust. You want code you can point to and explain, not a model that "usually" gets it right.
  • It's decoration. Adding a chatbot nobody asked for so you can say "AI" on the homepage. Users see through it, and you've added cost, latency, and a new way to embarrass yourself.
  • The failure mode is dangerous. If a wrong answer causes real harm, whether medical, legal, or financial, the bar for using a probabilistic system is very high, and the safeguards are expensive.

The question I ask every founder

"If this feature worked perfectly but had no AI in it, would customers care?"

If the answer is "no, they just want the outcome," then AI is an implementation detail, not a selling point. Use it where it's the best tool, hide it where it isn't, and never let "we should use AI" drive the roadmap. Let the problem drive it.

A worked example

A founder came to me wanting an "AI-powered matching engine" for a two-sided marketplace. Big budget attached, big expectations.

We dug into it. The matching logic was actually a handful of well-understood rules: location, availability, price range, a rating threshold. That's not AI; that's a database query and some sorting. Building it as a "matching engine with AI" would have added months, cost, and unpredictability for zero customer benefit.

But, buried in the same conversation, was a genuine AI opportunity: their support inbox was drowning in repetitive questions, and free-text queries were impossible to route sensibly. That was a perfect fit for AI classification and summarisation. So we built the matching with boring, reliable code and spent the AI budget where it actually moved the needle.

That's the whole point. It's not pro-AI or anti-AI. It's right tool, right problem.

The bottom line

Before you build, ask if you should buy. Before you add AI, ask if the problem is actually AI-shaped or if a simple rule would do. The founders who win with AI aren't the ones who use the most of it. They're the ones who use it precisely, on the one or two problems where it genuinely beats the alternative, and use boring proven tools everywhere else.

If you're staring at a build-vs-buy decision or an "AI or not" question and want an honest second opinion rather than a sales pitch, that's exactly the kind of thing I help founders think through as a fractional CTO.

Let's talk it through →

About the Author James Levine is a senior full-stack developer and fractional CTO based in Surrey. Ex-Amazon and Ticketmaster, he helps founders decide what to build, then builds it. AI is one tool in the box, used when it's the right one.