McKinsey Says a Third of Companies Skipped Buying Software This Year. Here's What That Number Actually Means for a 5-Person Shop.

Every small shop has a version of this line item: $49 a month for the scheduling app, $79 for the client portal, $30 for the invoicing tool, $19 for the thing that syncs inventory between two platforms. None of it is expensive on its own. All of it together is a second rent payment for software that mostly reformats data you already have.

McKinsey just put a number on how many organizations are deciding they don’t need to pay it anymore — and the number is bigger than a lot of people expected.

What McKinsey actually found

McKinsey’s State of AI 2026 survey — 1,719 respondents across 97 countries, fielded May 4 to June 8, 2026, published August 25, 2026 — found that 32% of organizations have decided against buying off-the-shelf software, opting instead to build their own solution using agentic coding tools (McKinsey, “The State of AI: Global Survey 2026”).

That number isn’t evenly spread. By sector: technology leads at 41%, healthcare payers and providers at 39%, professional services and energy at 38% (The Register, August 25, 2026). And it’s sharpest among what McKinsey calls “high performers” — the 6% of respondents who attribute at least 5% of their EBIT to AI. Nearly half of that group skipped a software purchase in favor of building, compared to 31% of everyone else (Fortune, September 2, 2026).

Here’s the framing everyone’s using this week: build vs. buy just flipped for a third of the market.

Here’s the framing almost nobody’s using, and the one that actually matters if you run a five-person shop: the same survey shows small organizations are not the ones driving this.

The stat inside the stat that nobody’s leading with

Buried past the headline number, Fortune’s reporting on the same survey includes this: large organizations (over $1 billion in revenue) scaling AI agents enterprise-wide rose from 27% to 40% year over year. Smaller organizations stayed flat at 22% (Fortune, September 2, 2026).

Read those two numbers side by side. The build-vs-buy shift making headlines is real, but it’s disproportionately an enterprise story — companies with dedicated engineering teams pointing agentic coding tools at internal tooling they’d otherwise have bought from a vendor. The small-company number for agent scaling didn’t move at all this year.

That’s not a reason to ignore the trend. It’s a reason to be honest about what it means for you specifically: the tools exist, the case studies are mostly enterprise, and the gap between “this is possible” and “this is normal at your size” is exactly where the opportunity is — and also exactly where the McKinsey number stops being directly applicable and you have to translate it yourself.

This is the same nuance covered in why AI doesn’t level the playing field: these tools are a skill multiplier, not an equalizer. A five-person shop with one person who can actually direct a coding agent competently will build real things. A five-person shop waiting for the tools to make it easy for anyone will stay at 22% with everyone else.

Why the small-business number is stuck, mechanically

It’s worth being specific about why 22% hasn’t moved, because “small businesses are slower to adopt tech” is too generic to be useful. The actual mechanism is capacity, not willingness:

• Enterprises scaling agents have a platform team whose whole job is evaluating, sandboxing, and rolling out new tooling. A five-person shop’s “platform team” is whoever’s fastest at closing at night.
• The failure mode is asymmetric. If an enterprise’s internal build has a bug, there’s a team to fix it during business hours and a rollback plan. If your shop’s build breaks on a Saturday, it’s you, at home, instead of doing anything else.
• Evaluation itself costs time you don’t have. Reading McKinsey’s report, figuring out which of your SaaS subscriptions is a good build candidate, and actually testing an agent’s output against your real workflow is a project, not a checkbox — and it competes directly with the work that pays the bills this week.

None of that means the tools don’t work at small scale. It means the barrier isn’t capability anymore — it’s that nobody’s built the small-shop version of the enterprise playbook yet. That’s the gap this section of the site exists to close.

The scaling gap is bigger than small vs. large

Even inside the enterprise number getting all the headlines, the same McKinsey survey shows scaling is thin everywhere. Only 23% of respondents overall report their organization is scaling an agentic AI system anywhere in the enterprise — and even within that group, no more than 10% say agents are scaling in any single business function. Security and risk concerns, not regulation or a lack of use cases, are the top-cited barrier to fully scaling agentic AI, ahead of both technical limitations and regulatory uncertainty (McKinsey, “The State of AI: Global Survey 2026”).

Translate that down: “40% of large orgs scaling AI agents enterprise-wide” sounds like agentic AI is already normal furniture at big companies. What it actually means is 40% of large companies have gotten agentic AI to real production status in at least one department — usually one, not all of them, and usually the department with a platform team and a security review process already in place. The other 60% of large companies, with all their engineering headcount, haven’t cleared that bar either. A five-person shop stuck at “we haven’t scaled anything yet” isn’t meaningfully behind a random large company at that size cutoff — it’s behind the specific subset of large companies with dedicated agent-ops capacity, which was always going to be a thin slice regardless of company size.

That reframe matters for the anxiety this stat tends to produce. The honest takeaway isn’t “everyone big is already doing this and you’re behind.” It’s “almost nobody has actually operationalized this yet, at any size, and the barrier respondents themselves name most often — security and risk confidence, not lack of interest — is exactly the barrier a five-person shop can address more cheaply than a five-thousand-person one, because you have fewer systems to secure and a shorter chain of people who need to sign off before something ships.”

