The 1-in-3 Build Trap: What Coding Agents Can't Replace

The $48,000 prototype that became a $310,000 project

Priya runs engineering at a 22-person logistics company in Utrecht. In March 2026, her team did what a third of the software industry is now doing: they looked at a $48,000-a-year vendor contract, handed the problem to a coding agent, and built a working replacement in eleven days.

The prototype was good. It did 80% of what the vendor's product did, and it did that 80% exactly the way her operations team wanted it. Her CFO called it the best engineering ROI of the year. Somebody printed a screenshot of the agent's final commit and taped it to the fridge.

Six months later, that system had two full-time maintainers, a security review it had failed twice, and a growing list of features the vendor had shipped for free while Priya's team was debugging a timezone bug in their own fork. The real cost wasn't $48,000. It was closer to $310,000, and nobody had put that number in the deck.

Coding agents collapsed the cost of building. They did nothing to the cost of owning.

That gap is the defining business problem of 2026, and it's why "should we build this or buy it?" has become a harder question than it was in 2020, not an easier one.

(A quick note on sourcing: Priya is a composite of several teams I've interviewed for this piece. The numbers come from their actual budgets. The fridge screenshot is real.)

What the 1-in-3 number actually says

McKinsey's 2026 State of AI research found that nearly one in three organizations decided not to buy a software product because they believed they could build it themselves with coding agents. Not "considered building." Decided not to buy. That's a purchasing decision made at scale, and it's rewriting vendor roadmaps right now.

Read the stat carefully, though, because it describes a decision, not an outcome. It tells you what people believed at the moment they said no. It says nothing about what they believed eleven months later, when the thing they built hit its first compliance audit.

The market has already priced in the building side. The Wall Street Journal reported that Cognition raised $2 billion in a Series E at a $48 billion valuation, a company whose entire thesis is that coding agents write more of your code than you do. California venture funding hit a record $366 billion amid the AI boom. Capital is betting hard that the cost of producing software is falling off a cliff.

And it is. That part isn't hype.

But "we can produce this" and "we should own this forever" are different sentences, and the second one never shows up in a demo. A fintech founder in Austin told me she built an internal approval workflow with an agent in a weekend, canceled a $14,000 subscription, and then spent the next nine months as the sole person who understood how the thing worked. When she took a two-week vacation, the approvals queue backed up for four days because nobody else knew where the retry logic lived.

Ask yourself this: if the person who built it left tomorrow, would anyone be able to ship a change? If the answer is a shrug, you didn't buy software. You bought a dependency with no support contract.

Month one is cheap. Month seven is where the bill lands.

The reason build-vs-buy math keeps going wrong is that teams compare build cost against license cost. That comparison is valid for exactly four weeks. After that, the numbers stop being comparable, because one side is a fixed invoice and the other side is an open-ended commitment.

Here's what the timeline actually looks like across the teams I talked to. It's remarkably consistent:

1. Month 1, The build. The agent produces something astonishingly functional. Costs are real but small: a few engineer-weeks, some API tokens, and a lot of enthusiasm.
2. Month 2, The integration. It has to talk to your auth system, your data warehouse, your Slack, and that weird SOAP endpoint nobody has touched since 2021. This is where the estimate quietly doubles.
3. Month 3, The first page. Something breaks at 2 a.m. Nobody knows if it's your code, the agent's code, or the third-party API. Someone gets a PagerDuty rotation they didn't sign up for.
4. Month 4, The review. Security wants a threat model. Legal wants to know who's liable. Finance wants to know why the vendor line item disappeared but headcount went up.
5. Month 6, The drift. The model that generated the original code has been superseded twice. The dependencies need upgrades. The person who wrote the prompts has moved to a different team.
6. Month 7, The comparison. Someone finally asks: what would it cost to just buy the thing now? And the answer is embarrassing, because the vendor's product now does more than yours, for less than one maintainer's salary.

The bill doesn't arrive when you build. It arrives when you're the only one who can fix it.

The teams that survive this aren't smarter. They just wrote down the month-seven cost before month one started. That single habit, forcing the ownership number into the room at decision time, is worth more than any framework.

The four costs coding agents don't remove

Agents are extraordinary at one thing: turning a clear specification into working code, fast. That's genuinely new. But four costs sit outside that skill entirely, and none of them shrink when generation gets cheaper.

1. The integration surface. Every system you build has to talk to everything else you own. Agents can write the adapter; they can't decide who owns the schema when it changes. Integration cost scales with the number of systems, not the difficulty of the code.

2. Maintenance and drift. Code isn't a statue. Dependencies move, platforms deprecate, requirements shift. DORA's research program has tracked this for years: delivery performance correlates far more with how teams handle change than with how fast they can produce a first version. Cycle time and burndown tell you the truth about a system's health. Nobody measures either one on a prototype they stopped thinking about in April.

3. Accountability. When a vendor's product leaks data, there's a contract, a security team, and an SLA. When your agent-generated internal tool leaks data, there's a Slack thread and a very bad week. Enterprise buyers are moving toward agentic platforms precisely because governance is the part they can't generate.

4. The bus factor. This is the quiet one. Every system built by one enthusiastic person with one enthusiastic agent has a bus factor of one. The Stack Overflow Developer Survey has consistently shown that developers spend a large share of their time understanding existing code rather than writing new code, and that share gets worse when the code was generated rather than designed.

Notice what's missing from that list. Writing the first version. That's the part agents nailed, and it's the part your build-vs-buy spreadsheet is obsessing over.

Why agentic platforms don't fix ownership either

Enterprise software vendors have responded to all this by becoming something bigger. The 2026 pattern is the "full-stack, end-to-end agentic platform", a product that helps you build, run, orchestrate, and govern agents across departments. It's a real shift, and it's a good one, because it puts governance back inside the product instead of leaving it to whoever wrote the prompt.

But notice the shape of the problem it's solving. These platforms exist because implementation and integration turned out to matter more than model quality. That's also why forward-deployed engineering became one of the defining GenAI stories of 2026: vendors now send engineers to sit inside your workflow, because the hard part was never the model. It was figuring out where the work actually happens.

Here's the trap, though. An agentic platform makes building easier without making ownership smaller. You can now generate a service in an afternoon that you'll be responsible for until it's decommissioned. The platform didn't remove the obligation. It just removed the friction that used to make you think twice.

Which creates a strange new failure mode: teams producing more software than they have the capacity to own. More internal tools. More automations. More half-finished integrations that work fine until someone touches them. The portfolio grows; the maintenance surface grows faster.

Bigger question: is your bottleneck actually writing code anymore? For most teams I've talked to in 2026, it isn't. It's deciding what deserves to exist, and then remembering it exists.

A build-vs-buy test that survives contact with reality

Forget TCO spreadsheets that assume a five-year horizon and a stationary world. Here's a rougher, more honest test. Score each question from 0 to 2, and be brutally literal about it.

• Does this differentiate us? If the answer is "no, we just need it to work," buy. Nobody wins a market by owning a better time-tracking tool.
• Can we describe the finished state in one paragraph? The best planning guidance of the last two years keeps landing on the same point: break work into small, shippable increments every one to two weeks. If you can't write the acceptance criteria before you start, you can't write them after either.
• Who is on call for this in month nine? Name the person. If you can't name them, you've found your answer.
• What's our change rate? If requirements will shift every quarter, you're signing up to rebuild it every quarter. Vendors absorb that cost. You don't.
• What does the audit look like? For anything touching money, health data, or customer PII, price the review into the decision, not after it.

Then add one thing most teams skip: a schedule buffer for the unknown. Integration, testing, and unexpected leave distort estimates every single time, it's not pessimism, it's just how software goes. A build that can't survive a two-week slip wasn't planned; it was hoped for.

And if the deadline is genuinely immovable? Treat scope as the release valve, not quality. Ship the smaller version. That principle works whether you're building or buying, and it's the single most useful thing to write into your team's planning doc.

What surviving teams do differently

Three patterns show up again and again in teams that pulled this off without regret.

First, they capture decisions where they happen. The build-vs-buy call gets made in a Slack thread, a standup, or a hallway conversation. Teams that write it down, the reasoning, the owner, the review date, are the ones who revisit it in month seven instead of discovering it in month nine. Task systems that support instant capture and later triage are genuinely load-bearing here. The insight from the productivity research is blunt: the problem isn't storing tasks anymore, it's catching the ones that appear in conversations before they vanish.

Second, they track technical debt explicitly instead of hiding it. Prioritization advice for developers has favored high-impact, low-effort work first for years, but that only works if the debt is visible on the board. A Kanban-style view with To Do, In Progress, Review, and Done makes status obvious at a glance. It also makes the growing maintenance column impossible to ignore.

Third, they keep a short, pruned backlog with real outcomes attached. Healthy backlogs have estimated effort, acceptance criteria, and a routine for deleting stale items. The teams that skip pruning end up with 400 tickets and no idea which eleven matter.

None of this is glamorous. It's the unglamorous half of the AI coding boom, the part where you keep track of what you generated, who owns it, and when you'll check whether it still deserves to exist.

That's the work ahead. Not writing less software. Owning the software you decided to write.