A McKinsey survey of 1,719 business leaders across 97 countries, fielded in mid-2026, found that 32 percent of organizations decided against buying a piece of software this year and built it themselves with AI coding agents instead. Among the firms getting the most measurable profit from AI, that figure was close to half. In tech specifically it was 41 percent.
That number spread through automation communities this week for an obvious reason. If a third of companies are cancelling software purchases, the software budget line that every small business quietly resents may finally be negotiable. The average small company in the US or the UK now pays for somewhere between 20 and 80 SaaS subscriptions, and a meaningful share of them exist to solve one narrow problem that nobody wants to solve by hand.
But the same week, a no-code forum thread with over 40 replies carried the opposite headline: most AI-built tools feel amazing until you try to build something real. Both things are true. The interesting question is not whether to build. It is knowing which of your subscriptions is a genuine build candidate and which one will quietly cost you more than the invoice you cancelled.
Three things changed at roughly the same time. Coding agents can now produce a working internal tool from a description rather than a spec. Workflow platforms like n8n, Make, and Zapier removed the need to write integration plumbing by hand. And the models that handle the messy parts, reading an email, classifying an invoice, drafting a reply, are now cheap enough that per-transaction AI costs fractions of a cent rather than the price of a human minute.
What used to be a 12 week project with a contractor is often a two week project now. That shift is real and it is why the McKinsey number is not a fluke.
What did not change is everything after launch. Upstream APIs still drift. Credentials still expire. Somebody still has to notice when a workflow silently stops firing at 3am. The build got cheaper. The run did not.
Before you cancel anything, run the candidate through these four questions. If you get a clean pass on all four, build. If you fail any one of them, buy.
A utility is something every business in your category needs in roughly the same shape. Accounting. Payroll. Email hosting. Card payments. You gain nothing by owning a slightly different version of it, and you inherit a permanent maintenance obligation the moment you do.
A differentiator is a process that is specific to how you actually make money. The way a UK letting agency routes viewing requests. The way a Chicago HVAC contractor triages emergency calls after hours. The way a Berlin agency assembles a client report from six tools. No vendor builds for that exact shape, which is why you are currently paying for three tools and gluing them together with copy and paste.
Build the differentiator. Buy the utility. This one rule eliminates most bad decisions.
Compare honestly. On the buy side: seats multiplied by price multiplied by 12, plus onboarding, plus the annual price increase that arrives every renewal.
On the build side: the build itself, plus hosting (30 to 80 USD per month for a self-hosted n8n instance that will carry a dozen workflows), plus model costs, plus monitoring, plus a maintenance reserve. I use 20 to 30 percent of the original build cost per year for maintenance. That is not padding. It is the number that makes the comparison truthful.
A concrete example. A 12 person US service business paying 39 USD per seat per month for a field service add-on is spending about 5,600 USD a year. A custom quote and dispatch workflow to replace it might cost 4,000 to 7,000 USD to build and roughly 1,800 USD a year to run. That pays back somewhere in year two, not year one. Worth doing if the tool is a differentiator. Not worth doing if you just dislike the vendor.
This is the question that kills most build projects six months in, and it came up repeatedly in automation threads this week. One builder described a single shared API key breaking five workflows at once. Another argued that the missing status in every automation dashboard is not "failed" but "unknown", because a workflow that quietly stops triggering looks identical to a workflow with nothing to do.
When you buy, the vendor owns uptime. When you build, you do. That is fine if there is a named person or a retained engineer who will get the alert and act on it. It is not fine if the answer is "the person who built it will probably have a look". Every abandoned internal tool started with that sentence.
If the tool stores payment card data, health records, or personally identifiable data at scale, or if it produces numbers that a tax authority or auditor will rely on, buy it. GDPR in the EU and UK, and the state privacy laws now live across most of the US, all put the compliance burden on you regardless of who wrote the code. Vendors amortise that work across thousands of customers. You cannot.
You can still build the workflow that moves data between compliant systems. That is a very different risk profile from building the system of record itself.
In practice the wins cluster in the same handful of places. These are the ones I see repeatedly across client work and in the automation communities:
Notice what is missing. Nobody is rebuilding their accounting system, their payroll, or their payment processor. The wins are in the seams between tools, which is exactly where vendors do not compete.
If you decide to build, do not cancel the subscription on day one. Run both in parallel for a full billing cycle and compare outputs. That single discipline catches the majority of problems while they are still cheap.
Three more things worth doing before go-live. First, give every workflow its own credentials rather than one shared key, so a rotation or a revocation breaks one thing instead of five. Second, build a dry run mode that shows you the messages the system would send, not just the records it would change, because a wrong email to a customer is much more expensive than a wrong row in a table. Third, add a heartbeat check that alerts you when a workflow has not run in its expected window, so "unknown" never masquerades as "fine".
None of that is exciting. All of it is the difference between an internal tool that lasts three years and one that gets quietly abandoned in March.
Gideon Wafula builds custom AI automation systems, n8n, WhatsApp, Voice AI, and more.
See Services →The build vs buy line moved in 2026, and it moved in a direction that favours small businesses for the first time in a long while. A workflow that would have needed a development team two years ago is now a two week engagement. That is worth acting on.
But the McKinsey figure describes companies that decided not to buy. It does not describe how many of those builds are still running well in 18 months. Treat every build as a commitment to run something, not a one-time saving, and the decision becomes much easier to get right.
If you want a second opinion on a specific subscription, that is the kind of work Gideon Wafula, AI Automation Engineer does before any build starts. You can see the full range of AI automation services, or start by listing your five most expensive tools and asking which of them are utilities.