McKinsey Says 32% Now Build Software Instead of Buying. Should You?

McKinsey published its State of AI 2026 survey this week. One number is getting all the attention: 32% of the 1,719 organizations surveyed have skipped buying at least one piece of software because they could build it themselves with AI coding agents.

Here is the answer up front. If you run a service business, you can now build a lot of the small tools you have been renting. A client intake form that writes to your CRM. An internal dashboard. A proposal generator that pulls from your own pricing sheet. Tools like Lovable, Claude Code, and Replit make that a weekend project at roughly $25 to $200 per month, not a $15,000 dev quote.

But the same McKinsey survey found that the share of companies seeing any profit impact from AI stayed flat at 37%. A third of the market stopped buying software and the earnings line did not move. That gap is the whole story. Building is cheap. Owning what you built is not.

So the real question is not "can I build this?" It is "should I own this?" Below is the test I use to answer it, with the numbers behind it.

What did McKinsey actually find about building instead of buying?

Nearly a third of companies cancelled at least one software purchase because an AI coding agent could build the feature, and the shift is strongest in tech and professional services.

The survey covered 1,719 business leaders across 97 countries. The build-instead-of-buy number breaks down by industry: technology firms lead at 41%, healthcare at 39%, professional services and energy at 38%. Insurance sits at 19% and the public sector at 17%.

That professional services number matters for anyone reading this. Consultants, agencies, and firms that sell expertise are already among the most aggressive builders. Your competitors are doing this.

The high performers, meaning the 6% of respondents who attribute at least 5% of their earnings to AI, are even more aggressive. Nearly half of them have skipped a software purchase, compared to 31% of everyone else.

McKinsey senior partner Lieven Van der Veken framed it as being deliberate about where to buy, where to build, and where to develop internal capability. That is the right frame. The wrong frame is the one most operators use, which is "the subscription costs $99 a month and Lovable can build it in an afternoon."

Why does building look so cheap right now?

Because the first version of any tool is the cheapest part of its life, and that is the only part AI coding agents have made dramatically cheaper.

Let me put real prices on it. Lovable runs about $25 per month for its Pro tier and builds full web apps from plain-English prompts. Replit Core is around $25 per month with its Agent included. Claude Code comes bundled with Claude Max at $100 to $200 per month. Cursor Pro is about $20 per month. A non-technical operator can get a working internal tool out of any of these in a few hours.

Compare that to 2024, when a custom intake portal from a freelance developer ran $5,000 to $15,000 and took six weeks. The build cost dropped by roughly 95%. That is not hype, it is just what happened.

Here is what did not drop. Published estimates put maintenance at 60% to 90% of a piece of software's total lifetime cost. A common budgeting rule is 15% to 25% of the original build cost every year, forever. Bug fixes, API changes, security patches, the login that stops working when Google updates something.

AI agents are strong on the first line and weak on the rest. Stanford research cited in Google's DORA report puts the productivity gain at 35% to 40% on simple new projects and 10% or less on complex existing code. The tool you build this month becomes existing code next month.

GitClear analyzed 623 million code changes from 2023 to 2026 and found duplicated code up 81% and refactoring down from 21% of changes to under 4%. AI-written code works. It is also harder to fix later.

What does a service business actually pay to own a tool?

A tool that costs $200 to build will cost you roughly $600 to $1,500 over three years in time, patches, and the hours it eats when it breaks, and that is before you count the risk of a bad day.

Say you replace a $79 per month form and scheduling tool with something you built in Lovable. Over three years the subscription would have cost $2,844. Your build cost $25 in Lovable credits and a Saturday.

Now add the run cost. Something breaks about once a quarter on a live tool with integrations. Call it two hours each time to diagnose and re-prompt the fix. At $150 per hour of owner time, that is $1,200 a year, $3,600 over three years. You are now above the subscription you cancelled, and you are the support desk.

That math changes if the tool is thin. A one-page internal dashboard that reads from one Google Sheet and never touches a client breaks maybe once a year. Run cost drops to a couple hundred dollars. Now the build wins clearly.

The difference between those two cases is not the coding agent. It is what the tool touches.

There is also the security line. Veracode's July 2026 report found AI-generated code introduced a known vulnerability in about 44% of tasks when the prompt did not explicitly ask for security. If your built tool stores client data, that number is your problem now. When you bought the SaaS, it was the vendor's.

What is the Thin Layer Test?

The Thin Layer Test is five yes-or-no questions, and you should only build a tool yourself if you can answer yes to all five.

I use this before any build decision in my own operation and with clients. It takes about ten minutes.

One, does it have one integration or fewer? A tool that reads from your CRM is thin. A tool that reads from your CRM, writes to your calendar, sends SMS through Twilio, and syncs to QuickBooks is a product. Every integration is a thing that will change without telling you.

