AI cut the cost of building software. It did not cut the cost of owning it, and that is the larger number.

IAH

Bottom line. Before replacing a SaaS tool with something you build, price the maintenance rather than the build. Assign a named owner and a budget line for the years after launch. Then pick which failure you can live with: a vendor changing terms on you, or an internal app nobody owns eighteen months from now. Build when the tool touches something specific to how your company works. Buy when it does a job every company does the same way. The vendor splits that maintenance cost across thousands of customers. You would pay all of it.

Why this is worth revisiting now: AI collapsed the cost of the build and left the cost of ownership almost untouched. Maintenance runs 60 to 80 percent of a system’s lifetime cost, and it always has.

Four hours

I published an article to Medium and their automated systems flagged my account for suspension within minutes. I filed a support ticket. The response took about seven hours, and the flag turned out to be a false positive. Medium sorted it out and my account is fine as you are reading this right now.

During those seven hours, I built a replacement. Working with Claude Code, GPT 5.6 Terra in VS Code, and Firebase, I put up fettink.com, where I publish my own writing. No third party holds the switch. It took under four hours to code and deploy, and then a few more hours here and there to work out the bugs; however, between the ban on Wednesday and the writing of this article, set to publish on the following Tuesday, it was up and operational. The feature set I needed was small, and small is the operative word.

It is not finished, and on its own, it would cost me the distribution that comes free with a platform. Nobody discovers my site the way they discover a Medium tag page. As a stopgap, it worked, and a working stopgap inside a single afternoon would have been unthinkable a few years ago.

Nobody did anything wrong. A classifier misfired, and the outcome was seven hours of not being able to reach my own archive. That is the ordinary operating risk of building your work on someone else’s platform, and it does not require anyone to act in bad faith. It only requires a false positive on any given day.

I did not replace Medium, and I do not think that is the right goal. I publish to all three now: LinkedIn, Medium, and my own site. Two of them get me readers. The third stores everything. That arrangement costs me one extra paste per article and removes the single point of failure entirely.

Owning the canonical copy also opens up things a platform will not do for me. I want the scrollstories and the other formats I have been working on aggregated in one place, alongside the essays, under one domain I control. No publishing platform is going to build that for an audience of one.

The four hours are the number in the headline. The harder question is what it costs to still be running this in 2031.

No product fits any customer

No SaaS product is a complete fit for any customer, and it cannot be.

A vendor builds for the median of their market. That is the correct business decision, and it produces a product that fits the median customer well and the rest of us approximately. (There is another tangent where the median may not represent a customer but that’s a different article altogether.) Your workflow has a step theirs does not model. There is a compliance field their schema lacks, and a report their dashboard will not cut. So you adapt your process to the tool, or buy a second tool to cover the gap. Or you keep a spreadsheet beside the system of record and try not to think about it.

That gap has always been there. Closing it used to require a project, a budget, and a team, which made tolerating the gap the rational choice almost every time.

The build got cheap

One side of the ledger moved, and it moved a long way. Someone with a clear idea of what they need can produce a working application in an afternoon. The same work took a quarter of engineering time three years ago.

The other side did not move nearly as much.

Maintenance has consumed the majority of software lifetime cost for as long as anyone has measured it. Lientz and Swanson established the pattern in 1980, Boehm in 1981, Glass in 2002, and the figure most commonly cited sits between 60 and 80 percent. Cloud-hosted applications run lower than on-premises systems, roughly 30 to 60 percent against 70 to 90. Even the low end makes the build a minority of what you spend.

Think of the build as a down payment against a mortgage you pay for years.

Maintenance is mostly not bug fixing

The word suggests bug fixing, which is the smallest part of the work. Lientz and Swanson’s breakdown has held remarkably stable across four decades of follow-up studies.

Roughly half of maintenance effort is perfective: performance work, refactoring, usability improvements, small features missing from the first release. About a quarter is adaptive, meaning keeping the software working while the world around it changes. Operating system upgrades. Framework updates. API deprecations at services you depend on. New regulations. Less than a quarter is corrective, the actual bug fixing. Preventive work is about three percent.

Adaptive maintenance is the line item that surprises people, and my four-hour site produced its first bill within a week.

The migration brought my article images across as links to Medium’s image CDN. Every thumbnail on the site I built to stop depending on Medium was being served by Medium. Nothing was broken. Everything rendered. The dependency would have sat there quietly until some future change on their end. Then the whole archive loses its pictures, at a moment I did not choose.

