You Can Build It. That Was Never the Question.

Thirty-two percent of organizations decided against buying at least one software product or feature this year because they believed they could build it in house with agentic coding tools. That's from McKinsey's 2026 State of AI survey, which also found large enterprises scaling AI agents jumped from 27% to 40% in a single year.

The number is real. The conclusion people are drawing from it is not.

Because that 32% didn't decide to build. They decided not to buy. Those are different decisions, and the survey can't tell them apart. One of them shows up in this year's budget as a savings. The other one shows up in 2029 as a problem nobody remembers agreeing to.

Commercial software isn't built for you

Let's give the build side its best argument first, because it's a real one.

Commercial software is not made for your company, your enterprise, how you work, or what you need. You are, at best, a small part of a market. When you buy commercial software you're buying what everyone else needs in addition to what you need, or what you think you need. Every enterprise buyer has sat through a demo watching features they will never touch, doing quiet math on what fraction of that license they'll actually use.

That complaint is legitimate. It's also incomplete.

The bloat you resent is the same mechanism that covers your blind spots. Commercial software contains the parts you'll likely need but didn't think of when you were writing requirements. The audit trail you didn't scope. The SSO integration you assumed you'd never need until legal asked. The rate limiting nobody considered until the day it mattered.

You're not paying for features. You're paying for the requirements you weren't smart enough to write down.

Building the tool was never the hard part

Set aside slop and capability for a moment. AI coding quality over the last twelve months has been remarkable, and it keeps improving. I'm not going to pretend the tools don't work, because they do.

So assume they work perfectly. Here's what actually happens.

You define the product in an intense workshop. Everyone leaves feeling good. Two weeks later you've got a reasonably complete MVP and you share it with the team. Now what?

Now you own a product. It has to be maintained. Secured. Integrated. Supported.

And not just code revision supported. User supported. Somebody has to be able to answer the call that goes "the software I need to do my job just broke, I cannot wait for a maintenance window, I need to work now." That call comes at 4:40 on a Friday. The person making it has a deadline and a manager who doesn't care whose fault it is.

For that call, you have no knowledge base. No corpus of history to lean on. No community forum where somebody hit this in 2023 and posted the fix. No third-party support contract. No partner who's seen it before.

You own all of it.

You cannot fire your own company

This is the part that gets skipped, and it's the one that ends careers.

A vendor relationship is a shared responsibility model. Somebody else carries part of the burden, and when they stop carrying it, you fire them. That's the whole deal. It's why you tolerate the pricing.

Say you're done with your CRM vendor. There are effectively infinite options. And if you don't have the internal capability to move from HubSpot to Salesforce, or Dynamics to HubSpot, there's a rich network of partners who've run that migration dozens of times and will quote you a fixed price to do it again.

Now say you're done with the CRM you rolled yourself. Who do you call?

Nobody. There's no partner network for your thing. No migration playbook, no reference architecture, no consultant with prior experience. And the internal team who lovingly built it, who just found out it's being thrown in the trash and their roles are being eliminated, is not going to be your most enthusiastic migration resource.

You can fire a vendor. You cannot fire your own company.

"But the AI can maintain it too"

Here's the pushback, and it's the smart version. The support burden I'm describing assumes 2019 conditions, humans reading logs and writing runbooks. If the agent built it, the agent can maintain it, triage it, and write the knowledge base I say doesn't exist. I'm pricing a cost that's actively falling.

Anybody making that argument hasn't run it in production.

Your users are not going to wait while AI hallucinates a poorly written ticket from someone who's already frustrated. The role of tech support doesn't change just because AI is here and AI wrote the tool. If it did, the last three years of large-scale experiments swapping human customer experience for AI would have produced a success story worth pointing at.

Instead, here's the scoreboard.

Klarna replaced 700 agents with AI and announced $40M in projected savings, then rehired humans after satisfaction dropped and repeat contact rates climbed. Commonwealth Bank of Australia cut 45 call center roles for a voice AI system and reversed within weeks when call volumes rose and quality fell. Ford hired 350 veteran engineers after finding that feeding requirements into automated systems didn't catch the defects experienced people catch. IBM's HR agent handled roughly 94% of requests, and the 6% requiring actual judgment was enough to force a rethink and a tripling of entry-level hiring. Duolingo walked back its AI-first memo inside a year, with the CEO conceding that the unhappy path consumed more effort than the happy path saved.

Forrester puts employer regret over tech-driven staff cuts at 55%.

This was never an argument about whether AI can write code. It's an argument about the AI-to-human interface at the exact moment somebody is under pressure and the tool has failed. That's the moment your whole investment gets judged, and it's the moment the technology is weakest.

Where this actually works right now

Headless and userless.

A custom integration that runs in the back office with no direct user connection is a good use of AI development today. Nobody calls the helpdesk about it. The blast radius is contained. When it breaks, it breaks into a log file and somebody fixes it Monday.

CRM, project management, communication, collaboration? Probably not. Not yet. Those are systems of engagement, which means every failure is a human being blocked from doing their job, and every one of those humans has a manager who wants an answer now.

Think about the application holistically. It's more than code and an interface. It's the entire ecosystem used to support it. Is it smart to take that on? Is the business positioned for it? Can your support team handle the change? Do you even want to?

If you're going to do this anyway

Three things, in order.

Know your own capabilities. Is your company capable of becoming a software vendor for key pieces of your operational capacity? Do you want to be? Can you fund this the way you fund your primary or secondary business today? Is technology a key stakeholder in your decision process right now? If it isn't, and you do this, it will be.

Know your tolerance for failure. This requires shipping fast and failing fast, because every failure informs the next success. If your organization is slow, if a bad release triggers a blame culture instead of a fix, this is going to be miserable and it's going to fail anyway.

Scope small and win. If this is your first one, limit the scope and the blast radius. If you need more than four people in the room to define the application and its success criteria, you're going to fail. Four may already be too many. Start with something headless and userless. Expand from there, and let your successes drive the flywheel.

Don't take on the most critical thing first. The fantasy is pointing at every desk in the company and saying "I built that." The likelier version is pointing at every desk and saying "I built that" while telling the story of why you got fired when it went wrong.

Trust is long to build and fast to destroy.

What to do with this

TO CEOs: When you ask your technology organization to build instead of buy, understand what you're asking them to become. You're not asking for a project. You're asking the company to add a software product line, permanently, with support obligations to your own employees. Fund it like a business or don't ask for it.

TO CIOs: Learn to say the real total cost of roll-your-own out loud, in a board meeting, before anybody falls in love with a demo. The build is two weeks. The obligation is a decade. If you can't articulate that difference clearly, the decision gets made without you and you'll still own the outcome.

TO CTOs: You're already wired for "we can do it," and that's your job, so I'm not asking you to stop. I'm asking you to be the person who says out loud what it costs to still be right about that in year three.

---