In-house AI agents beat SaaS past this point

In classic IT procurement there was a reliable rule of thumb: buy what's commodity. Build what differentiates your business. CRM, accounting, ticketing: buy. Pricing logic, inventory control, your core product: build, if it's what sets you apart from the competition. That rule held because software development was expensive and slow. Building your own CRM would have taken years and still ended up worse than an established off-the-shelf product.

For AI agents, the underlying assumption no longer holds. An agent that checks invoices, answers support requests, or prepares quotes can be built with a language model, a handful of tools and a few weeks of development time, if the data is accessible. The most expensive part of classic software development, coding the logic from scratch, largely disappears. What's left is integration work: access to the right systems, clean tools for the agent, a sense of where it can decide on its own and where it can't.

Most SaaS products that call themselves an AI agent are selling three things: a pre-built prompt, an interface and a contract with a language model provider. These vendors rent the actual intelligence themselves from OpenAI, Anthropic or Google and add a margin on top. Their contribution is the finishing work: prompt engineering for the use case, a handful of standard integrations, a user interface.

That's a legitimate business model, but it's worth seeing through. You're not paying for unique technology. You're paying for the shortcut of not doing that finishing work yourself. For a generic use case that ten thousand other companies have too, that's a fair deal. For a use case tightly woven into your own data and processes, you're paying for a customization that rarely fits as well as one you built yourself.

A simple test helps here: ask the vendor exactly what happens if you export your data and cancel the contract. If a working system remains that you can keep running yourself, the contract was a shortcut. If nothing remains, the contract was a dependency sold as a product.

Buy when three things line up. First: the use case is commodity, such as email drafts, meeting summaries and generic research. Second: the vendor has a genuine data advantage you can't replicate, such as a provider with decades of curated domain databases. Third: you have little internal engineering capacity, and time to first result matters more than control over the solution.

In these cases, building it yourself is a waste of time. You'd be building a weaker version of something that already exists, and the actual job (putting AI to productive use) would be needlessly delayed.

Another, often-overlooked signal for buy is how fast the use case changes. If the requirements for a function (spelling, translation, or general research, say) evolve quickly with the general state of the art, you benefit from a specialized vendor tracking that evolution for you. With a self-built system you'd have to maintain that yourself, for a use case that makes no strategic difference anyway.

Build when the workflow itself is part of your competitive advantage: pricing logic that ties market data to internal margin rules; a customer service agent with access to your full product and contract history instead of a generic knowledge base; a quality check that knows your specific manufacturing tolerances. The value here lies in the combination of model, your data and your process logic, not in the language model alone. Nobody can sell you that, because nobody but you owns it.

Building also pays off past a certain volume. Agent SaaS is almost always billed per seat, per request, or per document processed. At low usage that's cheap. Past a certain volume, ongoing license costs exceed what a self-built agent on top of a language model API would cost, given how low the marginal cost per request is.

The third reason is governance. When an agent makes decisions with legal or financial weight, the EU AI Act and usually your own compliance function require traceability: what data did the agent see, what rule did it apply, who can audit that. You can build that traceability into a system you own. You can't build it into someone else's SaaS black box.

Comparing license fee against one-time development cost is incomplete, in both directions. SaaS looks cheap because costs scale linearly with usage and rarely show up as a single large bill. Over two to three years and growing volume, that often flips.

Conversely, the effort for build is routinely underestimated in the upkeep phase. Language models change, prompts drift, third-party interfaces break. A self-built agent needs ongoing upkeep: monitoring, tuning, regression testing, just like any other production software. Choose build without budgeting for that operating cost, and you've only done half the math. Budget for it, and you typically end up cheaper than the SaaS contract would be after two years.

A clean calculation therefore has three line items, not two: one-time development cost, ongoing operating cost for maintenance and monitoring, and the opportunity cost of control: what it's worth not to make your pricing model and roadmap dependent on an external vendor. That third line item never shows up in a SaaS sales deck, but it's often the one that matters most for the actual decision.

In technical due diligences, build-or-buy comes up regularly from the other side: as a risk in the portfolio, not as an open decision. A portfolio company has tangled itself into a bundle of specialized agent-SaaS contracts, each with its own data export, its own pricing logic, its own notice period. No single contract is expensive. Together they tie up budget that would have covered an integrated in-house approach, and they create dependencies that show up as a risk in exit diligence, because nobody in the company can explain the logic behind the agent's decisions.

The reverse situation comes up just as often: a company built in-house early, but without the operating discipline that production software needs. The agent looked convincing in a demo, but never ran with real volume, real error cases and an accountable owner for ongoing operations. For an investment committee that's hard to assess: is this a working system or a well-marketed prototype? That uncertainty itself is already a valuation discount.

The most robust solutions we build in client projects are rarely pure build. They buy the infrastructure (a language model via API, an automation platform like n8n for orchestration, standard monitoring tools) and build the business-specific logic themselves: what data the agent sees, what steps it's allowed to take, when a human steps in. That keeps development time short without making you dependent on an agent SaaS whose pricing model and decision logic you don't control.

This split is also why build means something different today than it did a few years ago. You're not building AI. You're building the connection between a rented AI and your business. That's a much smaller and more manageable task than it sounds.

In the end, build-or-buy isn't a one-time, company-wide decision. It's a question per use case that you should keep re-asking. A company can buy a standard solution for scheduling and run its own agent for quote preparation, both at once, both right, if the reasoning holds up case by case. It only becomes a problem when the decision gets made on gut feel or by whoever made the loudest sales call, instead of on the criteria that actually matter: how company-specific the workflow is, how high the volume is, how much traceability the decision needs, and who carries the solution in operations afterward.

We have no interest in turning every use case into a build project. Honest advice to use a SaaS solution more often saves you money and time than a sales pitch for a custom system would. The use case should make the decision, not the vendor in the room.