Built-vs-Buy Analysis for AI Investments

In short

For most SMEs, the right answer to “build or buy AI?” is buy where good off-the-shelf exists, build where it doesn’t, glue them together with workflow automation. Wingenious produces a defensible built-vs-buy analysis per use case as part of the Feasibility Study: £3,950, 2–3 weeks.

The decision framework

For each candidate AI capability:

Factor	Favours BUY	Favours BUILD
Commodity capability (e.g. customer support)	✓
Differentiating capability		✓
Off-the-shelf exists + works	✓
Off-the-shelf is overpriced for your volume		✓
You need to control data/IP tightly		✓
You’ll iterate fast on the model		✓
You want it operational in weeks	✓

Most SMEs implement a hybrid: buy commodity layer, build differentiating layer, integrate via workflow automation.

Why the built-versus-buy question got harder in 2026

Two years ago the answer was almost always buy. Off-the-shelf SaaS had crossed the maturity point on most common AI use cases, vendor pricing was predictable, and custom development was slow and expensive. The build versus buy conversation had a default direction.

The picture in 2026 is more interesting. Two things changed. Vendor pricing has become substantially more aggressive at higher volumes, with consumption-based components that scale faster than SME revenue. At the same time, bespoke code via AI-assisted development tools (Claude Code, Cursor, similar) has collapsed the cost of building custom software from “always a six-figure number” to “sometimes a four-figure number for narrow scopes”. The default direction is no longer obvious.

The result is that the built-versus-buy question now requires real analysis on most non-trivial use cases. A decision that would have been “buy, obviously” in 2023 might land differently in 2026 once the three-year total cost of ownership is modelled honestly against the cost of a tightly-scoped custom build.

What the analysis actually examines

Five categories of input go into the recommendation. Each one is documented in the write-up with reasoning.

1. Capability fit. For each candidate off-the-shelf vendor, does the product actually do what the use case requires, or only the 80 percent of it that vendor marketing emphasises? The gap between “covers the use case” and “covers your specific shape of the use case” is where most procurement mistakes get made.
2. Total cost of ownership over three years. Not the headline licence price. The licence price plus the implementation cost plus the integration cost plus the volume-scaling cost plus the renewal escalation. Most SMEs only model year one when they buy; the analysis models years one to three.
3. Differentiation value. Does this capability sit at the heart of the SME’s competitive edge, or is it commodity infrastructure? Pricing engines for a quirky bespoke product line are differentiating. Customer support routing for standard ecommerce is not. Differentiation favours build; commodity favours buy.
4. Data and IP considerations. Where does the customer data sit? Does the vendor train on inputs? What is the exit cost if the relationship ends? Tight control requirements favour build; standard data flows favour buy.
5. Time to value. How quickly does the SME need the capability live? Off-the-shelf typically lands in weeks; bespoke development in months. Where the commercial window matters, time-to-value can dominate the decision.

The recommendation is then a written verdict per use case: buy, build, or hybrid, with reasoning, cost projection, and recommended next step.

The hybrid pattern that fits most SMEs

For roughly 70 percent of UK SME AI use cases, the right answer is neither pure buy nor pure build. It is hybrid: buy the commodity infrastructure, build a thin custom layer that captures the SME-specific logic, glue them together with workflow automation.

A typical hybrid shape looks like this.

• Buy the customer support platform (Gorgias, Zendesk, Tidio), the CRM (HubSpot, Salesforce, Pipedrive), the email tool (Klaviyo, Mailchimp), the document management system, the accounting tool.
• Build the sector-specific business logic that lives between these tools. The conflict-check workflow for a law firm. The supplier reconciliation logic for a manufacturer. The pricing model for a quirky product range.
• Glue the two together with Make.com, or bespoke code via Claude Code depending on the complexity. The glue layer is rarely more than 200 to 400 hours of work; the bought tools do the heavy lifting.

The hybrid shape captures most of the cost advantage of buy with most of the differentiation advantage of build. It also keeps the SME in a position to swap vendors when contracts come up for renewal, because the differentiating logic lives in the SME’s own layer rather than locked into a vendor product.

When pure build is the right answer

Three signals point clearly to a custom build rather than a vendor product.

• The use case is genuinely differentiating. Capability that other businesses do not have, and that materially affects the SME’s competitive position, deserves to be owned outright.
• The off-the-shelf cost is disproportionate. A vendor charging £30,000 per year for a capability the SME could build for £15,000 once and own forever is rarely the right answer.
• The data sensitivity is high. Cases where the SME cannot send certain data classes to external vendors, either for regulatory reasons or for commercial confidentiality, push the build inside the perimeter.

Pure builds in 2026 typically land between £9,950 (fixed-price Custom Build) and £30,000 to £60,000 for larger pieces. The build is delivered with source, documentation and IP assignment in the SME’s name; no royalties, no escrow conditions.

When pure buy is the right answer

Three signals point clearly to off-the-shelf rather than custom.

