For thirty years, government software procurement has run on a decision so ingrained nobody bothered to question it: build, buy, or rent. Three options, one triangle. You weighed control against speed against cost, picked your corner, and lived with the compromise.

The triangle had a hidden fourth variable nobody put on the board. The cost of production. Everyone treated it as a constant, a high, fixed floor that made building from scratch the expensive corner you avoided unless you had no choice.

That floor just fell through. And when you collapse the vertex a model was built around, the model doesn't get better. It stops being a triangle at all.

The Iron Triangle Already Fell. This Is the Same Physics.

I've argued before that AI broke the Iron Triangle of cost, quality, and speed. You used to pick two. Now the constraint that forced the tradeoff, the human hours it took to turn a decision into working code, has collapsed toward zero, and the triangle degenerates into something you can optimize on every axis at once.

Build/buy/rent is the same shape with the same flaw. It assumed production was scarce and dear. Remove that assumption and the whole framework has to be rebuilt, because it was solving for a variable that no longer varies the way it used to.

The claim deserves numbers, not the assertion that AI changes everything. Here is the arithmetic.

The Napkin Math

Two lines. Where they cross is the whole argument.

The rent line. Take the vendors' own published pricing rather than an aggregator's estimate. Salesforce lists its mainstream sales-team editions at $195 per user per month for Core and $395 for Advanced, with lighter tiers at $25 and $100 and a top tier at $550 (Salesforce). The list price is only the beginning; Salesforce's Premier support plan is priced at 30 percent of net license fees, and that is before implementation (Salesforce). Blend all of that down to a deliberately conservative $100 per seat per month, well below the editions most enterprises actually deploy. Call it $1,200 per seat per year. That line climbs with every head you add.

The build line. One senior engineer, fully loaded at a government contractor blended rate, costs somewhere around $300K to $400K per year. AI tooling adds little on top: GitHub prices Copilot Enterprise at $39 per user per month, roughly $470 a year (GitHub). Round the whole package to $400K for one AI-equipped engineer, all in. That line is nearly flat. It doesn't care how many people use what the engineer builds.

A fair objection: does the AI actually make one engineer productive enough to replace a rented platform? The honest answer is that the evidence is mixed and I am not going to cherry-pick the optimistic end of it. A 2025 randomized controlled trial from METR found that experienced open-source developers were, on average, 19 percent slower with early-2025 AI tools, even though they believed they were faster (METR). But the build line does not depend on a productivity miracle. It depends on the fully-loaded cost of a small team being flat while the rent line climbs linearly with every seat. Even if the AI contributes nothing, the arithmetic below holds. If it helps at all, the crossover simply arrives sooner.

Now watch them cross.

At 100 seats, renting costs $120K a year and building costs $400K. Rent wins; it isn't close. At 500 seats, renting is $600K and one engineer is still $400K. The lines have crossed. At 2,000 seats, rent runs $2.4M against maybe $800K for a two-person team. At 10,000 seats, you're comparing $12M in annual license against roughly $2M for a five-engineer team that builds the thing and keeps it running.

There is a cost the build line has to carry that the rent line hides inside the seat price: the software has to run somewhere. When you rent SaaS, the vendor's infrastructure is baked into the subscription. When you build, you pay for compute, storage, and bandwidth directly. So price it in. A production, high-availability platform on AWS commonly runs $5,000 to $20,000 a month, roughly $60K to $240K a year, with only the largest multi-region deployments climbing into the six figures beyond that (eon.io); GovCloud adds a premium of roughly 10 to 15 percent for the federal case (VSO). Call it $300K a year at the high end for a serious government workload. Fold that in and the 10,000-seat build line moves from $2M to about $2.3M, against $12M in rent. The crossover barely shifts. Infrastructure is a real line item, but at scale it is dominated by the labor beside it and dwarfed by the rent line across from it. Where it does bite is at the bottom: infrastructure has a floor that does not shrink with your user count, which pushes the break-even point higher and makes the build case worse, not better, for small deployments.

The crossover lands somewhere around 400 seats. Below it, rent. Above it, the gap widens until it becomes absurd; at enterprise scale you can staff an entire team to build and operate the software for less than the license costs. Not build it once and walk away. Build it, maintain it, patch it, and evolve it as an annuity, and still come out millions ahead every year.

That is the thesis in two lines on a napkin. At scale, the cost delta between build and rent is now wide enough to pay for the humans who deliver and own the product.

What Renting Actually Costs the Government

The license is the number on the invoice. It is not the cost.

When you rent commercial off-the-shelf software, you don't just pay per seat. You bend your mission to fit the tool, or you pay to bend the tool toward your mission. In government, that second bill is enormous and largely invisible. The vendors are candid about the surcharges once you read past the headline seat price: Salesforce's own pricing lists API access as an added $25 per user per month on some editions and prices its Premier support plan at 30 percent of net license fees (Salesforce). Implementation and customization sit on top of that again, and you still don't own what you end up with.

The federal track record makes this concrete. The government spends more than $100 billion a year running, buying, and modernizing IT, and GAO has documented for years that these efforts too often run over budget, slip their schedules, or fail outright (GAO). The Navy's Enterprise Resource Planning system is the story in miniature. It was a commercial ERP platform, adopted in 2003 to standardize the Navy's acquisition and financial processes, and priced at roughly $2.4 billion over its useful life. By 2009, GAO reported it had already run about $570 million over budget and slipped two years behind schedule (GAO).

