Build vs Buy Just Got a Third Option, and Most SMEs Are Picking the Wrong One
For twenty years the advice to small businesses was simple: buy, don’t build. Custom software was for companies with engineering departments. Everyone else subscribed to SaaS and got on with their day.
That advice is quietly breaking down. Retool’s 2026 build vs buy report found that 35 percent of teams have already replaced at least one purchased tool with something custom-built, and 78 percent expect to build more this year. AI-assisted development is the reason. A workflow tool that would have cost six months of developer time in 2022 can now be a two-week project.
At the same time, the case for “just buy it” has never looked worse on paper. Zylo’s license data shows companies using barely half the SaaS licenses they pay for, and Gartner puts average SaaS overspend around 25 percent. Small businesses now run dozens, sometimes over a hundred, subscriptions. Most owners could not list them from memory.
So building is cheaper than ever and buying is messier than ever. Time to build everything? Not quite.
The sprawl just changes shape
SaaS sprawl has a well-known cure: audit the stack, cut the unused seats, consolidate overlapping tools. Painful but understood.
Homegrown sprawl is worse, and it is the trap hiding inside the AI building boom. Every internal tool you build is software you now operate. It needs someone to fix it when a browser update breaks it, patch it when a dependency has a security hole, and explain it when the person who built it leaves. A SaaS subscription you can cancel. A half-documented internal app that the invoicing process depends on, you cannot.
We have seen versions of this before. The spreadsheet that became load-bearing. The Access database nobody dares touch. AI-generated internal tools are the same story with faster authoring, which means the pile grows faster too.
A decision rule that fits a small company
The real choice in 2026 is not build versus buy. It is build, buy, or extend, and for most SMEs the order of preference should be exactly backwards from how exciting each option sounds.
Extend first. If a system you already run (your ERP, your accounting platform, your CRM) can absorb the workflow through configuration, an API, or a small module, that is almost always the cheapest option over five years, because the vendor keeps carrying the maintenance load. This is most of what we do with ERP clients: the answer to “we need a tool for X” is very often a small extension to the system that already holds the data.
Buy second, but buy less. Before adding a subscription, check what your current stack already includes. The fastest way to cut software spend is usually not a cheaper tool, it is discovering you already own the capability twice.
Build last, and only what differentiates you. If a workflow is genuinely specific to how you win business, and no vendor does it well, build it. But budget for ownership, not just creation. A useful rule: if nobody on your team can name who maintains it in year two, do not build it.
The question that sorts it out
For any new software need, ask: will this thing still need to work in three years, and who will make sure it does?
If the answer is a vendor, buy or extend. If the answer is you, build only if the workflow is worth owning. If the answer is “nobody, hopefully it just keeps running,” you are about to create the sprawl you were trying to escape.
Deciding this well takes an honest look at the systems you already have. That is exactly what our assessment is for, and if the workflow touches your ERP, start with why delivery, not technology, is where these projects fail.