• The capability is commodity. Customer support routing, email automation, document scanning, transcription. These are well-served by vendors at SME scale; building them custom is rarely justified.
• Time-to-value is dominant. The capability is needed in weeks not months. Vendor products win on speed even where build would win on long-term cost.
• The SME does not want to own the ops burden. Self-hosted custom code requires monitoring, updating, security patching. Some SMEs have the appetite, many do not.

Buy decisions still benefit from a vendor shortlisting exercise to ensure the right vendor lands rather than the loudest one.

What can go wrong with each choice

Buy mistakes typically look like: vendor pricing scaling faster than the SME’s volume, contract auto-renewals that lock in unfavourable terms, vendor capability gaps that get filled with workarounds rather than addressed by the vendor, and exit costs that make leaving the vendor harder than expected.

Build mistakes typically look like: scope creep beyond the original brief, ongoing maintenance cost underestimated, vendor capability catching up and making the build redundant within 18 months, and key-person dependency where the only person who understands the code leaves.

The analysis surfaces both classes of risk and writes them down explicitly. The decision is the SME’s; the analysis just makes it defensible.

How the analysis sits inside the Feasibility Study

The built-versus-buy work runs across days four through ten of the Feasibility Study (£3,950, two to three weeks). The Study also covers ROI projection, vendor shortlisting, risk register and board-ready business case. The combined output is what a leadership team needs to commission the build with confidence, whichever direction the build goes.

For SMEs that want the built-versus-buy work standalone, it is available from £1,500 to £3,500 depending on the number of use cases in scope.

When to revisit the decision

A built-versus-buy verdict is good for around 12 months in a fast-moving market. Vendor pricing shifts, new entrants appear, open-source alternatives improve. Decisions made early in 2026 deserve a refresh in early 2027.

Fractional CAIO clients get this refresh as part of the standing engagement. Standalone Feasibility Study clients can commission a 12-month refresh at half the original fee.

How AI-assisted development changed the build cost equation

The single biggest shift in the built-versus-buy conversation between 2023 and 2026 is the cost of bespoke development. Tools like Claude Code, Cursor and similar AI-assisted development environments have collapsed the marginal cost of building narrow-scope custom software.

What used to require a four-person team for three months now sometimes lands with a one-person team in three weeks. The reduction is not uniform; complex multi-system integrations, large user interfaces and regulated workflows still take real engineering time. The bulk of the work an SME would commission, however, particularly the back-office workflow automation and the bespoke logic that lives between SaaS tools, is genuinely cheaper to build than it was.

The implication for the built-versus-buy decision is that the threshold at which build becomes the right answer has moved down. A use case that would have been “buy, obviously” in 2023 at a £15,000 build cost might now be a real conversation at a £6,000 build cost. The analysis takes the new cost reality into account explicitly.

What ownership of a custom build actually feels like

A common SME concern about custom builds: ongoing maintenance. The fear is that a custom build becomes a perpetual cost centre and a single-point-of-failure risk if the original developer leaves.

The Wingenious approach treats this directly. All custom code is delivered with source, documentation, deployment runbooks and a written IP assignment in the SME’s name. The build runs on the SME’s own infrastructure (Make.com, the SME’s own AWS or GCP account, the SME’s own server estate) rather than locked into a Wingenious account.

Maintenance over the first year is typically modest: occasional updates as upstream APIs change, occasional bug fixes, occasional capability extensions. Twelve months in, most custom builds need 5 to 15 hours of maintenance per year, which the SME’s internal team can usually absorb. Where the SME prefers external maintenance, the Fractional CAIO engagement covers it.

Single-point-of-failure risk is real but manageable. The mitigations: documentation written for someone other than the original developer, code structured for a reasonable engineer to extend, runbooks that cover the common failure modes. The build is built to be transferable rather than dependent on a specific person.

How the hybrid pattern lands across sectors

Three concrete examples of the hybrid pattern in different sector contexts.

A law firm hybrid: buy the practice management system (Clio or LEAP), buy the document automation tool (Lawyaw or HotDocs), build the conflict-check workflow that connects them with the firm’s specific risk rules, glue together with Make.com, or bespoke code via Claude Code. The bought tools cover the commodity work; the built layer captures the firm’s specific compliance logic.

An ecommerce hybrid: buy Shopify, buy Klaviyo, buy a customer support platform like Gorgias, build the bespoke pricing and recommendation logic specific to the catalogue, glue together with automation. The bought tools cover the operational commodity; the built layer is the differentiating intelligence.

A manufacturer hybrid: buy the ERP (NetSuite, Sage or Microsoft Business Central), buy the CRM, build the supplier reconciliation and quality-control workflows that capture the manufacturer’s specific operating model, glue together with automation. The bought tools cover the financial and customer infrastructure; the built layer is the operational specificity.

In each case, the split between bought and built reflects what is commodity versus what is differentiating for that business.

Related capabilities

Vendor shortlisting · AI use case identification · AI business case · AI ROI calculation

Related

Sectors where built-versus-buy analysis matters most: manufacturing, law firms.