"We Can Build That" - How business leaders should think about building vs buying software
Vibe coding made the first version of almost any software nearly free to produce, which is not the same thing as making the software cheap to own.
A founder I work with, sent me a screenshot last month with a single line of commentary: “Why are we still paying for this?” The screenshot was an invoice, a few hundred dollars a month, for a tool his operations team had used for years. Underneath it he had pasted a working prototype of a replacement that he had built over a weekend by talking to Claude on his phone. It did most of what the paid product did. It had taken him about six hours. He wanted to know whether he should cancel the subscription and have someone on his team “just finish it.”
I’ve had some version of this conversation more times than I can count now, which is itself the point. The prototype is new, but the question underneath it is old: we’ve been arguing about build versus buy in software for thirty years, and the argument always turned on the same number, which is how expensive it is to build, really, once you count the whole life of the thing rather than the first demo. What changed in the last eighteen months is that the first demo got close to free. What didn’t change is everything that happens after it.
It helps to look at how the ground actually moved. There is a genre of chart that maps the AI coding tools onto a ladder, rung by rung, from simple code completion at the bottom up through task automation, project automation, something the makers like to call an AI engineer, and at the top, autonomous AI development teams that promise to take a sentence and return a running application. A version of this map from early 2025 was mostly empty at the top. The upper rungs held a few experiments with names you’ve already forgotten. By 2026 the same ladder was crowded all the way up, the experiments at the top had become products people actually shipped with, and a prompt-to-app tool that would have been a curiosity the year before was the default way a non-engineer started something. By the time you read this the chart will have turned over again, the names in this paragraph will look quaint, and a rung that doesn’t exist yet will be the one everyone argues about. That churn is the whole reason to bring the chart up at all. Every one of these maps, in every year, ranks the tools on one axis, which is how much of the work they can do without a human in the loop, and not one of them has ever carried an axis for how much the resulting software costs to own once it exists, which happens to be the thing that actually decides build versus buy and the thing no version of the chart has ever shown.
Brandur Leach wrote a sharp piece at the end of May called “The Minimum Viable Unit of Saleable Software,” (linked at the end) and it is the cleanest treatment I have seen of the vendor’s side of this. His example is almost identical to my founder’s: someone on LinkedIn bragging about replacing a four-hundred-dollar-a-month Jira subscription with an internal tracker built by an LLM. Leach does the arithmetic the LinkedIn poster did not. Price an engineer at two hundred thousand dollars a year and you are paying about ninety-six dollars an hour for their time. To beat a four-hundred-dollar bill, that engineer can spend no more than four hours a month keeping the homegrown tracker alive, and that is before you count the cost of switching their attention away from whatever they were supposed to be doing. Be generous, assume the LLM gets maintenance down to two hours a month, and the project still takes more than three years to break even on the initial build. His conclusion is that there is a “zone of viability,” a band of price and complexity inside which buying still beats building even when an LLM will cheerfully write you the alternative, and that a healthy software business needs to price itself into that band.
Leach is right, and his model is conservative in a way that makes his case stronger than he claims, because he’s pricing only the labor of the person sitting at the keyboard prompting the model, which is the visible cost and not the one that does the real damage.
The carry
I have written before, in a piece called “Code Was Never the Bottleneck,” that the trap in all of this is treating the production of code as the hard part of building software. It was never the hard part. The hard part was always the part that has no demo: the integration with the three other systems that already hold your data, the permissions model that decides who can see what, the audit trail you will need the first time a regulator or an acquirer asks how a number was calculated, the quiet accumulation of edge cases that nobody specified because nobody knew about them until they broke. None of that shows up in a weekend prototype. All of it shows up later, and it shows up as a recurring obligation rather than a one-time expense. I’ve started calling this the carry, borrowing the word from finance, because the defining feature of the cost is not its size but its persistence, the way you carry it for as long as the thing runs rather than paying it off once.
The carry has at least four components that Leach’s two-hours-a-month figure does not capture, and any one of them can swamp the licensing fee you thought you were saving.
The first is context decay. The founder who built the tracker over a weekend understands it completely, on the Saturday he built it. He understands the choices the model made, the cases it handled, the cases it silently dropped, the half-finished prompt thread where he told it to “just make the dates work for now.” Six months later he understands none of this, and neither does anyone else, because it was never written down anywhere except in a conversation history that no one else can read. When he leaves, or simply moves on to the next fire, the tool becomes an artifact the company depends on and can no longer explain to itself. A purchased product distributes that knowledge across a vendor whose continued existence depends on retaining it. Your internal tool keeps it in one person’s head, and heads leave.
The second is the integration surface. Every internal tool that touches real company data opens a surface you now own and must defend: authentication, access control, logging, data residency, the SOC 2 question, the single-sign-on integration that everyone assumes exists until the day it doesn’t. When you pay for Jira, Atlassian carries this for you, and a meaningful share of that four hundred dollars is the cost of them carrying it. When you build the replacement, you haven’t eliminated that cost. You have moved it onto your own balance sheet and, more often than not, declined to fund it, which means you are running it as an uninsured liability until something forces the issue.
The third is the one I find mid-market owners discount most completely, because it never appears on any invoice. It is the opportunity cost of their own attention. In a company of fifty or two hundred people, the scarcest resource in the building is the founder’s capacity to make decisions, and every hour spent wondering whether the internal tool is computing the right thing is an hour not spent on the work that actually compounds. This is the same error I described in “The Cost of Thinking It’s Easy,” only turned inward. There I was writing about owners who negotiate down what they’ll pay a vendor because the work “looks easy now with AI,” without pricing the expertise and infrastructure and risk that sit underneath the easy-looking surface. The build version of the mistake is worse, because the person absorbing the underpriced work is the one person whose time the company can least afford to spend that way.
The fourth is feature gravity. Internal tools don’t stay the size they were on the weekend they were born. People ask for changes. The list grows. The person who built it becomes, by slow accretion, a part-time product manager for a product that generates no revenue and serves users who can walk to his desk. This is the mechanism by which a clever side project becomes a job nobody chose to create and nobody can quit.
What actually changed
The honest version of this argument has to concede real ground, because a great deal has changed, and some of it moves the line decisively toward build.
There’s now a category of software you should simply make and stop thinking about. An internal dashboard that pulls together numbers you already collect and shows them the way you actually think about the business. A throwaway script that cleans up a vendor’s ugly export. A prototype built to find out whether a workflow is even worth pursuing before you spend real money on it. And the glue between two systems that no vendor will ever productize, because the seam is specific to you and there is nobody else to sell it to. In “Code Was Never the Bottleneck” I described the regional sales manager who wants to know which competitors came up in last week’s discovery calls and can now build that tool herself in an afternoon, where filing the request with IT would have meant entering a backlog that never clears. That work is real, the tools deliver it, and arguing otherwise is just nostalgia. When I surveyed the AI coding landscape earlier this year, the prompt-to-app platforms, Lovable and Bolt and Replit and the rest, were strongest at exactly this: getting a working thing in front of a person fast, before anyone has committed to maintaining it.
So the decision boundary is not the one the LinkedIn poster thinks he is standing on. The question is almost never “can a model build this,” because the answer is almost always yes, and it gets more emphatically yes the higher up that ladder you climb. But the rungs are not equal in what they leave behind. A tool that completes your line of code or automates a contained task hands the work back to someone who still understands the whole, because the human stayed in the loop the entire time. A tool that takes a sentence and returns a running application hands you something complete and opaque, a system whose every decision was made by a model and reviewed by no one, which is to say the most autonomous rungs produce the most finished output and the least understood output at the same time. The carry scales with the autonomy. The thing you should actually be asking is not whether the model can build it but whether the thing, once built, will demand an ongoing institutional commitment, and whether you are the right party to make that commitment.
The question that actually decides it
I’ve stopped offering clients a two-by-two matrix for this, because it invites them to argue about which box they’re in. I offer one question instead, and it does the work of the whole framework.
If the person who built this left tomorrow, what happens?
If the answer is that nothing happens, that someone deletes it and the company moves on without noticing, then build it, ship it, and do not give it another thought. It was never a product in the first place, just a convenience, and conveniences are exactly what the new tools are for.
If the answer is that the company would have to reverse-engineer what the thing does and probably rebuild it from scratch, then you are looking at a vendor-shaped hole, and you should buy the vendor. The licensing fee you resent is the price of not carrying the obligation yourself, and Leach’s arithmetic, conservative as it is, already shows that the fee is usually cheaper than the carry.
If the answer is that critical workflows break and nobody knows how to fix them, then the decision has already been made badly, and the only useful move is to recognize it and buy the real product before the failure arrives on its own schedule rather than yours.
The trouble with build versus buy in the vibe coding era isn’t that the tools made building cheap, because they did exactly that. The trouble is that they made the cheap part visible while leaving the expensive part where it always was, out of sight, payable later, and easy to pretend doesn’t exist.
The third structure
Stated as build-or-buy, the choice looks like a trade with no free side. Build, and you get a thing shaped exactly to your business, and you take on the carry. Buying sheds the carry, but the product you get is shaped for the average of a thousand customers who aren’t you, meaning it fits you nowhere in particular. The whole argument so far has been that owners underprice the carry and so overvalue the fit, but I don’t want to leave the impression that the fit is worthless, because it isn’t. The reason my founder built his prototype at all is that the paid product genuinely didn’t do the two things he most needed, and no amount of correct arithmetic about break-even periods makes that frustration go away. What people miss is that build and buy are two answers to a narrower question than the one they think they are asking, which is who carries the obligation: in the buy model a vendor carries it and charges a margin for the privilege, in the build model you carry it and usually decline to fund it. Both leave the carry sitting on one side of a line, and the structure most owners never consider is the one that splits it.
If you can find a partner who will build the thing to fit your business, the way an internal team would, and then stay on to carry it, the way a vendor does, at a price set so that keeping it alive is cheap rather than a meter that runs forever, you have the fit of build without the institutional fragility and the support of buy without surrendering the thing to a roadmap drawn in some other company’s interest. The fit and the carry travel together instead of forcing you to sacrifice one to get the other.
I have to be honest about why this is rare, because the version most owners have met is the bad one, and their suspicion is earned. The usual build-it-and-support-it arrangement is worse than either pure option, since the partner’s incentives run backwards: a shop billing by the hour has every reason to make the carry expensive, to let the context live in its own people rather than your documentation, to ensure the thing breaks in ways only it can fix. What gets called a partnership in those cases is closer to a hostage arrangement wearing a partnership’s clothes, which is most of why the word has been hollowed out to the point of meaning almost nothing.
The good version inverts those incentives, and you can test for it before you sign anything by pressing on the same question that decides build versus buy in the first place: if this partner walked away tomorrow, what happens. A real one has already designed its own departure to be survivable, will hand you the code and the context or hold them jointly rather than hoard them, prices its support so that it earns less when the system misbehaves instead of more, and keeps the knowledge of how the thing works somewhere you can actually read it rather than only in the heads of its staff. It will tell you all of this without being pushed, because a structure that works only while the partner stays indispensable is one built to trap you, and a partner who built it that way has every reason not to say so out loud. These are the same questions I worked through in an earlier piece on how to buy AI work when everyone selling it is also using it: who is on the hook when it breaks, what you’re paying for in the weeks when nothing breaks, and whether the arrangement rewards the partner for the system working or for the project never quite ending. The economic viability is the whole test. A partner who can build and support at a price that pencils out for both sides across years, rather than one that pencils out for them only as long as you can’t leave, is worth more than the cleanest buy decision you will ever make. Those partners are uncommon, though not imaginary, and they are worth more effort to find than the subscription you were about to cancel.
The use you are actually missing
There is a better use of all this capability than replacing your vendor stack, and it is the one almost nobody is reaching for.
In the value-creation essay I wrote earlier this year, the argument was that the firms losing the AI race are the ones bolting models onto existing processes and measuring success by how much cheaper the old process got, when the real prize is using AI as a discovery mechanism, a way to learn something about your business you did not previously know. Build versus buy is where that abstraction becomes concrete and cheap enough to act on this week.
Do not build the CRM to replace Salesforce. Build the throwaway version, the one you will delete in a month, and make your team live inside it for two weeks. At the end you will know, with a specificity no sales demo could ever give you, which features your people actually touch and which ones are the vendor’s marketing. Then go buy the right product, with conviction, knowing exactly what you are paying for and exactly what you can ignore. The prototype was never going to be the product. It was the specification, and it is the most honest specification you will ever write, because you wrote it by using the thing instead of imagining it.
That’s the move the founder with the screenshot eventually made. He kept the subscription, and he kept the prototype too, not as a replacement but as the document that told him, for the first time in three years of paying the bill, what he was actually paying for. The six hours weren’t wasted on a failed replacement; they were the cheapest market research he had ever bought. He had just been about to file them under the wrong word.
References: