Maintenance is more than bugs – tylerrussell.dev

19 May 2026

Maintenance is more than bugs

Reading Time: 15 minutes<br>Replacing business SaaS applications with vibe-coded equivalents has been a topic of conversations for a long time now. But it feels like the build-vs-buy pendulum has truly swung to the "buy" apex in the last few months. Improvements in frontier models over the last six months combined with general-public adoption of AI-coding tools has led to a crescendo where companies are actually starting to replace their SaaS tools.

I’ve talked to a lot of business owners lately, both inside and out of work. And a lot of them are ecstatic about replacing their SaaS tools with vibe-coded alternatives. And rightfully so! I’ve long believed that the SaaS market has overcharged companies for the last decade. So good on exploited businesses for pushing back!

What was once a hypothetical for SaaS providers is becoming very, very real. To be fully transparent, at my company Masset, we’ve lost a few deals to vibe-coding. I’m not writing this based on assumptions. I’m seeing it personally.

One thing I have consistently seen in most of these discussions is a lack of understanding of what maintaining a technical application actually entails. In most people’s minds, maintenance = bug fixes.

I’ve tried to explain to people why I feel like there is a floor on SaaS pricing due to ongoing maintenance costs. At a certain point, it makes more sense for a company to pay someone else to do it for them. Vibe-coding has drastically lowered that number. But it’s still not zero.

Whether people will pay employees, consultants, or SaaS providers to do the maintenance, the jury is still out. I’m not going to debate whether SaaS is actually dying or not. I’ll save that for a different article. But the fact remains that there are costs that have to be paid to maintain software, and most people don’t have a great idea of what they actually are.

So in an effort to broaden understanding (and hopefully prevent some unnecessary consulting spend), I thought I’d share from personal experience what it takes for me to maintain my own SaaS application, Masset. I hope this provides a bit of insight into what software developers say when they talk about "maintenance costs".

Tyler’s Tangential SaaS Prediction

The build vs buy pendulum will swing back to equilibrium eventually. The real question is if SaaS companies can remain solvent long enough for that to happen.

My bet is that SaaS won’t die, but >40k ACV SaaS contracts will be a thing of the past, especially if said contracts are user-hostile (multi-year lockins, etc).

Scoping our comparison

Before we get started here, let’s touch on vibe-coding. I won’t belabor the point: vibe-coding is an industry-changing approach that is radically changing how software is written. What was once gate-kept behind years of learning is now easily accessible all non-technical users. Amazing.

There is only one problem. Vibing is faster because it ignores… well, pretty much everything that software engineers have been trained to do for the last three decades. I would go as far as to say that if measured by the same metrics, most engineers could 2-3x their output by ignoring the same things that vibe-coding ignores.

SDLC ? Don’t need it. Two sets of eyes for all code reviews ? Nope, single reviewer is fine now. QA, Security Review, Architecture Review, other reviews? Nah, just have more agents look at them. Pen Testing? What’s that? Cloud audits? Backups? Data Sharing agreements? User Access Reviews? SCA remediatations? Package updates? I could go on, but you get the idea.

And guess what? The hammer will drop soon. I don’t know which vibe-app governance platform will win. But it’s coming, and it’ll cause a lot of lost "velocity." IT teams won’t let this freedom (*cough* shadow IT *cough*) last forever. Vibe-apps will be forced to conform.

So why do I call this out? Well, for a comparison of maintenance costs to be truly fair, we have to acknowledge that not all vibe-coded apps will need to hit these requirements. They should, but they won’t.

But for our comparison here, we’re going to assume they will. If engineer-written apps have to abide by these requirements, all apps should, right? So if you feel like the maintenance requirements outlined here are too burdensome, maybe consider if they should be changed universally.

What it takes to keep an app running

So without further ado, here are the things that I spend my time on at Masset that I classify as maintenance tasks. Obviously the amount spent on each task varies per day, week, and month, but I’ve tried my best to calculate a general hours/month metric for easy comparison sake.

As engineers tend to do, I generally underestimate the actual amount of time it takes to do things. So in all reality, these number are probably higher.

Bug Fixes

Alright, let’s knock the easy one out of the way. Bugs happen, they need to be fixed. I’m...