That overrun didn't buy new capability. It bought the privilege of forcing a commercial product to approximate how the Navy actually works, and paying, in dollars and years, for every inch of the gap. That is the cost of renting somebody else's idea of your workflow.

And the meter never stops. Between 2019 and 2023, federal agencies spent about $3.3 billion on legacy Oracle PeopleSoft and SAP HR systems, and more than half of it, $1.7 billion, went to maintenance alone, according to reporting on federal HR spending (Federal News Network). That is the part of the rent nobody quotes you up front. You don't just pay to fit the tool once. You pay, every year, to keep the ill-fitting thing alive.

You Are Funding Someone Else's Roadmap

There is an objection to the build line I have not answered, and it is the strongest one: the arithmetic above does not price in research and development. A vendor amortizes years of engineering, product design, and iteration across thousands of customers. Building in-house means carrying that cost alone. Fair.

Except the objection is the argument turned inside out. You are already paying for research and development when you rent. It is a line item in every seat you buy; it is simply not your research and development. A slice of that per-user fee funds the vendor's roadmap, the sales organization, the marketing spend, the shareholder margin, and the feature bets aimed at the next industry the vendor wants to enter. You underwrite all of it, and you direct none of it. When the roadmap points somewhere your mission does not need to go, you pay anyway. When the feature you actually require sits three quarters out behind higher-revenue accounts, you wait anyway.

That is the value you think you are getting and are not. The premium over raw hosting and support is not buying you fitness for your mission. It is buying you a minority stake in a product company, with no equity, no control, and no guarantee the product will ever fit. Build, and the same money capitalizes an asset you own, aimed at a mission only you have. The R&D does not vanish. It changes owners. The question the napkin never quite asks out loud is whose roadmap your budget should be funding: a vendor's, or yours.

Personal Software Is the Hero

Here is the term the AI community landed on for building software that fits one purpose, for one context, without pretending to serve everyone: personal software. Andrej Karpathy's framing of a new software era gave the movement its vocabulary, and vibe coding gave it a method (Latent Space). The idea is that software has gotten cheap enough to be personal; fit to you, disposable when you're done, never forced to generalize.

Government has spent decades being told it must accept the opposite. General-purpose products, built for everyone, fitted to no one, sold as the responsible choice because building your own was reckless and expensive.

That story was true. It isn't anymore.

Personal software is the hero government software needs, because the government's entire problem was fidelity. Missions don't generalize. A benefits agency, a customs office, and a defense logistics command do not share a workflow, and every attempt to force them onto a common commercial platform ends the same way: a compromise nobody wanted, customized at ruinous cost, that still doesn't quite fit.

The napkin math dissolves that constraint. At the scale most agencies operate, you can build software that represents the mission fully and accurately, not "as close as the vendor allowed," not after spending millions to twist a COTS product into a shape it resists, but real delivery, fit for purpose, in a fraction of the time, at a cost comparable to what you already pay to rent something worse.

The categories have inverted. The conservative choice used to be to buy. At scale, the conservative choice is now the one that serves the mission, because it also costs less.

Where the Vendors Fight Back

Two things save the software industry from this argument.

The first is scale, running in reverse. The crossover cuts both ways. Below roughly 400 seats, renting still wins, and it wins decisively. Small businesses and plenty of mid-tier organizations simply don't have the volume to justify a build-and-maintain team, so SaaS and platforms will keep dominating that market for the same reason they dominated all of it a decade ago. The economics haven't inverted for them. They've only inverted at the top.

This raises a genuine question. When enterprises start walking away from seven-figure licenses because they can build for a fraction of the cost, what do the platforms do about the small end they still own? Do they simply shift the abandoned enterprise cost burden downward, squeezing the businesses that can't leave to cover the revenue that just did? Or do they build genuinely new, competitive models for a market that no longer resembles the one their pricing was designed for? One of those responses is extraction. The other is innovation. The next few years will show which one the incumbents choose.

The second escape is utility. When software becomes a true utility, ubiquitous, cheap, metered, available on demand, the build-versus-rent math flips back, because the marginal cost of renting approaches zero and the burden of reliability and compliance shifts to the provider. Nobody builds their own power grid. Nobody should build their own authentication, their own object storage, their own email.

But notice what makes those things utilities. It isn't the technology. It's the standardization. Auth and storage and payments became utilities because the workflow is identical across every organization on earth. Mission software is the exact opposite; its entire value is that your mission is not identical to anyone else's. That line is the whole map. Rent the utilities. Build the mission. A general-purpose platform can never be a utility for a purpose that only you have.

Maybe the real winning outcome is that this pressure forces more of the software industry toward genuine utility form; cheap, standard, metered infrastructure that nobody needs to own. For government, that would be a gift. Rent the plumbing at utility prices. Build the mission with fidelity. Stop paying enterprise rents for a compromise.

The government has been told for thirty years that building its own software was the risky choice. The arithmetic has changed sides. The risk now sits with the agency that keeps renting a workflow that was never its own, at a price that assumed no alternative existed.

The alternative exists.