Translating the enterprise stat to shop scale

McKinsey’s “build instead of buy” mostly means a company with an internal engineering team decided not to license a $200,000/year enterprise tool and built an internal equivalent instead. That’s not your situation. But the underlying mechanism — a general-purpose coding agent can now produce a working, narrow-scope internal tool faster than procurement can evaluate a vendor — scales down fine. It just scales down to smaller dollar amounts and smaller tools.

Here’s what that actually looks like against the recurring SaaS bills a small operation typically carries:

Category	Typical monthly SaaS cost	What building it yourself with an agent looks like	Realistic build time (competent operator + agent)
Employee scheduling	$29–$99/mo	Google Sheets with validation, auto hour/labor-cost calc, overtime flags	A weekend — see the full build
Client portal	$49–$150/mo	Simple auth + file-share + status page on a small hosting plan	1–2 weeks part-time
Inventory sync across channels	$40–$120/mo	Scripted sync job against each platform’s API, scheduled	1–3 weeks, ongoing maintenance
Invoicing / basic billing	$15–$50/mo	Template-driven doc generation + a simple tracking sheet	A weekend to a week
Code review / PR management for a small dev team	$20–$40/seat/mo	Workflow built around agent-assisted review — see the stacked-PR piece	Days, if you’re already running agents

None of these numbers are from McKinsey — they’re the site’s own estimates based on typical small-business SaaS pricing and the build-alongs already published here. The point isn’t the exact dollar figures. It’s that the pattern McKinsey documented at enterprise scale — “we could build this ourselves for less than we’d pay to license it” — is the same pattern that’s been quietly true for small shops for a while, and agentic coding tools just made the build side of that comparison faster and more accessible to someone who isn’t a professional developer.

Signals it’s actually a build, vs. signals it’s actually a buy

Signal	Leans build	Leans buy
How much of the tool do you actually use?	Under 30% of the features	Most of what you’re paying for
Consequence of a bug for a day	Annoying, internal-only	Customer-facing, financial, or regulated
Who maintains it after launch	Someone named, with hours budgeted	Nobody has time, honestly
How often does it need to change	Rarely — stable internal process	Frequently — you’d be rebuilding constantly
Is there a compliance requirement attached	No	Yes (payments, health data, tax)

If a tool scores “build” on most rows, it’s a legitimate candidate. If it’s split, that’s your sign to run the one-week test below rather than commit either way on instinct.

The honest “when not to build it yourself” list

This is the section McKinsey’s survey doesn’t cover, because it’s not an enterprise question — it’s a liability question, and small shops carry it differently than a company with a legal department.

Don’t build it yourself for:

• Payroll and tax withholding. The cost of getting this wrong is penalties, not an annoyed customer. Buy the compliance, every time.
• Payment processing. PCI compliance is not a weekend project, and the liability if you roll your own and it leaks card data is not comparable to any SaaS fee you were trying to save.
• Anything where a mistake creates legal exposure with a customer — contracts, terms of service, anything that touches health or financial data you’re required to protect under a specific regulation.
• Anything you don’t have anyone on the team who can actually maintain after the agent wrote it. An agent can produce working code today. It can’t be the person who gets paged when it breaks at 11pm on a Saturday. If nobody on your team can read and fix what got built, you haven’t reduced a dependency — you’ve replaced a vendor’s support line with silence.

This lines up with the deeper argument in the accountability premium piece: the value of “a named human reviewed this and is on the hook for it” doesn’t go away when the thing was built by an agent. If anything it gets more valuable, because now there’s no vendor to call.

Do consider building it yourself for:

• Anything that’s currently a spreadsheet pretending to be a system (the exact argument in the spreadsheet piece) — scheduling, simple tracking, internal dashboards.
• Anything where the SaaS tool you’re paying for does 20% of what you need and you’re working around the other 80% manually anyway.
• Anything narrow, internal-only, and low-consequence if it has a bug for a day.

The part where “we built it” doesn’t automatically mean “it worked”

The uncomfortable middle of the McKinsey report is this: only 37% of all respondents say AI is having a measurable impact on EBIT — unchanged from a year ago — even as agent adoption and the build-vs-buy shift both climbed (The Register, August 25, 2026). Eighty percent of individuals report feeling more productive. The organizational bottom line mostly hasn’t moved.

McKinsey’s own explanation, drawn from what separates the 6% “high performers” from everyone else, is workflow redesign, not tool adoption: nearly three-quarters of high performers say they fundamentally redesigned how the work gets done around the new tools, up from 55% a year ago, versus companies that just bolted an agent onto an unchanged process (Fortune, September 2, 2026).

Translated to shop scale: replacing your $79/month client portal with an agent-built equivalent doesn’t save you anything if you still run the underlying process the same way and now also spend Saturday afternoons maintaining code. The saving shows up when you use the build to also fix the actual workflow problem — the one your team has been quietly working around for two years because the SaaS tool never quite fit it.