The fix was straightforward: pull the images down, move them to my own storage, redeploy. Call it an hour. That hour is not in the four.

Nothing about it was a bug in my code. It is the ordinary condition of software that touches other software. Firebase will deprecate something. A dependency will publish a breaking change. A certificate will expire on a Sunday. The work arrives whether or not I have time for it. A project ends. This does not.

Why buying won for so long

Buying was never about difficulty. It rested on amortization. Vendors spread development, operations, and compliance costs across their entire customer base. A 2026 analysis of the buy-or-build decision under agentic AI puts it directly. That cost asymmetry has historically strengthened the case for buying, because the vendor splits maintenance across thousands of customers and you would pay all of it.

Read that against the four hours. AI cut my build cost by something like ninety percent. It did not give me a thousand other customers to split the mortgage with.

The amortization advantage is the durable part of the vendor’s value, and it is untouched by better coding tools. AI moved the threshold at which building becomes worth doing. That is a real change and a narrower one than the excitement suggests.

The constraint moved

Anyone who has read Goldratt will recognize the pattern. Break one bottleneck and another takes its place somewhere else.

Building was the constraint on internal tools. It has been broken, thoroughly, and the queue has moved to the next stage. The next stage is ownership: patching, upgrading, monitoring, answering the pager, keeping compliance current. It also means knowing enough about the system to change it safely two years after its author moved to another team.

Organizations that celebrate the broken constraint without staffing the new one will produce a lot of applications and a maintenance liability nobody budgeted.

Who owns it inside a company

Per-seat SaaS pricing includes something invisible. The vendor patches the security hole and renews the certificate. They keep the integration working when the upstream API changes, employ the compliance staff, hold the SOC 2 report, and answer the phone at 2am. None of that appears on the invoice as a line item, and all of it stops the moment you replace the tool with your own.

So the question for any enterprise considering this is not whether their people can build the thing. Increasingly they can, faster than procurement can run an evaluation. The question is whether the organization has anyone whose job includes owning it afterward.

Most do not, and the reason is structural rather than negligent. Per-seat software does not require an internal owner, so no headcount was ever allocated for one. Replace ten SaaS tools with ten internal applications and you create a maintenance workload no existing role absorbs. It falls to ten people who each built one thing on top of their actual job.

That is how shadow IT gets made. This time it will arrive faster and look more legitimate, since the applications will be genuinely good.

Can agents maintain it

A fair counter: if agents can build, maybe agents can maintain. Partly.

Agents handle mechanical maintenance well already. Dependency bumps, patch application, test coverage for a change, and tracking down why a build broke are all tasks with a checkable right answer.

What does not delegate is ownership. A person decides whether a breaking change gets absorbed or worked around, and answers when a regulator asks how the customer data in it is protected. A person gets paged. And a person knows why the odd thing in the code is there and whether removing it is safe. Those are judgment and accountability, and no tool available today does either one.

Realistically, agent assistance lowers the maintenance cost without taking it to zero. The threshold moves again. The question does not go away.

How I would decide

Four questions, roughly in order of how much they matter.

Is this specific to how we work, or does every company do it the same way? Specific work is a build candidate, since the vendor built for the median and you are not the median. Payroll, email, and accounting are not build candidates. Being able to build them is not a reason to.

Who owns it in year three? Answer with a name and a percentage of that person’s time. If you cannot name them, you are deciding to build and then abandon, which ends worse than either alternative.

What is the blast radius when it breaks? A tool that inconveniences one team when it fails is a different proposition from one holding customer data or sitting in a revenue path. Compliance obligations, in particular, do not scale down for internal tools.

What does the exit look like? Vendor lock-in is well understood. Internal systems lock you in too, through undocumented decisions and departed authors. That lock is often tighter, since there is no vendor to call and no migration guide to buy.

My site passes the first question, and on the third, nothing much breaks if it goes down. The second answer is honest: the owner is me, and the day that stops being true, the site stops. For a personal publishing site that is an acceptable answer. For a system a hundred people depend on it is not an answer at all.

Build specific, buy generic

The build-versus-buy calculation genuinely changed, and it changed in one direction: more things are now worth building than were worth building three years ago. That is a real shift and it will keep moving.

It did not become a different question. The costs that dominate a system’s life still arrive after launch. They are still mostly adaptive and perfective rather than corrective, and they still fall on whoever owns the thing. A vendor has thousands of customers to spread that across, and you have none.

Build the things that are specific to you. Buy the things every company does the same way. And before either, write down who owns it in three years, because that answer decides more about the total cost than the build ever will.