Software Maintenance Is More Than Bug Fixes

I've sat through a lot of build-vs-buy conversations this year. The case for vibe-coding a SaaS replacement is real. Frontier models are good. Tooling is good. A non-engineer can ship something that does roughly what a $20k/year SaaS app does in an afternoon.

What's missing from those conversations is what happens after the app ships.

Almost every build-vs-buy spreadsheet I've seen has a line called "maintenance." Almost every one of them treats it like a synonym for fixing bugs.

That's not what maintenance is.

At Masset, bug fixes are about 10% of the time I spend keeping the app running. The other 90% is everything else. And the everything else is what decides whether a vibe-coded replacement actually holds up.

Here's the rough breakdown of what I spend my time on every month keeping Masset running.

These are categories of work, not specific tickets. The hours are honest monthly averages. Some months are quiet. Some months are on fire.

A few things to notice in that table.

Dependency upgrades are the biggest line by far. We're seeing about 25 library vulnerability reports a month. The npm side eats roughly 75% of that work. The package graph is so interconnected that you can rarely update one package without updating three others to keep them compatible.

Add language version bumps. AWS major-version upgrades. Third-party API deprecation emails. LLM model deprecations (Gemini and Bedrock both rotate aggressively now). You're looking at most of a full work day every month. Every month. Forever.

Security work shows up four different times. SOC 2 evidence, pen testing, secrets rotation, and incident response are all separate categories. None of them is optional once you have real customers. None of them is a "bug fix."

The "bursty" categories are still in there. You don't run a disaster recovery test or get pen-tested every month. But you have to amortize them somewhere or the spreadsheet lies.

Twenty-nine hours a month is about 18% of a notional 160-hour work month. That number probably feels both high and low depending on the week.

Be generous. Assume someone else is 25% more efficient than I am. Call it a "better-than-Tyler tax." The number drops to about 22 hours a month.

That gives you a rough ratio. One engineer doing nothing but maintenance can keep about seven apps alive. 160 ÷ 22 ≈ 7.

That's the real build-vs-buy math. If you've vibe-coded replacements for ten SaaS apps, you need at least 1.5 engineers whose only job is keeping them running. If you want those engineers to also build new things, you need more headcount or fewer apps.

For some companies that math works. For most, it doesn't. Especially when the engineers you'd hire to maintain vibe apps would much rather be building something new.

Here's the honest prediction. Companies aren't going to hire seven-app maintainers. Most of the maintenance just won't get done.

Most vibe-coded apps will be left with insecure libraries and out-of-date frameworks. Most will skip pen tests. Most won't rotate secrets. Most will be running unpatched cloud infrastructure on whatever managed service the model picked at scaffold time. A lot of them will be running on publicly accessible networks while doing all of that.

That's not a knock on vibe-coding. Vibe-coding is a genuine industry-shifting unlock. The people using it are mostly right that the SaaS market has overcharged for years.

But "I built it in an afternoon" and "I'm responsible for it forever" are different sentences. A lot of build-vs-buy decisions in 2026 are pretending they're the same.

There's another prediction worth saying out loud. A vibe-app governance shoe is going to drop. IT and security teams are not going to let shadow-coded apps sit untracked in the enterprise forever. When that hammer falls, the work in the table above stops being optional and starts being audit-required. That's the moment the maintenance bill becomes visible.

None of this means SaaS pricing stays where it is. Vibe-coding has lowered the floor on what a small SaaS can charge. The spread between "build it yourself" and "pay a vendor" used to be enormous. Now it isn't.

But the floor isn't zero. Every line in that table is a real cost. Somebody pays it. An employee, a consultant, or a SaaS vendor amortizing across a customer base. The question is just who pays and how it's priced.

Here's my bet. SaaS doesn't die. The part that dies is the $40k+ ACV multi-year contract with lock-in pricing. The middle of the market wins: flat, fair, monthly, easy-out.

This post is a summary. The full essay walks through every line in the table with examples. npm CVE rates. AWS RDS major-version pain. The specific LLM model providers that quietly throttle availability before they deprecate. What a SOC 2 audit week actually looks like.

If you're weighing a vibe-coded replacement, it's worth your time.

Read the original: Maintenance is more than bugs on tylerrussell.dev.

A follow-up is coming that puts dollar amounts on each of these categories. We left the math out here because the labor and vendor costs deserve their own breakdown.