What If Your Customers Just Build It Themselves?
A third of organizations skipped a software purchase because coding agents let them build it — here's what small teams should do.
One number from McKinsey's 2026 'State of AI' survey deserves a small team's attention: 32% of responding organizations decided against buying at least one software product or feature because they could build it internally with agentic coding tools. The pattern was strongest in technology and healthcare, followed by professional services and energy and materials. Whether you sell software or buy it, that shifts the ground under your business.
Why is “build” suddenly beating “buy”?
Because coding agents dropped the cost of making something internally that is merely good enough. Work that once required several developers for months can now start as a draft from the person who actually does the job, cleaned up by one engineer. So the question “couldn't we just build this?” now arrives before the purchase order does.
The same survey shows large organizations scaling agents in one or more functions rose from 27% to 40%, while adoption among smaller organizations stayed essentially flat at around 22%. Put those two numbers side by side and the picture is clear: the teams with money and headcount already moved toward building, and small teams mostly have not. That is a widening gap — and also a window that is still open.
Worth noting too: chatbots remain the most widely scaled AI tool at 47%, while only about two in ten organizations report scaling AI agents or coding agents across the enterprise. So this is not “all software disappears.” It is internal quick-builds eating the bottom of the purchase list — the single-feature products: intake forms, report generators, lightweight alerting tools.
If customers build it themselves, what should you sell?
Products that are only a screen plus a feature go first. What gets more valuable is everything a customer does not want to own alone: accountability, operations, integrations, and verification. Move your unit of sale from “feature” to “outcome plus upkeep.”
- Speed to in-house capability: for the client who insists on building, deliver a two-week sprint that ships v1 plus the internal rules doc, then charge monthly for operations.
- Accountability and operations: incident response times, log retention, privacy handling — the parts internal drafts almost always skip.
- Integrations: payments, shipping, invoicing, booking systems — the connections nobody enjoys wiring up twice.
- Domain data: industry document templates, past support transcripts, field glossaries. A coding agent cannot clone these.
- Verification: a pre-launch answer-quality test set and a results report. You are selling the gap between “we can build it” and “we can trust it.”
Example: sell a clinic booking chatbot as a chatbot, and someone on the client's staff builds a rough version over a weekend. Sell it as a monthly measured report on no-show rate and phone handling time, and you still own the yardstick their homemade version gets judged against.
If you hear “we already tried building something like this with Cursor or Claude Code” more often in sales calls, treat it as an opening, not a rejection. Ask three questions: are you still using it daily, who fixed it when it broke, and have you ever shown its output to someone outside the company? Wherever they stall is exactly where your offer belongs.
Should your own team build or buy?
The test is not “can we build it” but “can we own it for three years.” Coding agents cut the cost of v1; they do not cut maintenance or liability. Run this order and most decisions answer themselves.
- Is this feature core to what makes you different? If yes, build. If not, lean toward buying.
- Does being wrong cost money or trigger legal exposure? Payments, tax, and personal data are cheaper to buy.
- Can it reach real production quality within a month? If not, buy now and revisit later.
- Who fixes it if the builder leaves? No answer means don't build.
- Can you reverse it? Confirm data export and source code custody first.
For instance, classifying inbound customer messages by your own rules is context-heavy and good to build; issuing compliant tax invoices is rule-heavy and better bought. When it's a coin flip, set a deadline instead of a debate: “if we have something usable in two weeks, we build; otherwise we buy.”
One more line for the buying checklist: an internal build sends no invoice, but it does send a time invoice. Log who spends how many hours on it for three months, and you finally have a number comparable to a subscription fee. Without that log, “free because we made it” stays an illusion.
The real message of this survey isn't that software development became free. It's that the baseline for purchase decisions moved. If you sell, sell outcomes and upkeep instead of features. If you buy, price three years of maintenance instead of a build quote. Re-reading one open purchase and one open proposal through that lens this week is enough of a start.