Decision framework

Build vs buy AI automation: when custom actually beats SaaS in 2026

Most build vs buy frameworks oversimplify. Here's the honest 2026 decision matrix for UK services businesses choosing between SaaS, SaaS-plus-glue, and engineer-led custom AI builds.

Written byRobin LairesRobin Laires
10 min read2,276 words
Summarise with
Brass balance scale with paper on one side and stacked cards on the other, illustrating the build vs buy AI automation decision.

You're a partner at a 14-person services firm. You've sat through three discovery calls in the last month: one with a SaaS vendor offering an "AI-powered" version of the workflow tool you're already using, one with a Zapier-flavoured automation agency promising six workflows in eight weeks for £15,000, and one with an engineer-led shop quoting £25,000 to build something custom on your own infrastructure. They're all telling you they're the right answer for your firm. They cannot all be right. Nobody is giving you a framework for choosing.

This post is that framework. I'm Robin, I run Laires Labs, a solo AI engineering studio in London. I sit in the third category and I've watched a lot of firms make this decision well and badly. The decision is not the binary "build vs buy" the consulting world insists it is. It's a three-way choice, and most firms end up with a deliberate hybrid.

The short answer

The build vs buy decision for AI automation in 2026 has three answers, not two: buy SaaS for generic workflows where the vendor's product is well-aligned to your need; buy SaaS plus a Zapier or n8n layer for simple integrations and one-off connectors between products; build custom for cross-system workflows, regulated work, or anything where the volume, integration count, or specificity makes SaaS bend out of shape. Most firms past 10 staff end up with a hybrid: SaaS or PMS as the system of record, custom code as the workflow layer that integrates everything else. Run the two-year total cost of ownership math before committing in either direction.

Why the standard build-vs-buy framework is incomplete

Most build vs buy advice frames the choice as binary: build everything yourself, or buy everything off the shelf. In 2026, neither extreme is right for a services business. The honest decomposition has three options.

Option one: pure SaaS. You buy a product that does the workflow. The vendor handles updates, integrations, AI features, and compliance. You configure it for your business. Examples: Xero for bookkeeping, HubSpot for CRM, Karbon for practice management, Clio for legal practice management. The vendor's roadmap determines what you can do.