This is also why the token-cost side of this matters more than people admit. Twenty percent of respondents in the same survey cite AI-related operating costs, including token spend, as a constraint on scaling further. If you’re going to build instead of buy, track what the agent actually costs you the same way you’d track a subscription — because “free because we built it ourselves” is rarely literally free once you count the tokens and the maintenance hours.

A worked example: the scheduling tool, week by week

Take the first row in the table above — employee scheduling — since it’s the most commonly-cited candidate. A real five-person retail shop swapping a $59/month scheduling app for an agent-built spreadsheet system looks something like this:

Day 1–2: You describe the actual rules to the agent — shift patterns, who’s full-time vs. part-time, your state’s overtime threshold, the fact that Sunday shifts pay a $2/hour differential. The agent produces a working spreadsheet with formulas for hours, labor cost, and overtime flags in a few hours, not days. It looks done.

Day 3: It isn’t done. Someone works a split shift — four hours in the morning, three at night — and the overtime formula silently miscounts it as two separate shifts instead of seven hours toward the weekly total. This is the normal shape of a first-pass agent build: it handles the cases you described clearly and misses the one you didn’t think to mention because it’s obvious to you and invisible to the agent.

Day 4: You catch it because you spot-check the sheet against what you’d have calculated by hand for one real employee’s actual week — not because the agent flagged it. That’s the pattern worth remembering: agent output looks confident whether it’s right or not, and the only reliable check is comparing it against a case you already know the right answer to.

Day 5: Fixed, re-tested against three more real employee-weeks, including one with overtime and one with the Sunday differential. This is the point where it’s actually ready to run in parallel with whatever you were using before — not before.

Total time: a real week, not a weekend, once you count the case that broke on day 3. That’s the honest version of “a weekend” from the earlier table — achievable, but only if you budget the day for finding the edge case your first description left out. The tools didn’t lie about being fast. They just don’t tell you up front which day is the one where you find out what you forgot to mention.

A one-week test before you cancel anything

Before you cancel a SaaS subscription because “an agent can build that,” run this instead of committing outright:

1. Pick the one tool that annoys you most — the one where you’re already paying for 20% usage and working around the rest.
2. Time-box a build to one week, using whatever coding agent you already have access to, scoped to the actual narrow thing you need (not a full clone of the vendor’s feature set).
3. Run it in parallel with the SaaS tool for two more weeks, not instead of it, so a bug doesn’t cost you a real customer interaction while you’re validating.
4. Name who owns it. If nobody can answer “who fixes this when it breaks,” that’s your answer regardless of how well the build went.
5. Only then cancel the subscription — and only for the specific tool you tested, not everything on the list at once.

That’s the small-shop version of what McKinsey’s high performers are doing at enterprise scale: redesigning the workflow deliberately instead of just swapping the tool underneath an unchanged process.

When this doesn’t apply to you at all

If your team is genuinely one or two people with no spare capacity to review, test, or maintain anything an agent produces, the SaaS subscription is still probably the right call — not because building is impossible, but because the ongoing maintenance cost lands entirely on people who don’t have the hours. McKinsey’s own data backs this up sideways: small organizations are flat at 22% agent scaling for a reason, and it isn’t that the tools don’t work. It’s that redesigning a workflow takes time most small teams don’t have slack for during a normal week. Building it yourself is a good trade when it replaces recurring cost with a bounded one-time investment. It’s a bad trade when it replaces a predictable bill with an unpredictable, unowned maintenance burden.

Quick answers

Is the “32% skipped buying software” stat relevant to a small business? The mechanism is relevant; the number itself isn’t. McKinsey’s 32% is driven heavily by enterprises with dedicated engineering teams. The same survey shows small organizations flat at 22% on agent scaling — the tools work, but most small teams haven’t had the bandwidth to build the internal playbook yet.

Should I cancel my SaaS subscriptions and build everything myself? No — run the one-week parallel test on one tool at a time, and keep the categories in the “don’t build it yourself” list (payroll, payments, anything regulated) on vendor tools regardless of what an agent can technically produce.

Why hasn’t AI shown up in company profits if adoption is this high? McKinsey’s own data: only 37% of respondents report a measurable EBIT impact, unchanged year over year, even as adoption climbs. The gap is workflow redesign — high performers restructured how work happens; most companies just added a tool to an unchanged process.

What’s the biggest risk in building instead of buying? Not the initial build — the unowned maintenance afterward. An agent can produce working code quickly. It can’t be the person who fixes it when it breaks and nobody on your team can read what was written.

Sources

All figures accessed September 5, 2026.

• McKinsey State of AI 2026 survey methodology, build-vs-buy statistic, sector breakdown — McKinsey, “The State of AI: Global Survey 2026,” published August 25, 2026
• EBIT impact flat at 37%, survey respondent count and sector figures — The Register, “McKinsey says enterprise AI is finally ‘on the road to ROI,’” August 25, 2026
• High-performer workflow redesign figures, small-vs-large agent scaling gap (22% vs. 40%), individual productivity stat — Fortune, September 2, 2026