The build vs buy software decision used to resolve itself. Building an internal tool meant engineers, a product manager, a designer, a security review and years of maintenance. Buying meant a subscription and a login. For most non-differentiating software, buying won by default.
AI-assisted development has compressed the build side of that equation. An operations lead with the right platform can now produce a working internal tool in a day or two, and a small team can scaffold a credible replacement for a narrow SaaS product in a week. The buy side — subscription pricing, integration work, customisation costs — has not moved nearly as far.
That has produced a genuine shift and a considerable amount of overstatement. This article separates the two, then gives you seven questions that will settle the decision for a specific tool in your own stack.
Table of Contents
- What does “build vs buy” mean in 2026?
- What the data actually says
- The part of the research nobody quotes
- The shadow IT problem underneath it
- The 7 questions that settle the decision
- When building is the right call
- When buying is still the right call
- The costs people forget
- A safer middle path
- FAQs
What does “build vs buy” mean in 2026?
Build vs buy is the decision between developing software internally and licensing an existing product. In 2026 the question has narrowed in a specific way: it is rarely about replacing core systems like your ERP or accounting platform, and almost always about the layer of internal tools around them — dashboards, approval workflows, data lookups, admin panels, reporting views and integrations between systems that do not talk to each other.
The reason is cost asymmetry. AI-assisted development reduced the cost of producing that middle layer by roughly an order of magnitude. It did not reduce the cost of producing regulated, high-availability, multi-tenant infrastructure by anything like as much.
So the honest version of the 2026 question is narrower than the headlines suggest: which parts of your stack are you renting out of habit rather than necessity?
What the data actually says
The most-cited evidence comes from Retool’s 2026 report, The Build vs. Buy Shift: How Vibe Coding and Shadow IT Have Reshaped Enterprise Software, published in February 2026 and based on a survey of 817 Retool customers and builders conducted in late 2025.
Its headline findings:
- 35% of teams had already replaced the functionality of at least one SaaS tool with a custom build
- 78% planned to build more custom internal tools during 2026
- 60% of builders had created tools, workflows or automations outside IT oversight in the previous year, with 25% doing so frequently
- 31% of those bypassing IT did so simply because they could build faster than IT could provision a tool
The report also carried a concrete example. Productivity platform ClickUp evaluated a range of AI vendors for its go-to-market operations, found none with the integrations it needed, and built six internal AI tools connected to Salesforce, Zendesk and Snowflake instead — reporting several hundred thousand dollars in saved headcount cost and roughly $200,000 a year cut from automation software spend.
TechyKnow note on sourcing: Retool sells the platform that makes this shift easier. The survey population was Retool’s own customers and builders — people already predisposed to build. That does not make the findings false, and independent coverage in the technology press treated them as credible directional evidence. But these are not neutral market-wide statistics, and any article presenting them as such is misleading you. We have cited them as what they are: strong evidence of a real trend, gathered from a self-selecting population by a company with a commercial interest in the answer.
The part of the research nobody quotes
Here is where the story gets more useful. Buried under the headline numbers, the same report describes how people are actually working — and it does not match the “anyone can replace SaaS now” framing.
Among respondents who had shipped software:
- 72% use AI to write discrete pieces of code that they then integrate into larger projects
- Only 31% are prompting their way to a complete application
- Only 8% use AI-generated code without any changes
- Just 44% test thoroughly before deploying anything
Read those four numbers together and a different picture emerges. The dominant pattern is not non-technical staff conjuring finished applications from prompts. It is people who already know how to build software using AI to go faster.
The 8% figure is the one that should reassure and worry you in equal measure. Reassure, because it means very little unreviewed AI code is reaching production. Worry, because it means the speed advantage is smaller than advertised once review time is counted — and because 56% of builders are not testing thoroughly before deployment.
The report’s own framing acknowledges the risk. Its authors warn that without governance the result could be a proliferation of cheap, one-off tools built for speed rather than quality — what OpenAI’s Sam Altman has described as a “fast fashion” era for software.
The shadow IT problem underneath it
The 60% shadow IT figure deserves more attention than the 35% replacement figure, because it describes a governance gap rather than a purchasing trend.
When people build tools outside IT oversight, several things stop happening automatically: access control review, data handling assessment, dependency scanning, security review and any record that the tool exists. The tool works. Nobody knows who owns it, what it connects to, or what happens when its creator leaves.
It is worth being fair about why this happens. The same research found that a substantial share of people going around IT did so because they could build faster than IT could provision — not out of recklessness. Shadow IT at this scale is better read as a demand signal about procurement speed than as a discipline problem.
That said, the risk is real and specific. An internal tool that queries production data through credentials pasted into a config file is a data-exposure incident waiting for a trigger, regardless of how useful it is.The scale of exposed credentials and unsecured endpoints already found in production systems shows how routine this failure is. If you are encouraging internal building, the security controls need to arrive at the same time as the permission — not eighteen months later.
Free frameworks exist for this. The NIST Secure Software Development Framework and the OWASP Top 10 both give you a starting checklist that does not require a dedicated security team to apply.
The 7 questions that settle the decision
Run any candidate tool through these before you cancel a subscription.
1. Is this tool generic, or does it encode something specific to how we work? Generic tools — a basic dashboard, an approval queue, a data lookup — are the strongest build candidates. Anything encoding industry-specific rules, regulatory logic or years of accumulated data is not.
2. What is the real total cost of the SaaS product? Subscription plus integration work plus customisation plus internal admin time plus the cost of working around its limitations. Most build-versus-buy comparisons fail because they compare a full build cost against only the invoice.
3. Who maintains this in eighteen months? Name the person. If you cannot, you are not building a tool, you are creating an orphan. This is the single most common reason internal builds fail.
4. What data does it touch, and what breaks if it leaks? Customer data, financial records and anything covered by GDPR raise the bar considerably. If the answer is “production customer data,” the build needs the same review a vendor would get.
5. Does it need to work when the person who built it is on holiday? Availability requirements are where prototypes and production systems diverge. A tool nobody can fix at 2am on a Sunday is a tool you have not finished building.
6. Are we replacing the product, or one feature of it? Replacing one feature of a suite rarely lets you cancel the subscription. It usually adds a system to maintain while keeping the cost you were trying to remove.
7. How will we know in six months whether this worked? Define the measure before you build: hours saved, subscription cost removed, errors reduced. Replacement without measurement is not a saving, it is a swap.
When building is the right call
Building genuinely makes sense when several of these hold at once:
- The tool is generic in function but specific in fit — no vendor’s version quite matches your workflow, and the gap costs real time
- You are paying for a suite to use one feature
- The tool needs to sit across systems that no single vendor connects well
- The functionality is competitively relevant — it is part of how you win, not part of how you administer
- You have a named owner and a maintenance plan
- The data involved is low-sensitivity or you have the controls to handle it properly
The ClickUp example fits this pattern precisely: an integration problem no vendor solved, an engineering-capable team, and a measurable target.
When buying is still the right call
The production bar has not moved, whatever the build tooling can now produce. Pernod Ricard’s Pierre Yves Calloc’h, quoted in the same report that celebrates the building wave, was direct about this — enterprise-grade technology scaling across thirty countries is a different problem from a working demo.
Keep buying when:
- The product handles compliance or regulatory obligations that are expensive to reproduce and dangerous to get wrong
- It carries accumulated data or network effects you cannot rebuild
- It requires 24/7 availability with a support obligation attached
- It sits in a security-critical path — authentication, payments, access management
- Nobody on your team wants to own it, which is usually the honest answer and worth respecting
- The vendor’s integration ecosystem is the actual product
The costs people forget
Build-versus-buy comparisons tend to be optimistic in predictable ways. The build side routinely omits:
| Hidden cost | Why it gets missed |
|---|---|
| Maintenance | Feels like zero at build time; becomes the dominant cost by year two |
| Security review | Skipped entirely when the tool is built outside IT |
| Dependency upgrades | Libraries age. Something breaks. Someone has to fix it |
| Documentation | Rarely written; makes handover expensive or impossible |
| Onboarding | Every new team member needs teaching on a tool with no help centre |
| Institutional risk | The builder leaves and the knowledge leaves with them |
| Re-subscription | The tool decays and you buy the SaaS product again, having paid twice |
That last one deserves emphasis. The failure mode for a poorly-planned build is not a broken tool. It is a tool that works well for a year, degrades quietly, and gets replaced by the subscription you cancelled — at a worse price, with migration costs on top.
A safer middle path
For most organisations the sensible answer is neither wholesale building nor defensive buying.
Start with one narrow, low-stakes tool. Pick something generic, low-sensitivity and genuinely annoying. Build it. Measure it against the criteria you set in question seven.
Bring governance forward, not backward. Decide access controls, data handling and code review expectations before people start building, not after an incident. The shadow IT numbers suggest the alternative is not “no building” but “building you cannot see.”
Give procurement a fast lane. If a third of people bypassing IT do so because building is faster than provisioning, the fix is partly a procurement problem. A lightweight approval route for low-risk tools removes most of the incentive to go around the process.
Keep a register. A simple list of internal tools, owners and data touched is the cheapest governance control available and the one most often missing.
The bottom line
The build vs buy software calculation genuinely changed in 2026, but not in the direction the loudest coverage suggests. The cost of building the middle layer of internal tooling collapsed. The cost of running production software did not.
What that rewards is discrimination, not enthusiasm. Build the generic things that fit your workflow badly and matter to how you operate. Keep buying the regulated, security-critical, always-on things. And decide who maintains it before you write the first prompt — because that question, more than any capability of the tooling, determines which side of the 35% you end up on.
FAQs
What is the build vs buy decision in software? It is the choice between developing software internally and licensing an existing product. In 2026 the question mostly applies to internal tools — dashboards, workflows, admin panels and integrations — rather than core systems.
Has AI made building software cheaper than buying it? For a specific category, yes. AI-assisted development substantially reduced the cost of building internal tooling. It did not reduce the cost of maintaining, securing and supporting software in production, which is where most of the long-term expense sits.
How many companies have replaced SaaS with custom software? Retool’s February 2026 report found 35% of the 817 builders it surveyed had replaced the functionality of at least one SaaS tool, and 78% planned to build more during 2026. Note that the survey population was Retool’s own customers, so it is directional evidence rather than a market-wide measurement.
Is vibe coding safe for production software? The evidence suggests it is mostly not being used that way. In the same research, only 31% of builders were prompting their way to complete applications and only 8% used AI-generated code without changes. Most were using AI for discrete pieces of code within larger projects. Treat AI-generated code as a first draft requiring review, testing and security assessment.
What is shadow IT and why does it matter here? Shadow IT is software built or adopted outside official IT oversight. It matters because tools created that way typically skip access control review, data handling assessment and security review — and often nobody records that the tool exists.
What is the most common reason internal builds fail? No named maintainer. Tools that work well at launch degrade without ownership, and organisations frequently end up re-purchasing the SaaS product they cancelled.
Should a small business build its own internal tools? Sometimes — for narrow, low-sensitivity, genuinely annoying problems where no product fits well. Small businesses are usually more exposed to the maintenance risk because there is less slack to absorb it, so start with one tool and measure the outcome before committing further.
