Should your SaaS build the AI infrastructure layer that powers your copilot, or buy it?

Adding an AI copilot to your SaaS platform might feel like a new feature request. In practice, it's a full platform build.

The demo is easy. A single model call, a chat window, and you have something convincing enough to show the board by Friday. Then production arrives, and underneath that copilot sits an entire infrastructure layer nobody scoped: orchestration, memory, guardrails, permissions, evaluation, model management, analytics. None of it is visible to your users. All of it has to work before a single customer touches the feature.

Which leaves your team with one question. Do you build that layer, or do you buy it?

This page breaks down both paths: what building actually involves, what each costs, where the industry is drawing the line, and how to work out which one fits your situation.

What does building the AI infrastructure layer involve?

More than the prototype suggests. The distance between that demo and something you can put in front of a paying customer is where the engineering time goes.

Owning the layer means building and maintaining:

• Orchestration, so an agent can plan a task, call your APIs in the right order, and recover when a step fails

• Memory and context, so the agent knows who the user is and what happened last time

• Guardrails and moderation, so it declines what it should decline

• PII masking, so customer data does not reach a model it should not

• Granular permissions, so an agent can only act within an individual user's access

• Evaluation, so you can tell whether a change made things better or worse

• Analytics, so you know what users ask for and where it breaks

• A model layer you can swap, because the model you pick today will not be the one you want in nine months

That list is for a copilot, where a user asks for something and watches it happen. The harder version is an agent that runs unsupervised, on a schedule or triggered by a change in your database. Those need retry handling, webhook infrastructure, protection against the same event firing a job twice, and permissions tight enough that an unattended agent cannot exceed what the user who triggered it could do. Nobody is watching, so it has to be right first time.

Evaluation is the part teams consistently underestimate. Shopify's engineering team, building AI into their own product, found that a model at benchmark parity still showed a 35% gap once real users arrived. Benchmarks are not evidence that something works in production. Building the harness that tells you the difference is its own project.

What does it cost?

Realistically £150,000 or more per year. Two to three senior engineers for six months to reach production, then permanent ownership after that.

The permanent part is what gets missed in the business case. Model deprecations, prompt regressions, new attack patterns, customer-reported failures, evaluation datasets that need maintaining. This is not a project with an end date. It is a standing addition to what your team looks after.

Buying the layer typically runs £25,000 to £75,000 per year depending on scope and usage, with no specialist hires and no ongoing maintenance burden.

Where the line is being drawn

The split that has emerged across the industry looks roughly like this.

Looking at the right-hand column carefully, you'll notice that almost everything in it is domain knowledge your team already has and no vendor can supply. Everything on the left is the same problem every SaaS company shipping AI is solving right now, in parallel.

The column on the right is the part that makes your SaaS unique. The column on the left is the the non-differentiating part.

When buying the layer makes sense

For most SaaS companies most of the time, which is worth saying plainly rather than hedging.

Your AI enables the product rather than being the product. Customers chose you for your domain: the workflows, the data model, the edge cases you learned the hard way. AI makes that better. It is not the reason they signed. When that is true, the infrastructure underneath is pure cost, and cost is the thing to minimise.

You are still learning what customers want the agent to do. The expensive knowledge is which workflows customers will actually use and pay for. You get that by shipping something and watching, not by spending six months on plumbing first. Buying the layer gets you to that learning in weeks.

Your engineers are your scarcest resource. Six months of two or three senior engineers costs more than the salary line. It is the roadmap those people were going to deliver. Ask what stops shipping while they build orchestration, and whether your customers would notice the difference.

You have no permanent owner for it. Building the layer is a commitment, not a project. Without a funded team who will still be maintaining evaluation datasets and handling model migrations in eighteen months, the realistic outcome is an impressive launch followed by slow decay.

Speed to market matters this quarter. If AI is a live question on renewal calls, a board expectation, or a competitive gap, the two to three week path exists and the six month path does not.

Your data is customer records rather than labelled outcomes. Building only pays back when you have observable signals showing what good looks like, at volume. Most SaaS companies have the former and not the latter.

When building makes sense

There are real cases, and it is worth being straight about them.

Your AI performance is the product. If customers choose you primarily because your AI resolves more or acts more reliably than the alternative, then a few percentage points of accuracy move revenue, and a generic layer will cap what you can reach. Intercom is the clearest example. Fin's resolution quality is not a feature of the product, it is the product.

