Take a 60-person SaaS business. The founder wants to understand which AI tools the team should be using and, in the same conversation, whether the product roadmap should include a machine-learning recommendation feature. Both questions land in the same meeting, on the same budget line, as though they are one decision.
They are not. Treating them as one is how engineering ends up spending a quarter building an internal Slack summariser that a vendor tool would have covered in a few days of setup. The two decisions need different criteria, different owners, and sometimes very different answers.
What makes the build-or-buy question different in a SaaS business?
In almost any owner-managed business, build-versus-buy is a procurement call about internal tools. A SaaS company faces that same call plus a second one: whether to build AI capabilities into the product it sells. Every other sector has one question. A SaaS business has two, running at the same time, with different criteria and different failure modes if the answers are wrong.
The first decision is operational. Should the firm buy a tool for its support queue, its pipeline analysis, its internal knowledge base, its marketing workflow? This is the same software evaluation every business runs. The criteria are familiar, and the evidence on what works is fairly clear.
The second decision is different in kind. Should the firm build AI features into the product its customers pay for? A law firm does not face this question, nor does a recruitment agency. A SaaS company does, and it is the decision that genuinely shapes what the business can become.
The confusion starts when both questions land in the same conversation, and engineering is asked to evaluate both.
Why does mixing the two decisions drain engineering capacity?
When operational and product AI share a single budget conversation, engineering gets drawn into evaluating tools it should never own. Vendor-led deployments succeed at roughly twice the rate of internal builds for standard operational work, because the vendor carries R&D and support costs that a mid-sized team cannot match. Every sprint spent on internal tooling is a sprint diverted from the product.
AI implementation research consistently finds that vendor-led projects succeed at around 67 per cent for operational deployments, against roughly 33 per cent for internal builds, a gap attributed to MIT research on enterprise AI initiatives. The reasons hold up on examination. Vendors have spent years on the specific problem, they carry the iteration cost, and they support the tool continuously. A 60-person SaaS team building its own revenue forecasting tool is competing against a specialist whose entire business depends on getting that one thing right.
There is also a subtler cost. When engineering takes on internal tooling, the work gets treated as a product build, with requirements gathering, sprint allocation, and testing cycles. The firm ends up half-building something it should have bought, and the partially-built version is both worse than the vendor solution and more expensive to maintain long term.
Where does bought AI belong in a SaaS operation?
Operational AI in a SaaS business covers the work that sits outside the product itself, including support queue management, pipeline and revenue analysis, internal knowledge retrieval, marketing content, and finance automation. A firm’s competitive edge is not in how it processes expense reports. Vendor tools handle these reliably, and McKinsey’s data shows the tech sector passed 90 per cent AI adoption by buying standardised operational tooling rather than building it.
Specialist vendors have been refining these tools against real usage at scale for years. The SaaS firm buying a customer support AI is making the same rational call as the law firm buying contract review software. The vendor has already solved the problem better than an in-house team could in the available time, and maintains the solution continuously as requirements evolve.
The McKinsey data is worth sitting with for SaaS businesses specifically. The tech sector leads every other industry in AI adoption, and the firms driving that number are not building their CRM integrations from scratch. They are buying standardised tools for the work that any firm does and directing engineering capacity towards the work that sets them apart.
The useful test before buying anything is to ask whether the problem is specific to the firm’s product or common across the business category. If it is common across the category, a vendor has almost certainly already built the better solution.
When should a SaaS firm build AI into its product?
Building makes sense on the product side when the AI capability is the competitive position, not a support layer. A SaaS firm already has an engineering team that built the product and understands the technical architecture. The question is whether the AI feature is distinctive enough that an off-the-shelf tool would produce something generic where a bespoke build would produce something that genuinely differentiates the product for customers.
The distinction to draw is between a feature that is the product and a feature that supports the product. If a SaaS firm is building a personalisation engine that is the primary reason customers choose it over alternatives, that belongs in the engineering roadmap. If the firm is adding AI summarisation to a meeting notes feature and several vendors already do it reliably, the answer is to buy or integrate.
The 67 per cent to 33 per cent success split applies to operational deployments, not to product development work. On the product side, the decision reverts to the standard make-or-buy calculation in software: can the engineering team build this better than a vendor provides it, given that they know the architecture and carry the product context no vendor can fully replicate?
That answer will sometimes be no. A SaaS firm in its early stages with a small engineering team should be buying nearly everything. A 60-person firm with a dedicated product function and a genuine AI-led differentiation thesis has a more credible case for building on the product side.
What to put in place before the budget is approved
The practical fix is two separate decision processes with separate owners. Operational AI decisions sit with whoever manages internal systems; product AI decisions sit with product and engineering leadership. A single combined budget line forces the wrong person to evaluate the wrong type of decision, and sets up a competition between internal efficiency and product advancement that does not need to exist.
Four questions are worth asking before any AI spend is approved. Is this for the operation or for the product? If operational, has a vendor option been properly evaluated by the person who will actually use it, not just the engineering team? If it is for the product, has the engineering team confirmed the feature is distinctive enough to justify the build? And who owns the outcome six months after launch?
The delegate’s role in this is to be the person who insists the two questions are kept separate. Founders often want to combine them because combining feels efficient. The outcome tends to be operational tools that engineering builds and nobody maintains, and product features bought from vendors who cannot match what the team could have built with that same capacity directed at the right problem.
Sustained AI adoption in the tech sector reflects, in part, a consistent discipline about which capabilities to own and which to buy. Getting that separation right in a SaaS business is a more complicated call than it is for other owner-managed firms, because both questions are real and both deserve a proper answer. The mistake is assuming they deserve the same one.