Two, does it touch zero regulated or sensitive client data? Payment details, health information, anything under a signed NDA. If yes, you want a vendor with a SOC 2 report and a liability clause, not a Lovable project.

Three, are the only users you and your team? The moment a client logs in, you own uptime, password resets, and the 9pm text when it is down. Internal tools can be down for a day. Client-facing tools cannot.

Four, is there a named person who will own it for two years? Not "the team." A person. If that person is you and you are already the bottleneck, the answer is no.

Five, are you paying for seats or features you do not use? Most build-versus-buy arguments are really "we use 3 of 40 features" arguments. That is a negotiation with the vendor, not a build. But if you are paying $300 a month for ten seats and use two, that is a real reason to build the two things you need.

Five yeses, build it. Four or fewer, buy it or negotiate. It is that simple.

What should a service business build right now?

Build the thin internal layer on top of the systems you already pay for, and leave the core systems alone.

Here is what passes the test in most service businesses I see.

An internal dashboard that pulls your pipeline from GoHighLevel or HubSpot into one screen with the three numbers you actually check. One integration, internal only, read-only. Lovable builds this in an hour.

A proposal generator that takes your discovery call notes and your pricing sheet and drafts the document in your format. This is a prompt plus a template, not really software. Claude Code or a Make.com scenario at $9 to $30 per month handles it.

A weekly client report builder that reads from one data source and produces a PDF. Internal, one integration, replaces a $50 to $150 per month reporting tool most agencies use two features of.

An onboarding checklist app for your own team. Zero integrations, zero client access. This is the ideal build.

Here is what fails the test and should stay bought: your CRM, your booking system, your invoicing and payments, your email platform, anything that stores client contracts. These are the systems where the McKinsey insurance number is instructive. Insurers build at 19% because in their world, the software was never the product. The audit trail and the liability were.

Your CRM is not as regulated as an insurer's underwriting model. But it holds every client relationship you have. A $97 per month GoHighLevel subscription buys you a vendor whose entire business depends on that data not disappearing. You cannot build that.

How do you keep a build from becoming a liability?

Write down the run cost before you start, give it one owner, and re-read the number in twelve months before you build a second thing.

If a tool passes the Thin Layer Test, three habits keep it cheap.

First, budget the run cost on paper. Take 20% of the build cost per year, plus two hours a quarter of owner time. Write it down where you track subscriptions. A build that is not on the subscription list is a cost nobody audits.

Second, pin your dependencies. If the tool calls an AI model, name the exact version. If it reads from an API, note which one. This is the same lesson from last week's piece on model pricing: a vague "latest" setting means every upstream change becomes your emergency.

Third, build one thing, run it for a quarter, then decide on the second. Gartner expects more than 40% of agentic AI projects to be cancelled by the end of 2027 over unclear value and escalating costs. Most of those started as three builds in the first month. Internally built systems succeed about a third of the time versus roughly two-thirds for purchased tools. You improve those odds by building slowly and learning what breaks.

Does this mean you should stop buying software?

No. It means you have leverage you did not have two years ago, and the smartest use of it is often at the negotiating table, not in the code editor.

SaaS pricing has gotten aggressive. Vertice, which manages over $75 billion in software spend, puts SaaS price inflation at 16.4% as of June 2026, the highest it has recorded. Vendors are raising prices on products most customers use a fraction of.

The ability to say "we can build this" is worth real money in that conversation even if you never build anything. When your booking tool announces a 20% increase, you now have a credible alternative. Ask for the old price or a smaller plan. Most vendors would rather keep you at $79 than lose you to a Lovable project.

Klarna is the most-cited example of a company that ditched Salesforce and Workday to build its own. What it actually did was move to other SaaS tools with AI layered on top. The famous SaaS-killing was a migration with a better negotiating position. That is a fine outcome. It is just not the one being pitched to you.

The point of AI in a service business is that your people spend more of their time on the work clients pay for. A coding agent that saves you a $79 subscription but costs you a Saturday a quarter did not do that. A coding agent that builds the one dashboard your ops lead checks every morning, and never breaks because it only reads one sheet, did.

McKinsey's 32% is real. The flat 37% is also real. Be one of the operators who understands why both are true. Run the Thin Layer Test on the next tool you are tempted to build. Then build only the ones that pass.

---

If you want a clear picture of what AI can actually do for your specific operation, book a free AI Clarity Call. Thirty minutes, no pitch, you leave with a real answer.

If you want to learn alongside other operators and stay current on what is working, join the Abra AI community. That is where I share what I am actually building.

Subscribe to the newsletter for more breakdowns like this.