You have a genuine data flywheel. Not customer records. Labelled outcomes, at volume, compounding. Shopify fine-tuned a model for generating automation workflows inside its own product and got a result 2.2 times faster and 68% cheaper than the closed model it replaced. That was possible because millions of merchants generate corrections and successes every day, and it came after the workflow was already proven.

Usage has made vendor economics hurt. At sufficient scale, inference cost becomes a margin problem worth engineering around. Shopify has reported cutting the annualised serving cost of one internal agent from $27M to $1M. That is a scale-stage optimisation, not a starting position.

You have constraints no vendor can meet. Fully air-gapped deployment, or regulatory requirements that genuinely rule out external processing. Worth testing honestly, because enterprise hosting and strict data boundaries cover most of what teams initially assume requires building.

Notice what those four have in common. Three are consequences of scale you reach after the AI is already working, and the fourth is rare. Almost nobody arrives at this decision on day one holding any of them.

If none of them describe you, six months goes into something your customers will never see and your competitors are building at the same time.

One honest exception

If all you need is summarisation, text generation or a help-centre chatbot, you do not need an agent platform from anyone, including strikeUp. A direct model call with retrieval and good examples will do it. The infrastructure question only becomes real when agents need to act inside your product, on your customers' data, within their permissions.

How do the two paths compare?

What does the buy path look like in practice?

You keep the interesting half. You decide what the agents do, which workflows they take over, how they behave inside your product and what your customers see. The layer underneath handles orchestration, memory, security, integration and analytics. See what is included for the full picture.

Most in-house builds stall at the copilot, because the jump from "a user asks for something" to "this runs on its own" is where the engineering gets hard. That is the part strikeUp, the agentic AI layer for SaaS, is built to hand you. Agents that run on a schedule, and agents triggered automatically by a change in your own database, are live in the platform, working to rules your customers set and inside permissions you define.

This is the pattern that shows up most often with B2B SaaS platforms and PE-backed roll-ups, where the pressure is to show AI in the product this quarter rather than next year.

The practical rule

Own the customer problem, the workflow design, the domain rules, the product experience, the data permissions, the definition of quality and the feedback your customers generate.

Build the infrastructure underneath only when doing so creates a proven advantage in quality, cost, speed or control, and only once you have evidence rather than intuition that it will.

Too early or too simple, use a model API directly. Proven use case without an AI platform team, buy the layer. AI-native at serious scale with a real data flywheel, start internalising selectively.

Interested in buying the infrastructure for your SaaS?

strikeUp provides exactly that. Get in touch and we will build a working demo on your SaaS. It takes less than 30 minutes. No commitment, no sales pitch. Just your product, with AI.

See your product with AI

Frequently asked questions

How long does it really take to build AI infrastructure in-house? Around two weeks for a prototype, six months or more for something you can sell. The difference is permissions, guardrails, evaluation and security review, none of which appear in the prototype.

What does it cost to build AI agent infrastructure in-house? Realistically £150,000 or more per year, covering two to three senior engineers for six months and permanent ownership afterwards. Buying the layer typically runs £25,000 to £75,000 per year depending on scope.

Do we need to hire ML engineers? To build, usually yes, or you accept a much longer timeline. To buy, no. The skills that matter are product and domain skills, which you already have.

We have already started building. Is that wasted? No. The prototype told you what your customers want an agent to do, which is the expensive knowledge. The plumbing underneath it is the replaceable part.

Is a copilot the same as an agent? Not quite. A copilot completes multi-step work, but a user has to ask it to. An agent goes further: it can run on a schedule, or start automatically when something changes in your product. The difference is what starts the work.

Does buying mean vendor lock-in? You hand over infrastructure, not product logic or your data model. The workflows, the interface and the customer relationship stay yours. Worth asking any vendor how model portability works before you sign, because agentic workflows raise switching costs whichever path you take.

What happens when the models change? On the buy path, the layer absorbs it. On the build path, your team re-tests prompts and re-plumbs integrations every time a model is deprecated.

When should we build instead of buy? When your AI performance is the main reason customers choose you, when you have a genuine labelled-data flywheel, when usage makes vendor economics material, or when you have constraints no vendor can meet. Most of those arrive after the AI is already working, not before.