passcut

Comparison

Build vs buy: AI agents

There are three real ways for an SMB or mid-market company to get AI agents working: hire in-house, buy a vertical AI product, or bring in an integrator to build on your stack. Each is right for someone.

The short version

  • Hire in-house when AI is your product or you have five or more workflows queued.
  • Buy vertical SaaS when your workflow is genuinely standard and a proven product covers it.
  • Use an integrator when the workflow is specific to you and spans several systems.
  • Cost shapes differ: salary, versus per-seat subscription forever, versus build fee plus flat retainer.
  • Exit paths differ most: only ownership lets you leave without losing the automation.

The three paths, defined

Hiring in-house means recruiting an AI engineer (or a small team) who builds and iterates on agents as employees. You get maximum control and context, at salary cost, hiring risk, and months of ramp time.

Buying vertical AI SaaS means subscribing to a product built for one function: an AI bookkeeping categorizer, a meeting-notes tool, a support deflection bot. Fast to adopt, polished for the standard case, and priced per seat or per usage for as long as you use it.

Using an integrator means bringing in a firm that builds custom agents on top of the systems you already run, then maintains them. The fit is engineered to your workflow, and (in our model, though not every firm's) the resulting system belongs to you: code, configuration, and credentials in your accounts.

Buy (vertical AI SaaS)Build with an integrator
Time to valueDays, if your workflow matches theirsWeeks, shaped to your workflow
FitYou adapt to the productThe system adapts to you
Cost shapePer-seat/usage subscription foreverBuild cost + modest retainer
DataLives in the vendor's cloudStays in your accounts
OwnershipNone. Churn risk is realYou own the code and config
CoverageOne function per vendorAny workflow across functions

Dimension by dimension

Time to value

SaaS wins the sprint: if your workflow matches the product, you can be running in days. An integrator build takes weeks (our pilots run 30 days against your real data). Hiring takes the longest by far: months of recruiting plus months of ramp before the first workflow ships.

The trap is optimizing for week one. The workflow you automate will run for years; a few weeks of fitting matters less than the fit itself.

Fit: adapt to the product, or the product adapts to you

Vertical SaaS is built for the median customer. If you are the median (standard bookkeeping, standard meeting notes), that is exactly what you want. The further your process is from standard (approval chains, multiple systems, industry quirks), the more your team bends to fit the tool.

Custom builds invert this: the agent learns your workflow as it actually runs, including the parts you'd never find in a product's settings page. That is also why no product exists for workflows that span QuickBooks, Zendesk, and your ERP at once: nobody can productize your specific combination.

Coverage: one function versus any workflow

Each SaaS vendor covers one function, so breadth means a subscription stack: one tool for support, one for bookkeeping, one for meeting notes, each with its own data silo and login. An in-house engineer or an integrator covers whatever is next on the list, and each build reuses the plumbing of the last.

Data and security

With SaaS, your documents and customer data live in the vendor's cloud under the vendor's terms; review each one's data handling separately. With in-house or integrator builds done right, data is processed through your own accounts with the model providers under no-training API terms, and nothing is warehoused by a third party. We put that in the contract.

Ownership and churn risk

Subscriptions buy access, not assets. If the vendor raises prices, gets acquired, or pivots, your workflow moves with them, and the switching cost is yours. This is not hypothetical in a market moving this fast.

An owned system carries none of that: the code sits in your accounts, and any competent engineer can maintain it. The integrator's leverage over you is only as good as their service, which is exactly the incentive you want them to have.

The operations load nobody prices in

SaaS is self-serve: when it misbehaves, you file a ticket. An in-house engineer is a team member you manage, retain, and eventually replace. An integrator under a retainer is accountable by contract: monitoring, response times, and a monthly improvement, without a seat on your payroll. Pick the load you actually want to carry.

Model churn, and who absorbs it

The models under all of this improve and get deprecated on a cycle of months, not years. A SaaS vendor absorbs that churn for you, and also changes your workflow's behavior silently when they swap models. An in-house engineer spends real time re-evaluating. Under our retainer, model updates are applied and regression-tested against your workflows, so improvements arrive without surprises.

Whichever path you pick, insist on this property: the system's rules and tests should outlive any particular model. Swapping the engine should never mean rebuilding the car.

Regulatory responsibility

AI rules increasingly assign duties by role: who provides the system, who operates it. With SaaS, you accept the vendor's terms and their compliance posture wholesale. With a custom build, roles can be set deliberately: in our contracts you are the owner and operator, we are the integrator, and for EU-facing work we scope engagements to stay out of high-risk categories by design.

For most SMB back-office workflows this is straightforward. The point is that it's written down before anything runs, not discovered afterward.

The handover test

Whatever path you choose, apply one test: if the people who built it vanished tomorrow, could a stranger operate the system? For SaaS the answer is no by definition; you'd be shopping again. For in-house, it depends entirely on documentation culture. For an integrator, demand it contractually: documentation, a recorded walkthrough, credentials inventory, and code in your accounts.

We structure every build to pass that test, because it is also what makes our own maintenance honest: a client who can leave is a client you have to keep earning.

The cost reality

In-house is the expensive path that looks responsible: a capable AI engineer in the US runs well into six figures before benefits, takes months to ramp, and carries retention risk. It amortizes only when you have a queue of workflows and permanent iteration ahead.

Vertical SaaS is the cheap path that compounds: $50 to $500 a month feels painless, then it scales with seats and usage forever, and the subscription buys you access, never an asset. When the vendor pivots or raises prices, your workflow moves with them.

The integrator path is a build fee plus a retainer: with us, pilots from $4,900, production builds from $9,000, and Care at $1,500 a month. The asset is yours. Over a two or three year horizon, the math usually beats per-seat SaaS for any workflow with real volume, and beats a salary for anything under a handful of workflows.

Which one fits your situation

AI agents are your product, or you have 5+ workflows queued

You need permanent iteration and deep context. A salary amortizes; an agency invoice at that scale doesn't.

Pick: Hire in-house

Your workflow is truly standard: meeting notes, bookkeeping categorization

A proven product covers it end to end, cheaper than any custom build ever will. Standard problems get product prices.

Pick: Buy SaaS

The workflow spans QuickBooks, Zendesk, and your ERP, with approval rules

No product matches how your company actually runs it. Custom fit without the salary, and you keep the asset.

Pick: Integrator

How to run this decision

  1. 1

    Write the workflow down and mark each step as standard (any company does this) or specific to you.

  2. 2

    Demo two vertical SaaS products and count the workarounds your team would need. Three or more is a fit problem, not a training problem.

  3. 3

    Price 24 months on all three paths honestly: subscription times seat growth, salary plus ramp, build fee plus retainer.

  4. 4

    Ask each option the exit question: if we leave in a year, what do we keep?

  5. 5

    Weight the decision by where errors are expensive. Fit matters most exactly where mistakes cost most.

The verdict

Hire in-house when

AI agents are core to your product or you have 5+ workflows queued and permanent iteration ahead. A capable AI engineer runs well into six figures with real hiring risk. Right for some mid-market companies, rarely first move for an SMB.

Buy SaaS when

Your workflow is standard (bookkeeping categorization, meeting notes, basic chat deflection) and a proven product covers it end to end. If that describes you, buy the product.

Use an integrator when

Your workflow is specific to how your company runs, touches several systems, or needs human approval built in. You get an engineered fit without the in-house salary, and unlike SaaS, you keep the asset. That is the work we do.

Exit paths matter more than entry prices

Leaving a SaaS means exporting your data and losing the automation. Leaving an in-house build means re-hiring the person who understood it. These exits are where the cheap option gets expensive.

The integrator model is only honest if the exit is real: code, configuration, and credentials in your accounts, documentation any engineer can maintain from, and a retainer you can cancel monthly. That is how we structure every build, and it also means you can bring the system in-house later when hiring finally makes sense. The asset moves with you, not with us.

Common mistakes

Deciding once for the whole company

The paths compete per workflow, not per company. Buying SaaS for meeting notes and hiring for your core product can both be right on the same day.

Comparing month-one prices

SaaS wins every month-one comparison and loses many 24-month ones. Run the longer math with seat growth included before calling anything cheap.

Hiring one engineer to be a whole function

One person is a bus factor: no coverage on vacation, no peer review, and the system leaves when they do. Hire when there's enough work for redundancy, or buy accountability by contract until then.

Forcing SaaS onto a cross-system workflow

A product built for one function meets a workflow that spans three systems, and your staff becomes the integration layer, copy-pasting between tools. That labor is the cost the subscription hid.

Common questions

Can we start with an integrator and bring it in-house later?

Yes, that is the ownership model working as designed. The system runs in your accounts with documentation and a recorded handover, so an in-house engineer inherits a working system instead of a mystery.

A SaaS product covers 80% of our workflow. Buy it?

If the missing 20% is tolerable, yes. Buy it and move on. Custom agents make sense when the missing 20% is exactly where the hours and errors live.

How should we compare integrator quotes?

Four questions: who owns the system afterward, what monitoring is included and how often it actually checks, what response times are committed in writing, and what happens when you cancel. Published pricing versus discovery-phase pricing tells you a lot too.

What does two years actually cost on each path?

Rough shapes: SaaS is subscription times months times growth in seats. In-house is salary plus ramp. Integrator is build fee plus retainer, flat. The audit does this math with your real numbers, including the honest case where SaaS wins.

Can we mix the paths?

Most companies should. Buy SaaS for the standard functions, use an integrator for the workflows specific to your business, and hire when the queue justifies a salary. The paths compete per workflow, not per company.

What happens if the integrator disappears?

With ownership done right, your agents keep running: the code, credentials, and documentation are in your accounts, and any competent engineer can maintain them. Ask every integrator this question and listen for hesitation.

Aren't integrators just reselling ChatGPT?

The model is a commodity; nobody should pretend otherwise. What you pay for is the engineering around it (integration, validation, approval flows, monitoring) and contractual accountability for the result. Ask to see a run log and a response-time commitment; that distinguishes builders from resellers quickly.

When is hiring in-house clearly the right call?

When agents are part of your product, when data sensitivity demands everything stays in-house, or when you have a standing queue of five or more workflows with permanent iteration ahead. At that point a salary amortizes and deep context compounds.

Should we just wait for the models to get better and cheaper?

The models will improve whether you move or not; the hours your team spends on manual work are spent either way. Build on an architecture where models are swappable and the improvements arrive automatically. Waiting has a payroll cost that compounds monthly.

Do integrators lock clients in with proprietary frameworks?

Some do, and it quietly converts a build into a subscription. Ask one question: does the code run without your platform? Ours does, by design, and your engineers can verify it during handover.

Related workflows: Customer support · Bookkeeping & close · Lead qualification

Want this answered for your stack?

The free audit looks at your tools, volumes, and workflows, and tells you which approach fits, even when the answer isn't us.

Get your workflow audit45 minutes · written summary · no obligationAlready know what you want built? Get a quote