Option two: SaaS plus glue code. You buy several SaaS products and wire them together with a workflow tool like Zapier, n8n, or Make. The glue is configured by a non-engineer or a small reseller agency. You get cross-system workflows that none of the SaaS products handle natively, but at the cost of fragility (any vendor API change can break the glue) and limited logic (Zapier's conditional branching breaks fast).

Option three: engineer-led custom. You commission code written for your business, deployed to infrastructure you own, integrating with your specific stack. Cost is concentrated upfront. The deliverable is yours. Maintenance is your responsibility (or your retained engineer's).

The honest reality: most small services firms in 2026 should run all three at once, deliberately, with each option doing what it's good at.

When SaaS wins outright

SaaS is the right answer when several of the following are true.

The workflow is generic across many businesses. Bookkeeping, payroll, basic CRM, calendar scheduling, generic email marketing, expense management, document signing. These are commodity workflows. The vendor has invested far more in the product than you ever would in a custom build. Buying is the obvious answer.

You're under five staff. The fixed cost of a custom build (£12,500 floor minimum) doesn't pay back at this scale. SaaS subscriptions amortise across the team, custom code amortises against revenue.

The workflow has no business specificity. If your version of the workflow looks like everyone else's version, the vendor has built a better product than you can.

The integration count is one or two. SaaS-plus-glue handles this fine.

You don't have engineering capacity. Maintaining custom code requires either a retained engineer, a contractor relationship, or comfort with the build sitting unmaintained for stretches. If none of those are realistic, buy SaaS.

The vendor's roadmap matches your needs. Sometimes the vendor is genuinely shipping the features you need. Pay them.

When custom wins outright

Custom is the right answer when several of these are true.

The workflow is specific to your business or vertical. A recruitment firm's candidate-to-submission flow is not the same as another firm's. A law firm's matter intake is not the same as another firm's. A practice's onboarding-to-AML-to-engagement-letter chain is not the same. Specificity defeats vendor product roadmaps.

Two or more systems must integrate. Cross-system workflows are where custom shines. Your bookkeeping data needs to talk to your billing, which needs to talk to your CRM, which needs to talk to your platform reconciliation. SaaS-plus-glue gets brittle fast at this scope.

The data is sensitive enough that you want it on your infrastructure. Regulated services (legal, accountancy, financial advice, healthcare) increasingly need to evidence where client data lives, who can see it, and what happens on deletion. Custom builds running on your own AWS or Render account are easier to defend in a compliance audit than SaaS shared with thousands of other firms.

Seat fees are scaling badly. A 25-person firm paying for 25 seats of three different SaaS products is hemorrhaging money on per-seat scaling. Custom code's marginal cost of supporting a 26th user is roughly zero.

Volume is high enough that LLM API costs at custom-tier rates beat the bundled SaaS markup. SaaS AI is typically priced at £15-£50 per user per month. Custom builds run direct against the LLM API at actual token cost, which for moderate-volume use is £100-£300 per month for the whole firm regardless of seat count.

The workflow is core enough that ownership is itself a competitive advantage. If your way of running this process is part of how you win clients, owning the code matters.

When SaaS plus glue is the right answer

The middle path. Often the right answer for the smallest end of services businesses, and a reasonable transitional state on the way to custom.

Single connector workflows. New invoice in Xero, post to Slack channel. New form submission, create row in Google Sheet. Zapier handles this in 20 minutes for £20 a month forever.

Limited fan-out and conditional logic. Zapier and n8n handle "if A then B" and basic filters fine. They start to fall over at "if A and B but not C, route to D, E, or F based on G."

You expect to revisit later. If you'd happily replace the Zapier setup with custom in 18 months as the workflow's value becomes clear, starting with Zapier is the right call. Don't over-invest in proving a workflow.

No engineering capacity now, possibly later. Configuring Zapier is non-engineer work. Hiring or contracting a custom build is engineering work. If you're between the two, glue is the bridge.

The constraint to hold in mind: every Zapier or n8n connector is a maintenance burden. Vendor APIs change. Task limits hit. Errors fail silently. A firm running 30 Zaps in 2026 is paying maintenance cost in adviser or operations time even if it doesn't show up as an invoice.

The five questions to ask before deciding

Asked in order, these collapse most firms' decision in under ten minutes.

1. Does this workflow exist in a SaaS product that already covers 80% of your needs? If yes, buy that product. The remaining 20% is either accepted, configured, or covered by glue code. If no, consider custom.

2. How many systems must this workflow touch? One: SaaS handles it. Two to three: SaaS-plus-glue. Four or more: custom.

3. What's the volume? Low (10 events per day or fewer): SaaS or glue. Medium (10-100 per day): glue or custom. High (100+ per day): custom is usually cheaper at LLM API costs.

4. How specific is the logic? If the workflow's branching looks like every other firm's, SaaS. If it has firm-specific rules, edge cases, or integrations, custom.

5. What's your two-year horizon? Static team size, stable workflow, no growth expected: SaaS. Growing team, evolving workflow, increasing complexity: custom.

If three or more answers point to custom, run the build numbers. If three or more point to SaaS, buy the SaaS.

Build vs buy decision matrix scoring SaaS, SaaS-plus-glue, and engineer-led custom across firm size, system count, volume, specificity, and time horizon.

Two-year total cost of ownership is the right horizon

First-year economics always favour SaaS. The build cost is concentrated upfront, the subscription cost is spread monthly. A £15,000 custom build looks expensive against £400-per-month SaaS. By year two, the comparison shifts. By year three, the gap widens.

I've published worked TCO numbers across three verticals for context.

VerticalFirm sizeSaaS path 2-yearCustom path 2-yearDetail
Recruitment10 recruiters£68,240£58,000-£61,000Detail
Law8 fee earners£51,440£47,640-£50,640Detail
Accountancy9 staff£43,824£45,264-£48,264Detail
IFA / Wealth6 advisers£37,760£47,800-£50,800Detail

Build vs buy AI automation 2-year total cost of ownership across UK recruitment, law, accountancy, and IFA verticals, comparing SaaS and engineer-led custom paths.

The pattern across all four: at small firm sizes the totals are close. The custom path's economic argument shows in year three or four, when the SaaS path's per-seat fees scale linearly with headcount and the custom path's marginal cost of supporting a tenth or twentieth user is roughly zero.

For a fuller pricing breakdown by tier and by build size, see the pricing reference.

Hybrid is the realistic answer

Most services firms past ten staff end up running all three options together, deliberately:

  • SaaS or PMS as the system of record. The platform that holds clients, jobs, time, billing, and core operational data. Vendor maintains it. You pay per seat.
  • SaaS-bundled AI features for the workflows the vendor has actually built well. Karbon AI, Clio Duo, Intelliflo's AI features, Bullhorn Automation. Useful inside their boundary.
  • Specialist vendor SaaS for narrow workflows where a vendor has built deep capability you can't justify replicating. Aveni for legal call notes, AdvisoryAI for IFA suitability, Dext for receipt processing.
  • Custom code as the workflow layer that integrates everything else: cross-system flows, regulatory chase, custom dashboards, scheduled batch jobs, specialised reporting.

I've written specific build-vs-buy comparisons for two of the most common practice management platforms:

Both reach the same hybrid conclusion: keep the bundled AI for what it does well, build custom for what it does not reach.

Ownership, exit cost, and the long view

A piece of the decision that buyers consistently underweight: what happens at year five.

On the SaaS path, you're paying ongoing seat fees. The vendor controls the roadmap, the price, and the data export. If the vendor raises prices 30% (and the SaaS market does this regularly), you absorb it or migrate. Migration off a SaaS that's been your system for three years is a five-figure project at minimum.

On the SaaS-plus-glue path, the glue is fragile by design. Every vendor API change can break a connector. The Zapier or n8n configuration is owned by you in name but maintained by an ad-hoc resource (the original reseller agency, an internal champion who left, a freelancer who's hard to find). The cost of recreating it from scratch is roughly the original build cost.

On the custom path, the code is yours. If your engineer leaves, another engineer can take it on. If your needs change, the code changes. The asset compounds. The risk is concentrated in maintenance discipline: a custom build no one is paying attention to gets brittle the same way any neglected codebase does.

The exit cost question rarely shows up in a discovery-call quote. Ask it before signing.

When to skip the agency entirely

Three cases where the honest advice is "don't hire anyone, including me."

The problem is small. Two-step Zapier workflows costing £40 a month forever beat a £5,000 reseller engagement and a £15,000 custom build for the same job. If the work fits inside Zapier's free or Starter tier and you have a non-engineer who can configure it, do that.

You already have an engineer. A full-time engineer or a long-term contractor builds most automation workflows faster than an agency can scope them. Specialist external work is the exception (specific LLM eval pipelines, complex integration with rare APIs, AI-first systems where the engineering judgement is unusual).

The cost won't pay back. A workflow that saves 30 minutes a week of a £30,000 employee's time is worth £390 a year. A £15,000 build doesn't make sense for that. Run the back-of-envelope payback math before scoping.

Book a call

If you're sitting on this decision and trying to work out which of the three paths fits your firm, that's the call to book. Twenty minutes, no pitch. Tell me the workflow, the systems involved, the firm size, and the rough business case. I'll give you a direct read on which path fits and what each one would cost. You walk away with a one-page write-up of the build, the price, and the SaaS-or-glue alternative if either is cheaper. Yours to keep whether you hire me or not.

Don't book if your budget is under £10,000, if you want generic AI strategy, or if you already have a full-time engineer. The right answer in those cases isn't Laires Labs.

Book a 20-minute call or read the full AI automation agency buyer's guide for the underlying framework on agency archetypes.

Thinking about a system like this?

20-minute call, no slides. We'll map it against your stack and I'll tell you if it's worth building.

Book a call
People also ask

Questions buyers actually ask

The decision a services business makes between buying off-the-shelf SaaS that includes AI features, configuring SaaS plus a workflow tool like Zapier or n8n, or commissioning custom code that runs on its own infrastructure and integrates with the existing stack. In 2026 the answer is rarely binary. Most firms end up with a hybrid: SaaS for the workflows the vendor handles well, plus a custom layer for the cross-system or specialised work the SaaS cannot reach.

Robin Laires
Written by

Robin Laires

Solo engineer · Laires Labs

Ten years software engineering, former tech lead at Jellyfish — one of the UK's largest independent digital agencies. Now I build custom AI systems that replace manual business processes: ads ops, sales intelligence, intake routing, research pipelines. One engineer, installed into your stack.

Related posts