What running SaaS actually costs after launch

Launch is the cheap part. It has a scope, a date, and an invoice. What follows has none of those, which is why it gets left out of the budget.

The costs that arrive after launch

A running SaaS product needs, every month, whether or not anyone ships a feature:

• Dependency updates. A Laravel and Vue application pulls hundreds of packages. Left alone for a year, upgrading stops being a chore and becomes a project.
• Security patching. CVEs do not wait for a convenient sprint.
• Backups you have actually restored. An untested backup is a hope, not a backup.
• Monitoring and alerting. Knowing a queue has stalled before a customer tells you.
• On-call time. Someone has to be reachable when a payment webhook starts failing at 9pm.

None of this is visible in a demo. All of it is the difference between software that runs for five years and software that quietly rots for eighteen months and then needs rewriting.

Why we price maintenance separately

We put support and SLA work on its own line because bundling it hides it. When maintenance is folded into a build price, the first thing cut under pressure is the invisible half. Then the rewrite lands two years later and costs more than the original build.

A separate line is harder to sell and easier to defend.

What we do about it

Every system we hand over ships with the operational parts already in place:

  

    text
    
      Copy
    
  
  
CI on every push          tests + build must pass before deploy
Staging that mirrors prod  same runtime, same migrations
Automated backups          with a documented restore, tested
Uptime + error monitoring  alerts to a human, not a dashboard

  

That is not a premium tier. It is what “we run it” means.

The question to ask a vendor

Not “what will it cost to build”. Ask what it costs to keep running in year two, who is on call, and what happens when they are not available. A vendor who has not thought about it will improvise an answer, and the improvisation is the answer.