Don't Build What You Can't Keep

The request arrives the way it always does. Someone in operations needs a tool that doesn’t exist, or exists at a price that feels silly for what it does. Five years ago the answer in a company with a small IT team was automatic: find a vendor, sign, move on. Building was for companies with a developer floor.

That answer stopped being automatic, and my own budget is part of the evidence. I’m buying fewer software tools. When a client needs something now, we often build it with AI coding tools instead of paying for someone else’s product. The short version of the argument went out as a LinkedIn post: the old rule, don’t build what you can buy, was never about owning software. It was about what building cost, and that cost fell. So the rule grew a second half. For the work that’s actually yours, don’t build what you can’t keep.

This article is the part the post couldn’t hold. Who is actually doing the building, as far as anyone can tell? Which builds are worth doing? And what does it cost to keep one alive? Those three questions are where a mid-sized company gets this right or gets it expensively wrong.

What the survey says, and what it leaves out

McKinsey’s State of AI survey, published in late August 2026 with 1,719 respondents in 97 countries, found that 32% said their organization had decided against buying at least one software product or feature because it could be built in-house with agentic coding tools. Among the 6% McKinsey calls high performers, organizations that both attribute at least 5% of operating profit to AI and call its impact significant, nearly half had done so, against 31% of everyone else.

That’s the headline, and it’s real. What the survey doesn’t tell you is who these organizations are. It splits the 32% by industry, never by company size. It does split adoption and scaling by size, and that’s where the picture gets less comfortable for a company of 150 people.

Scale still matters, more than the headline admits

In McKinsey’s words, AI deployment by larger organizations “continues to outpace” deployment by smaller ones. Larger means more than $1 billion in annual revenue. 54% of respondents from those organizations report scaling AI across the enterprise, against a third from smaller ones. On agents, the share of large organizations scaling them in at least one function went from 27% last year to 40% this year, while among smaller organizations it stayed essentially flat at 22%.

A few things follow. First, McKinsey’s smaller bucket is everything under a billion dollars in revenue, so a 150-person company sits at the far end of a category that also holds firms with hundreds of engineers. The gap a 150-person company would feel is probably wider than the one the survey shows. Second, the high performers, the group more likely to be building, are also far more likely to be scaling agents: more than three times as likely as others to be scaling them in most of the business functions McKinsey covers. That’s a performance group rather than a size group, so it doesn’t settle who the builders are either. The one thing the survey does say about where these decisions cluster is the industry: technology and healthcare first, then professional services, then energy and materials, and the list stops there. What the survey does show is that the large organizations are moving fastest on agents, and that until someone publishes the split, a mid-sized company is working without a benchmark.

So can a mid-sized company do it? Yes. I do, from inside professional services, which is on that list, so take my case as proof it’s possible rather than as a template. What changes with size isn’t whether you can build. It’s what happens in year two.

Here’s the year-two scenario I’d plan around. One strong engineer, or one operations person who has learned to work with a coding agent, ships a useful internal tool in a few weeks. It replaces a subscription and everyone is pleased. Eighteen months later that person leaves, and the tool becomes a piece of software nobody left in the building has read. A vendor product in the same spot has a support line, a release schedule and other customers hitting the same bugs first. Your tool has none of that, and it has spent eighteen months quietly collecting changes nobody went back to.

The last of those, the changes nobody went back to, is partly a guess about human nature, and partly not. There is aggregate evidence that code is being revisited less than it used to be. GitClear, whose product attributes each line of code to the AI model that wrote it, analysed 623 million code changes from 2023 into 2026. Its measure of code revised long after it was written, a share of the changes it tracks, fell from 1.7% to 0.46%, roughly a quarter of what it was. Over the same period, duplicated blocks per million changed lines rose from 40.3 to 73.0, an 81% increase and the highest level in its records. GitClear reads that as the fingerprint of AI-assisted coding. I’d keep the claim narrower: whatever the cause, the code being written now is copied more and revisited less than it was three years ago. GitClear’s own line for what happens next: “These neglected sections gradually calcify until something breaks.”

So the size question comes down to two questions a CEO can ask about any tool that’s already been built, without reading a line of code, and neither of them is “do we have engineers.” Who is the second person who can open this and change it? If there’s no name, you don’t have a tool, you have a dependency on a person. And could a successor rebuild it in a week? A tool small enough to rebuild is a tool you can afford to lose. One that has grown past that needs what a product needs: a named owner, a successor who can open it, a written description of what it does, and a run cost.

Not every build is the same build

Andrej Karpathy, who coined “vibe coding” in a post in February 2025, drew its limits in the same breath. He described accepting every change without reading the diffs, pasting error messages straight back in, and code that “grows beyond my usual comprehension.” His verdict: “It’s not too bad for throwaway weekend projects.”

