You needed user authentication, so you described it to an agent and had a working version by Sunday night. Sessions, password reset, OAuth, the lot. It felt like getting something for nothing, and in a way it was, because the writing really was free. The part nobody quotes you on is the next four years of owning the thing you just generated.
For most of software history, the hard part of any feature was producing it, and that cost quietly did the deciding for you. Anything tedious enough to build was tedious enough to make you ask whether you should just pay someone else to have already built it. AI removed the tedium, and with it, the question. Code is cheap to write now and exactly as expensive to own as it has always been, and most founders are making build-or-buy calls against the price tag that vanished instead of the one that stayed.
| The part that got cheap | The part that didn't |
|---|---|
| Writing the first version | Maintaining it for years |
| Boilerplate and scaffolding | Security patches and dependency updates |
| Wiring up a known pattern | The edge cases you only find in production |
| The weekend build | The 3am page when it breaks |
The cost you can see collapsed. The cost you can't didn't.
The build estimate you react to is almost always the small number. The number that actually decides whether a piece of software was worth making shows up later, spread across years, in a place you weren't looking when you said yes.
Where the money actually goes
Industry estimates have held the same shape for decades: somewhere between half and ninety percent of a piece of software's lifetime cost lands after the first version ships. Building happens once. Maintenance runs for as long as the thing is alive. A system that costs a hundred thousand to build and twenty thousand a year to keep running has doubled its real price tag by year five, and none of that second hundred thousand appeared in the estimate that got it approved.
Why AI widens the gap instead of closing it
Generated code does not arrive maintenance-free. It arrives as more code, faster, which is more surface to patch, more dependencies to track, and more behavior you will have to understand later without the memory of having written it. The cheaper generation gets, the more of it you accumulate, so the maintenance base grows underneath you while the build cost keeps falling. The two lines move in opposite directions, and only one of them is on a dashboard you check.
⚠️ The hidden ledger: Every feature you generate adds to a maintenance balance nobody ever quotes you. The writing was free. The owning compounds, quietly, every month the code stays in production.
"I could just build this" is now the most expensive sentence
That sentence used to be a harmless fantasy. You would see a tool charging forty dollars a month, think you could build it in a weekend, and then not, because the weekend was real and forty dollars wasn't worth it. Now you actually can build it in a weekend, so you do, and you have just adopted a commodity system you will maintain forever to dodge a subscription that would have stayed someone else's problem.
Commodity work versus the thing you actually sell
The line that matters did not move just because building got cheaper. Some code is the reason customers pay you. Most code is plumbing that every company needs and no customer will ever thank you for. Auth, billing, email delivery, file storage, an admin panel: nobody chose your product because your password reset flow was bespoke. Building commodity plumbing was a costly mistake when it took a month, and it is a quieter, cheaper-feeling version of the same mistake when it takes a weekend, because the maintenance bill at the end is identical either way.
| The work | Default move | Why |
|---|---|---|
| Commodity plumbing (auth, billing, email) | Buy | Maintenance is forever, differentiation is zero |
| Your actual product surface | Build | It's the reason anyone pays you |
| Adjacent but not core (analytics, support) | Buy now, build later if it turns strategic | Don't own what you can rent until you know it matters |
💡 A quick test: If a competitor having the exact same implementation would cost you nothing, it's commodity. Buy it. Save the building for the parts where being identical to everyone else would actually hurt.
Decide on the ten-year line, not the weekend
The build-or-buy call goes wrong when you line up the wrong two numbers. A weekend of agent time against a yearly subscription looks like an easy win for building, right until you remember the subscription includes the vendor's entire maintenance, security, and on-call operation, and your weekend build includes none of it.
You're not comparing a weekend to a subscription
You are comparing a decade of your ownership to a decade of theirs. Priced honestly, the questions to answer before you generate the thing are these:
- Who patches this the night a dependency gets a critical vulnerability?
- Who owns the edge cases you will only discover once real users hit it?
- What does keeping this alive pull your attention away from every week it runs?
- If it breaks while you are shipping something that matters, who even notices?
None of those costs show up in the weekend. All of them show up later, and they are paid in the one currency a small team cannot print, which is founder attention.
🔑 The reframe: Cheap to build is not cheap to own. Price the build on what it costs to keep alive for years, then set that next to the cost of buying. Most commodity systems lose that comparison badly.
When building is still the right answer
None of this is an argument against building. It is an argument for spending your scarce ownership on the things that earn it. Build the parts that are the reason you exist: the workflow, the model, the interface a customer would switch to you for. Build when the off-the-shelf option genuinely cannot do the job, not when it can and you would simply enjoy doing it yourself.
The crossover is real, just further out than it feels
There is a point where buying stops being cheaper. Heavy usage, where a vendor's per-unit pricing finally exceeds what running it yourself would cost, is a real reason to bring something in-house. But that point arrives later than the weekend you are tempted to spend right now, usually well past the scale most early products ever reach. Cheap inference and cheap building nudged the line, and for a young company the safe default is still to rent the commodity and own only what makes you different.
🔑 The takeaway: AI changed what's cheap to make, not what's expensive to keep. Build the thing customers pay for, buy the thing they never think about, and price every build on the decade of ownership rather than the weekend of writing.
FAQ
Doesn't buying everything leave me dependent on vendors?
Some dependency is the price of not maintaining commodity infrastructure yourself, and for plumbing like auth or billing it's a good trade. The risk worth managing is lock-in on something core to your product, where a vendor going away or changing terms would genuinely hurt. Concentrate your independence there. Renting a password reset flow is not the dependency that will sink you.
Can't AI just maintain the code too, so ownership gets cheap as well?
It helps, but maintenance was never mostly about typing. It's about noticing a dependency went critical, understanding a production edge case, deciding whether a fix breaks three other things, and being on the hook when it does. AI can assist each of those, and none of them stop being your responsibility. The attention cost is the expensive part, and that part did not get automated away.
How do I tell commodity from core in my own product?
Ask whether a customer would ever choose you because of it. If a competitor shipping the identical implementation costs you nothing, it's commodity and you should buy it. If owning it is part of why someone picks you, or it touches the thing you're uniquely good at, that's core and worth building. Most of your codebase is commodity, which is the uncomfortable part.
Isn't a stack of subscriptions its own expensive, sprawling problem?
It can be, and it's worth auditing what you pay for. But a subscription you can cancel in a click is a far lighter liability than a system you must patch, secure, and understand forever. Compare the monthly fee against the loaded cost of owning the same thing, including your time. For commodity work, the subscription usually wins by a wide margin.
What about the learning value of building it myself?
Learning is a real reason to build, just be honest that it's the reason. Building your own auth to understand auth is a fine use of a side project and a poor use of the runway on a product you're trying to ship. Separate the two. Learn on something that isn't load-bearing, and buy the load-bearing commodity you can't afford to babysit.
The weekend build feels like a gift because the cost arrives on a delay. By the time the maintenance shows up, the excitement that made you build it is long gone, and you are patching a thing you barely remember writing to save money you were never really spending. Generate the parts that make you different. Pay someone else to own the rest. The cheapest code you will ever run is the code that is somebody else's job to keep alive.