Build vs Buy AI: A Decision Framework for SMBs

The build vs buy decision is older than AI. Every IT shop has had this conversation about every internal system since the 1990s. The AI version has a few new wrinkles but most of the framework is unchanged.

The decision matters more than usual for AI right now, though, because the SaaS market is in a phase where every product has "AI" stapled to the side and most of them are about as deep as a Tuesday demo. Picking the wrong side of build vs buy in this environment is expensive in a way it wasn't for prior categories. I've watched SMBs spend $30,000 on a SaaS that didn't fit their workflow when they could have built the custom version for $25,000 and gotten exactly what they needed. I've also watched SMBs spend $80,000 building something they could have bought for $200 a month.

This post is the decision framework I use to keep both errors off the table.

The default: buy first, build the gap

The default move for an SMB on a generic workflow is buy. Modern SaaS is good. The build market for software has matured. If your problem is a problem most businesses have, the SaaS for it exists and is probably cheaper, more reliable, and better-supported than what you'd build.

The build vs buy AI question only gets interesting when the workflow isn't generic. The mistake most owners make is assuming their workflow is more special than it actually is. Most calendar scheduling is calendar scheduling. Most transcription is transcription. Most generic customer support is generic customer support. Calendly, Otter, Zendesk, and their kin handle these well for most SMBs.

The build vs buy decision is really a question of how custom the workflow is, not how complicated the AI is.

The three buckets

I sort SMB AI workflows into three buckets. Each has a default answer.

Bucket A: pure commodity

The workflow is the same across most businesses. Examples: meeting scheduling, transcription, generic email summarization, calendar drafting, document OCR for common formats, generic chat.

Default: buy. SaaS exists for all of these. Custom builds are slower, more expensive, and will be worse than the off-the-shelf product within a quarter.

The exception is when you're processing such high volume that the per-unit SaaS cost is genuinely meaningful. A business doing 50,000 transcriptions a month might economically build. Most SMBs don't do enough volume to cross that threshold.

Bucket B: customized commodity

The workflow looks generic on the surface but the specific way your business does it matters. Examples: customer support that requires deep product context, lead triage with industry-specific intent categories, invoice processing for a non-standard vendor format, internal search across your unique policy docs.

Default: buy a layer and build the custom part on top. SaaS provides the model and the basic interface. You build the integration, the prompting, and the workflow-specific logic. The hybrid is usually cheaper and faster than either pure buy or pure build.

This is where most SMB AI projects actually land. Recognizing it stops you from buying a SaaS and then complaining it doesn't fit, or building from scratch when you could have used a SaaS API.

Bucket C: deeply custom

The workflow is specific to your business in a way that the commodity layer can't address. Examples: agent reasoning over your proprietary product taxonomy, automation across your bespoke internal systems with no clean API, drafting that requires brand voice trained on years of your specific writing, classification using your specific judgement rules that no generic model can learn from prompting alone.

Default: build. The SaaS market won't address this for a long time, if ever. Trying to bend a generic tool to fit will waste more money than building the custom version.

This is the smallest bucket for most SMBs but the highest-impact. The agents that produce real competitive advantage live here. They're also the most expensive to build and the most expensive to operate.

How to tell which bucket a workflow is in

Three quick tests.

Test 1: search for SaaS products. If you can find five reputable SaaS products for the workflow with good reviews, it's bucket A or B. If you can find none after an hour of searching, it's probably bucket C.

Test 2: how much of the work is the model versus the integration. If the model is doing the interesting work and the integration is "send a webhook to our CRM", bucket A or B. If the integration is itself the interesting work (orchestrating across your internal systems, applying your specific business rules, joining your proprietary data), bucket C.

Test 3: what happens if you describe the workflow to ChatGPT in detail and ask it to recommend a tool. If the recommendation is a real product that more or less fits, bucket A. If the recommendation is "you'd want to combine X and Y", bucket B. If the recommendation is "this is custom and you'd want to build", bucket C.

The tests are not rigorous and they sometimes disagree. When they do, prefer buy unless the bucket-B case is overwhelming. The build cost is always higher than the optimistic estimate; the buy cost is always lower than the build cost when both are calculated honestly.

I cover the cost of building a custom AI agent in more detail, including the categories of cost that get under-quoted. A useful gut check: if your build estimate is under $25,000 for an SMB workflow, you've under-scoped the integration. If your build estimate is over $80,000 for a single first agent, you've probably scoped a build that should have been three smaller agents.

The hybrid pattern that wins most often

The SMB AI builds that work tend to follow a specific hybrid pattern.

A SaaS or commodity API handles the "intelligence" layer. OpenAI, Anthropic, or a similar foundation model API, plus a vector database SaaS, plus maybe a workflow automation SaaS like Zapier or Make. None of these is bespoke. They're commodity infrastructure.

Custom code handles the integration, the prompting, the business rules, the evaluation, and the user interface. This is the build part. It's what makes the agent specific to your business.

The ratio of build to buy in the hybrid is usually around 70/30 in favor of build, measured in either time or money. The buy part is the cheap part. The build part is the expensive part. But the build part is also the part that produces the advantage, so the ratio is what you'd expect.

The mistake I see SMBs make is trying to flip this ratio: buy a SaaS that promises to "do everything end-to-end" and avoid the custom build. The end-to-end SaaS exists. It works for the median customer. It does not work for any specific customer whose workflow is more than 20% custom. The result is a SaaS subscription that's actively used for 6 months and then quietly cancelled.

Specific decisions I've seen go well and badly

Three real-world examples from SMB engagements I've been close to.

A logistics company picked custom build for their warehouse exception triage agent. The workflow involved their proprietary inventory codes and their specific routing rules. The build cost $35,000, ships in 10 weeks, has been in production for 8 months without major changes. The right call.

A real estate agency tried to bend a generic AI chatbot to their lead qualification workflow. They paid $18,000 for a year of SaaS, spent another $15,000 on internal staff time configuring it, and abandoned it after 7 months because it kept missing leads that didn't match the median profile. The right call would have been a $25,000 custom build, which they're now running.

A consulting firm bought a generic transcription SaaS for client meeting notes. $200 a month, deployed in a day, no integration issues. The right call. They considered building something more custom that would tag entities and surface insights. Cost estimate came in at $40,000. They decided the SaaS was good enough for now and may revisit in a year. Also probably the right call.

Notice the pattern. The bad outcome is buying for the deeply custom workflow or building for the commodity one. The good outcomes are matching the bucket to the workflow honestly.

The decision in one paragraph

If the workflow is generic and SaaS exists, buy. If the workflow is mostly generic with a custom edge, buy the commodity layer and build the custom part on top. If the workflow is deeply specific to your business and no SaaS fits, build. The default is buy. The case for build has to clear a real bar. The case for hybrid is the most common right answer for SMBs running real AI projects.

Anyone who tells you "always build" or "always buy" is selling you what they make money on. The right answer depends on the workflow.