AI-assisted building has flipped the buy/build calculation

When one person can ship custom infrastructure in a weekend, the old reasons to buy off-the-shelf stop holding. A note on what that changes for product teams.

Abstract

The classic buy-versus-build decision rested on a stable assumption. Building is expensive and slow, so you buy unless the capability is core. AI-assisted development has broken that assumption. When one person can stand up custom infrastructure in a weekend, the cost side of the equation collapses¹1I have shipped several of these myself — a local RAG pipeline, an LLM-backed Chrome extension, an analysis dashboard — each in days. and the old reflex to buy off-the-shelf stops holding.

I. The old calculus

Transaction-cost economics gave us the tidy version. Make it in-house when coordination is cheaper than contracting; buy when the market does it better.²2Coase (1937), later Williamson: the firm’s boundary as a question of transaction costs. For software, “build” carried a heavy fixed cost, so the default for anything non-core was to buy a SaaS seat and move on.

The calculus was so stable it stopped being a decision. Procurement processes, vendor comparisons, and the entire SaaS pricing model grew up around one assumption, that custom software is a luxury reserved for whatever a company calls core. Everything else, you rent.

II. What changed

AI-assisted building drives the marginal cost of a bespoke tool toward the cost of specifying it well. The leverage moved from “who can write the code” to “who can define the problem precisely enough for a model to help build it.” That is a product skill as much as an engineering one.

The cost collapse is measured rather than anecdotal. In a controlled experiment, developers with an AI pair programmer completed a standard task 55.8% faster than the control group.⁴4Peng et al., “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot,” arXiv:2302.06590 (2023). Field studies with consultants found double-digit quality and speed gains inside the technology's frontier, alongside a warning this essay takes seriously. Performance degrades when people lean on the tools outside that frontier.⁵5Dell’Acqua et al., “Navigating the Jagged Technological Frontier,” Harvard Business School Working Paper 24-013 (2023).

The consequence is that a lot of things that used to be obviously “buy” are now plausibly “build”. The internal tool that fits your exact workflow, the eval no vendor sells, the glue between two systems.

I keep running this experiment on myself. A local RAG pipeline for interview data, an LLM-backed Chrome extension, an analysis dashboard. Each was a weekend or a few evenings, each replaced either a subscription or a manual process, and each fits its job better than anything I could have bought. The pattern held at work too. The eval suite for a multi-agent system I shipped was itself a build decision no vendor could have made for me.

III. The new failure modes

The old risk of building was that you couldn't afford to. The new risk is that you can, and so you build things you shouldn't own. A weekend tool still has to be maintained, secured, and understood by someone other than its author.³3The maintenance tail, not the build cost, is where cheap internal tools get expensive.

The second failure mode is subtler. Building becomes so easy that teams skip the question of whether the problem was worth solving at all. Far from licensing teams to skip scoping, cheap build cost raises the premium on it.

The jagged-frontier finding names a third. The boundary between what AI-assisted building handles well and what it botches is invisible from inside the work. A team that has shipped five cheap internal tools has learned where the frontier was for those five problems, and nothing about where it sits for the sixth. Build decisions now need the same discipline as any other bet, an explicit hypothesis about why this problem is inside the frontier, checked rather than assumed.

IV. A heuristic for teams

Buy when the capability is a moving target maintained better by a market, like security, payments, or anything with a compliance surface. Build when the value is in the fit. And treat every build as a product with an owner and a maintenance plan rather than a clever artifact.

Notes

1. See the Lab section of this site for examples built solo in days.
2. R. H. Coase, “The Nature of the Firm,” Economica 4, no. 16 (1937): 386–405.
3. On the long-run cost of internal tooling, ask any team that inherited an un-owned script.
4. Sida Peng, Eirini Kalliamvakou, Peter Cihon, and Mert Demirer, “The Impact of AI on Developer Productivity: Evidence from GitHub Copilot,” arXiv:2302.06590 (2023).
5. Fabrizio Dell’Acqua et al., “Navigating the Jagged Technological Frontier: Field Experimental Evidence of the Effects of AI on Knowledge Worker Productivity and Quality,” Harvard Business School Working Paper 24-013 (2023).

Works Cited