Build vs. buy: an AI guide for SMBs

Almost every AI project starts at the same fork: do we pay a subscription for a tool that already exists, or build something custom? The industry's default answer is "buy, always." The honest answer is "it depends, and there are rules for deciding."

This post is the framework we use to settle that decision in the audit. It's not a case for building — we build software, yes, but selling you a build when a $30-a-month SaaS solves your problem would be terrible for you and for trust. It's a method for making the call with numbers instead of fashion.

The four factors that decide

Every build-vs-buy decision comes down to four variables. Run your case through them before you quote anything — most people skip straight to price, and price is the one that misleads you most on its own.

Process fit. How well does the off-the-shelf tool match how you actually work? A SaaS gives you the 80% it solved for the average of its customers. The question is whether your remaining 20% is a luxury or exactly where you live.
Integration. Does it connect to your current systems, or force you to re-key data by hand? A tool that doesn't integrate creates new work while promising to remove it.
Total cost. Not the monthly fee. The three-year cost, including per-seat and per-volume charges, plus the time your team spends fighting what doesn't fit.
Lock-in. If you want out tomorrow, do you take your data and your logic with you, or are you trapped? The cost of leaving is part of the cost of entering, even if it isn't on the quote.

When to buy (SaaS wins)

Buying is the right call more often than a developer likes to admit. Buy when:

The problem is generic and already solved. Invoicing, accounting, email, video calls. Don't build what a mature product does better for $30 a month.
Your process fits the tool's standard flow. If the 80% a SaaS gives you covers what you need and the remaining 20% is tolerable, buy it.
Volume is low or uncertain. If you don't yet know how much you'll use something, a cancelable subscription is cheaper than a build you might not need.
You need to start tomorrow. The SaaS already exists. A build takes weeks. If time is the critical factor, buy now and evaluate building later.

The SaaS trap isn't the monthly fee. It's when the tool almost fits and you end up hiring people to work around its limits. That's where "cheap" turns expensive without ever showing up on the invoice.

When to build (build wins)

Building wins when your process is your advantage, or when the SaaS gets expensive precisely because of what makes you different. Build when:

The process is your differentiator. If the way you operate is part of why you win customers, molding yourself to a third party's generic tool is turning your advantage off.
Integration with your systems is the whole point. A build connects to what you already have; a SaaS asks you to live inside its garden.
Volume makes the SaaS scale against you. Many tools charge per seat or per action. At a certain volume, a custom build running on your own infrastructure is cheaper month over month.
You need logic templates can't handle. Casual Spanish text, decisions across several tables, rules that change per customer. That's where a system that reasons over your data beats chaining brittle templates.

When a $5,000 build beats a subscription

The number where the scale tips is lower than people think. Here's a hypothetical example with simple math.

Say a tool costs $400 a month at your scale: that's $4,800 a year, $14,400 over three years. And say that, because it doesn't quite fit your process, your team loses a few hours every week fighting it. A fixed-scope build starting at $5,000, running on your infrastructure with no monthly fee, pays for itself in a little over a year against the subscription alone — and sooner once you count the recovered hours.

The math flips toward building when three things are true at once: the SaaS charges by volume or per seat and that number is growing, the tool doesn't quite fit your process, and the problem is stable rather than an experiment you might abandon. If all three apply, building usually wins. If only one does, the subscription is almost always the smarter bet — run the arithmetic honestly and let the numbers decide. The full ranges and what moves the price are in what AI adoption actually costs.

When NOT to build

The part a software vendor won't tell you. Don't build if:

You haven't validated the process by hand. If the flow still changes every week, building freezes it too soon. Stabilize the process first.
The problem is small and isolated. To connect two tools once, a simple automation or a SaaS is plenty. You don't need custom software for that.
Nobody will own the system. A build with no internal owner dies the same way an abandoned pilot does. Why that happens is in why AI pilots die.
You just want to experiment. If it's exploration, try a cancelable SaaS. Once you know the problem is real and stable, build.

A five-question checklist

Before you decide, answer these. Three or more "yes" tips the scale toward building; fewer, toward buying.

Is the process part of how you differentiate from competitors?
Does the SaaS charge per seat or per volume, and is that number going to grow?
Does the off-the-shelf tool leave out something you genuinely need?
Is integration with your current systems critical?
Is the problem stable, not an experiment you might abandon?

None of the five is decisive on its own. One strong "yes" — like the process being your core differentiator — can outweigh three lukewarm ones. The checklist orders the conversation, it doesn't replace it: the final tally matters less than understanding which of the five weighs most in your business.

If you're unsure of your answers, that doubt is normal and it's exactly what we settle in the audit: we run your case through the framework and the recommendation comes out with numbers, even when the recommendation is to buy.

Frequently asked questions

Isn't it obvious that building always gives more control?

More control, yes, but also more responsibility. A custom build is yours to maintain and evolve. If the problem is generic and a SaaS solves it well, that extra control is weight you don't need to carry. Control for its own sake isn't worth it; control over what differentiates you is.

Can I combine both strategies?

Almost always the right answer. You buy SaaS for the generic stuff — email, invoicing, accounting — and build only where your process is your advantage. The mistake is building everything or buying everything on dogma instead of deciding piece by piece.

Isn't a custom build riskier than an established SaaS?

The real risk isn't that the build fails technically, it's that nobody adopts it. A well-scoped build, deployed on your infrastructure with a trained internal owner, is as reliable as any SaaS — and without the risk of the vendor raising prices or shutting down.