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 scoping this to just customer-reported bugs, not ones I find myself. Those just get fixed as standard deployment process. Find a bug? Fix it. But customer-reported bugs are higher priority.
I normally see around 2 customer-reported bugs a month; on average they take me about 1.5 hours to fix and get deployed.
Total Monthly Time: 3 hours
Feature Requests
“Wait!” I hear you say, “Feature requests don’t count as maintenance do they?!”
Hear me out. This isn’t all feature requests. Those just fill whatever time you have left over. These are what I call ‘functionality breakers’. They aren’t bugs. Things are operating as they were designed. But the design is wrong and your users need something else or quite frankly, they can’t use your app.
For example, “This is useless without a connection to Salesforce”. Or “IT team mandates we have an antivirus agent on all deployed EC2 instances”.
Believe it or not, some feature requests have to be considered maintenance because the needs of your users shift over time. I think it’s fair to assume half a day a month is reasonable to stay on top of those changes.
Total Monthly Time: 4 hours
Questions / Documentation
Slack messages asking how to do something, user emails asking for training, keeping documentation up to date with your changes. The more people use your app, the more they ask questions. And that’s good!
Your customer service or product marketing teams might handle this for paying customers. But for your company-specific vibe app? Unfortunately you’re the one on the line.
Total Monthly Time: 1 hour
Alert Remediation
Any reasonable deployment is going to have at least some level of alerting and monitoring. And as any DevOps engineer will tell you, even the best alerts will fire every once in a while. And when they do, you’ll need to investigate and figure out if PDF processing really is taking 8 hours per page, or if something has just stalled.
This normally happens a couple times a month with standard . Not a big deal when it does, but it takes 30 minutes or so each time.
Total Monthly Time: 1 hour
Dependency Upgrades
Ah. Dependencies. One of the truely hidden time sucks. While you may consider your app complete, the language, tools, and libraries that you used to build it aren’t.
You may be thinking to yourself, “So what. If what I have works, then why do I even need to upgrade? I’ll just leave it on the same version I built it.” Honestly, that’s the right way to think! You really shouldn’t upgrade dependencies unless you have a compelling reason to.
But here’s the problem, there are a lot more compelling reasons (and forcing functions) here than you would think. For example, vulnerability reports, EoL announcements, acquisitions, etc. And even if you keep up with all those, after a while some things just kind of fall out of support windows. Eventually you have no choice, you need to make updates.
Language
Languages are probably the easiest to keep up to date. If what you have is working, the only real forcing function here is library support.
We use two primary languages at Masset: Kotlin for the backend and Typescript for the frontend. I try and upgrade each once a year. Between upgrades, fixes and testing, it probably takes a day or two a year. So we’ll call it an hour a month.
Total Monthly Time: 1 hour
Libraries
Most often you need to update your libraries in response to vulnerability reports. In the past, this wasn’t that big of a deal. In the age of AI, the frequency of CVEs and other reports has jumped quite significantly.
NPM and the Javascript ecosystem is the biggest offender at Masset. It takes about 75% of our library vulnerability resolution time. Not because it gets more, but because the libraries tend to be more interconnected; so you have to update/override a few different packages to stay compatible with the newer versions. Kotlin/JVM dependencies also get some CVEs, but generally feel more stable and less prone to interdependent upgrades.
Believe it or not, we’re averaging between ~25 vulnerability issues a month over the last few months. And that’s for a small startup! Tools help to make this upgrade process smoother, but at that volume, it does take some time.
Total Monthly Time: 5 hours
Cloud Platform
Cloud platforms also have their own requirements for upgrading. If you don’t upgrade, your deployments will simply stop working.
We run on AWS and the most frequent required manual upgrades we see are:
- RDS database major versions
- Elasticache major versions
- ECS Fargate Task platform
These don’t hit often, but they require a lot of manual testing when they do.
Total Monthly Time: 1 hour
3rd Party APIs
Does your app use any 3rd party APIs? What about any integrations? If the answer is yes and the quantity is more than 3, you will get an email at least once a month telling you that the version you are using is going to stop working unless you make a change. Fortunately, these are normally pretty simple changes, but they are important to stay on top of.
Total Monthly Time: 1 hour
LLM Models
This is a new one that has started happening over the last 18 months. We all love getting newly released models! Newer, better, and smarter! Yay!
The downside of that quick progress is that LLM models are deprecated and removed at an equally blistering pace. At Masset, we serve most of our LLM track through AWS Bedrock models and Google Cloud Gemini. I’ve found that I have to update models pretty much every 6 months to stay ahead of deprecations and removals. Gemini on GCP is the biggest offender here.
I’ve never seen any public documentation on it, but anecdotally based on alerts, it seems that both providers will start scaling down availability on deprecated models. So even if you’re still in support windows, model providers will start throwing availability errors that magically go away once you upgrade to newer versions. So you don’t even have the luxury of waiting until the end of the support window if you care about reliability.
Total Monthly Time: 1 hour
Infrastructure Patching
Infrastructure patching is a little bit different than cloud platform upgrades. Patching is more akin to making sure your infrastructure adheres to secure best practices.
At Masset, we adhere to the AWS Foundational Best Practices, monitored by Security Hub. These controls evolve and change over time, so they require constant monitoring and updates to ensure we are compliant. To be fair, not all vibe-coded apps will need this level of compliance, but they will need compliance to something.
Also, because we are small, we try and use managed services for all deployments. If you are deploying vibe-coded apps, I recommend you do that same. But there are a few workload-specific cases where we have to unmanaged EC2 instances. In those cases, we have to manage patching. The majority of this is automatic using AWS Patch Manager, but occasionally there is some patching that needs a manual kick.
Total Monthly Time: 1 hour
Certification / Controls (SOC2, ISO, etc)
Most companies have some of certification status. That may vary per industry. For tech, most often companies have a variation of SOC2 or ISO reports (yes, I know it’s not a certification).
At Masset, despite our small size, we maintain a SOC 2 report. It’s a very common ask of our customers. So we have to adhere to certain processes, policies, and controls. We need to monitor each of those things, provide evidence, and keep them updated. It’s an ongoing process that has to be executed on a schedule. This includes things like:
- Evidence gathering
- Investigating failing controls
Now, do vibe-coded apps need to adhere to compliance requirements? That is an excellent question and likely unique to each company. Are vibe-coded apps going to be excluded from controls with unique carve-outs or scoping? I’m not sure. Right now, I’d be very surprised if any vibe-coded SaaS replacements are being included in SOC2 Vendor reviews or scoped into the audit. But if history has taught me anything, I think we’ll eventually land in a place where they are. And once they are, they will need to participate in all the fun.
This is another bursty one. To be clear, this isn’t the execution of the controls, this is just the review, monitoring, and resolution of controls. You won’t spend 2 hours on this a month, but you’ll definitely spend 24+ hours on it within a given year (mostly around audit time).
Total Monthly Time: 2 hours
Pen Testing + Remediation
Whether or not you are doing a SOC2/ISO, you really should be getting a 3rd party Pen Test done on all deployed applications. There’s simply no replacement. Once the test is done, make sure to remediate all of the issues!
This won’t be every month, but we’ll average it out over the whole year.
Total Monthly Time: 2 hours
Secrets Rotation / Management
If you aren’t rotating your secrets, you’re asking for trouble. What’s a secret? Any configuration you don’t want the public to see. Rotation requirements can vary, but you should be doing it.
If you’re running on AWS, AWS Secrets Manager helps here; especially the direct integrations it has with a lot of the other AWS platforms. But there will also be secrets that can’t be rotated automatically. Often these are secrets that are integrations to other platforms, making them extra sensitive.
At Masset, we do a monthly secret audit / manual rotation. During that time block we confirm automatic rotation is happening properly and rotate any secrets that need manual intervention for that month.
Total Monthly Time: 2 hours
Security Incidents
Ah yes, even more time spent on security. We’ve already covered upgrades from scanning, secret rotation, patching and a bunch of other implied things. So what’s left?
Well, what if you did everything right, but once of your 3rd parties had a breach? Or one of your dependencies had a Supply Chain Attach (SCA)? You get to deal with the fallout.
Thankfully these don’t happen often (although shocking more frequent in 2026). But when they do, they are “drop-everything and go full time on this” issues. And often they take multiple days to properly investigate/resolve.
To be clear, security incidents aren’t only fired when you are actually affected. They fire when you might have been affected. So whether or not you fell victim in a SCA, you have to do the investigation to determine if you were. If you did fall victim, then the time invested gets even worse.
I’m going to be gracious on this estimate. If current trends of 2026 continue, this number will be much higher by the end of the year. But I’ll be nice and estimate based on 2025.
Total Monthly Time: 2 hours
Vendor Reviews / Audits / Infra Tests
Not included in the previously described certification section is the actual work to meet the controls (or just be a good technical steward). Most of these things should be done whether you’re getting a certification or not, but to be 100% fair, most companies don’t do them unless they are required to.
This includes things like:
- Disaster Recovery Tests
- Backup Management and Tests
- Access Reviews
- Vendor Reviews
This is another bursty one. You won’t do a Disaster Recovery Test every month or review all your vendors every month. But you’ll easily spend at least 24+ hours a year doing it.
Total Monthly Time: 2 hours
Conclusion
Wow. We made it to the end. I’m sure I forgot some really important things that I do to maintain Masset, but that list are the ones that came top-of-mind.
Here’s a summary of those different tasks in table form.
| Maintenance Task | Hours/Month |
|---|---|
| Bug Fixes | 3 |
| Feature Requests | 4 |
| QA / Documentation | 1 |
| Alert remediation | 1 |
| Dependency Upgrades | 9 |
| Infrastructure Patching | 1 |
| Certification / Controls | 2 |
| Pen Testing + Remediation | 2 |
| Secrets Rotation / Management | 2 |
| Security Incidents | 2 |
| Vendor Reviews / Audits / Infra Tests | 2 |
| 29 |
As you can tell, there’s a lot more to maintaining an application than just updating code with bug fixes. In reality, bug fixes are around 10% portion of the time I invest into Masset maintenance. Assuming a 160 hour work month (I’m a founder, I wish that were true…), I spend about 18% of my time on maintenance related tasks.
You’ll also notice that I didn’t include anything related to “prevent code rot”. I went back and forth on that one. I don’t mean to sound derogatory at all, but I honestly don’t feel that most vibe-coded apps will do anything to fight code-rot (refactors, cleanups, simplifications, etc). Vibe-maintainers will likely operate in a mode closer to set-it-and-forget-it, so I thought it was fair to leave any my own time doing that off.
In the end, if my estimates are correct, I spend 29 hours maintaining Masset a month. Honestly, that feels both a bit high and a bit low depending on my mood any given day.
There’s a real scenario that people are just better at this than I am, and obviously there are process optimizations that could be made, so let’s cut that number by 25% as a “better than Tyler tax”. That gets us to to just under 22 hours a month. So based on my very, very terrible math, single engineer is likely to be able to maintain 160/22 = ~7 apps a month if they are doing nothing else but maintaining them.
So companies would need to hire 1 technical employee per 7 SaaS apps they are replacing. Not a terrible ratio. And depending on the cost of the SaaS app, and the cost of labor in their market, that may or may not be worth it.
Or, the more likely scenario in my mind: most of the necessary tasks to maintain an app will be left undone in order to save time and energy. I anticipate that a lot of vibe apps are going to be left with insecure libraries or out-of-date frameworks. I hope in that scenario they aren’t running in publicly accessible networks. 🤔
Follow up
You’ll notice that I didn’t take the next step and evaluate the estimated monthly cost to maintain an app. There are a number of reasons for this. Obviously it ties in the cost of a developer, which is hard to calculate, but it also includes a lot of costs that are not directly associated to time spent. It costs much more in $/month to maintain Masset than simply my time spent. There’s also costs associated with vendors, hosting, audits, etc. I’d love to assign costs to each of these tasks and calculate what I believe is the new MRR SaaS floor. Stay tuned for that.