He drew that line around a specific way of working, one where nobody reads the code. A team that reviews the diffs and writes tests is doing something else. The line still matters, because the cheaper building gets, the more of it happens the way he described. And it points at the sorting the buy-or-build decision has been missing: there are three kinds of build, and they aren’t close to each other.

The thin thing. A script, a report, a bit of glue between two systems you already pay for, a small internal page. Nobody would notice for a week if it stopped, and anyone could rebuild it in a few days. Build it, and treat it as disposable: don’t document it, don’t assign it, rebuild it when it breaks. My guess is that a good share of the purchases the survey’s 32% walked away from lives here, and it’s where a mid-sized company should build without a second thought.

The workflow that’s yours. A tool that encodes how your business does something nobody else does, your quoting logic, your intake process, your approval chain. This is where building wins on the merits, because no vendor product fits and the fit is the value. But the moment it sits on the critical path it’s a product, whether or not anyone calls it one, and it needs the same four things: an owner, a successor, a description and a run cost.

The mature vendor product you’d be replacing. Payroll, CRM, accounting, anything with logins for many people, permissions, audit trails, integrations, a security team behind it and a release every month. What you pay a vendor for there is the upkeep, and the upkeep is the whole price. This is where the old rule stands untouched, and it’s the same lesson as fewer, deeper AI bets return more: the win is in not adding one more thing to keep.

The test that sorts the three, before anything gets built, has two parts. First, what breaks on a Tuesday if this stops? If nobody would notice for a week, it’s a thin thing, and the second part doesn’t matter. Second, if someone would notice: could a competitor buy this same capability off a shelf? If yes, buy it, however much it matters to you, unless the licence costs more than keeping your own would, which is the question the next section prices. If no, you’ve built a product, with everything that comes with one.

The cost that arrives every month

A licence has a price on the invoice. A built tool has a price that arrives every month, spread across a token bill and people’s time, and never as one invoice you can cancel. This is the point I’d underline for any finance team cheering the subscription they just cancelled.

Two sets of numbers pull in opposite directions here, and both are true. For the same level of capability, AI keeps getting cheaper, fast. Guido Appenzeller, writing for the venture firm a16z, estimated in November 2024 that for a model of equivalent performance the cost was falling by 10x every year, and had already fallen a thousandfold in three years. And yet McKinsey finds one in five respondents saying their organization is already limiting AI use because of operating costs, tokens included, a share it reports as broadly consistent across company sizes. On coding agents specifically, the high performers, the ones more likely to be building, report being held back by cost about three times as often as everyone else.

How can both hold? Because the unit price and the bill are different things. The price of a given level of capability falls. The bill is price times volume, and volume is what a working agent grows, because a cheaper unit gets used for more. I haven’t seen that measured per organization, so treat it as the reading that fits both figures rather than as a finding. And the other part of the run cost doesn’t fall at all: the hours. Someone has to notice when a model update changes how the tool behaves, re-test it, fix the prompt that used to work, watch the outputs for the week after, and answer “is it still right” when nobody is asking. The judgement in that list, knowing when the output doesn’t fit, is a larger share of what you’re paying for than it used to be, and a built tool moves it in-house permanently. Model choice is part of the same bill: a tool built on one vendor’s model changes whenever that vendor changes the model, on their timetable rather than yours, which is one more reason to choose models the way you’d choose any supplier you can’t easily leave.

So the run cost gets one line per built tool. Tokens per month, read from the bill rather than estimated. That number only exists if each tool runs on its own key with the AI vendor. If everything runs through one account, split it before you try to fill in the line. Hours per month, from whoever owns it, rounded up, and counting the weeks it broke. And the licence it replaced, or, if nothing existed before, what the work cost by hand. If tokens plus hours come in under that, the build is paying its way. If nobody can fill in the line, the build is a hope with a budget line, and hopes don’t get to sit on the critical path.

The register

The Monday-morning move is a single page. A build register: one row for every build that someone would notice missing, and thin things stay off it, because that’s the point of them. Six columns. The four things a product needs: who owns it, who could take it over, where the description lives, and the run cost per month in tokens plus hours. Then the two that make the row decidable: what the licence it replaced cost per month, or what the work cost by hand if nothing existed, and the date it was last re-tested after a model change. Treat a blank cell as an action, and fill it. If the owner or the successor cell is still blank a month later, take the tool off the critical path: buy the generic version if one exists, and if none does, cut the tool back until a successor could rebuild it in a week.

“Don’t build what you can buy” still holds for everything generic, and it always will. For the work that’s actually yours, the second half is the one to write on the wall: don’t build what you can’t keep. Building became the easy part. Keeping it is the decision, and the register is where you find out whether you’ve made it.