In the next four weeks, .NET 8, .NET 9 and PostgreSQL 14 all reach end of support [O24, O26]. Nobody sends you an invoice for that. But someone on your team has to stop what they're doing and run the upgrade, and that's what running a SaaS product actually costs.
If you've just paid to get your product built, the cost of running a SaaS is the part of the budget nobody put in the proposal. We covered the first bill in what it costs to build a SaaS startup. This post is about the second one. It arrives every month after launch, and you mostly pay it in people's time.
The cost of running a SaaS is what you spend every month to keep a live software product working, secure and supported after launch: hosting, plus the people's hours for monitoring, bug fixes, patching, upgrades, backup tests, access reviews and support.
Key takeaways
People's hours. The median private B2B SaaS company spends 5% of its annual recurring revenue (ARR) on hosting, 9% on customer support and success, and 22% on R&D [O14].
That's from SaaS Capital's 2026 survey of more than 1,000 companies [O14]. In the $3–5M ARR band, support and success rises to 10% while hosting stays at 5% [O43]. Put another way: for every dollar a typical SaaS company sends its cloud provider, it spends nearly two on the people who answer customers, and more than four on the people who build and fix the product.
Most founders still judge SaaS operating costs by the cloud invoice, because it's the one that arrives with a number on it. Public companies show why that misleads. The median public enterprise SaaS company ran a gross margin of nearly 77% in 2025 [O16]. One public software company's annual filing describes its cost of revenue as "allocated cloud-hosting costs" plus customer support staff, contractors, payment processing and overhead [O17]. Hosting and people sit in the same line, and the line isn't mostly servers.
The people cost doesn't wait for customers, either. A lot of it lands on day one.
Here's the list nobody hands you at launch. Every item on it is a job someone does by hand:
None of these is a project with an end date. They come back every week, every month, every quarter.
Collecting logs costs almost nothing. Azure Log Analytics charges $2.30 per GB ingested after the first 5 GB [O1]. AWS CloudWatch Logs charges $0.50 per GB for standard ingestion, with 5 GB a month free [O3]. Google Cloud Logging lists $0.50 per GiB, and the first 50 GiB per project each month are free [O4]. For a young product, that bill is often zero.
The expensive part is the person reading them. Google's SRE book has a name for this kind of work, "toil", and defines it as work that is "manual, repetitive, automatable, tactical, devoid of enduring value, and that scales linearly as a service grows" [O7]. Google's own goal is to keep toil "below 50% of each SRE's time" [O7]. Think about that for a second. One of the most automated companies in the world is aiming for half.
And it isn't shrinking. A vendor-published SRE survey found the median share of time spent on operations work rose from 25% to 30% in its 2025 report [O8]. That was the first rise in five years [O8]. The report notes the general expectation had been that AI would reduce toil, and says: "The jury is still out" [O8]. Another vendor-published survey of on-call engineers found respondents were paged an average of 6 times a week [O49]. That's six times a week someone drops what they're doing to go and look.
Software doesn't stop needing work once it ships. It just stops being called "the build".
Robert Glass, in Facts and Fallacies of Software Engineering, put maintenance at 40 to 80% of software costs, with an average of 60% [O10]. The US Government Accountability Office reports that federal agencies spend about 80% of their IT budgets on operations and maintenance of existing systems [O11]. That's government IT, not SaaS, but it points the same way.
Stripe's 2018 Developer Coefficient report gets closer to a normal week. Developers spent 17.3 hours of an average 41.1-hour week on maintenance: debugging, dealing with bad code, refactoring and modifying [O9]. That's about 42% of their week.
Not all of it is waste. An older study found that roughly 60% of maintenance effort went on improvements, and only about 17% on fixing bugs [O12]. So a lot of "maintenance" is really the work of keeping the product worth paying for. Someone still has to pay for it.
There were 48,185 published software vulnerabilities (CVEs) in 2025, up 20.6% on 2024 [O18]. That works out at about 132 new ones every day [O18]. Most won't touch your product. Someone still has to check which ones do.
And the clock on the ones that matter is getting shorter. In June 2026, the US Cybersecurity and Infrastructure Security Agency (CISA) replaced its two-week patching deadline for federal agencies [O19] with a risk-based model. Under it, a vulnerability that is internet-facing, known to be exploited, automatable and gives an attacker control must be fixed "within three days" [O20]. That rule binds federal agencies, not you. But a law-firm analysis expects it to show up in government contracts and in cloud providers' own patching rules [O20], so a version of that clock can reach you through your bigger customers.
The hours add up. A vendor-commissioned study of 500 organisations with more than 250 staff found seven in ten spend more than 6 hours a week on patching [O51]. Another vendor-published report found 80% of application dependencies go un-upgraded for over a year, even though more than 99% have newer versions available [O52]. Nobody decides to fall behind. It's just a backlog nobody got to.
Then there are the annual checks bigger customers ask for. Vendor-published pricing puts a web app or SaaS penetration test at $5,000 to $30,000 [O21]. Vendor-published auditor fees for a SOC 2 Type II audit run from $5,000–20,000 for a small company to $40,000–60,000 for a large one, and that's before your own team's preparation time [O22].
Everything you build on has an expiry date. .NET long-term support releases get three years of patches, and short-term releases get two [O24]. PostgreSQL gives each major version five years [O26]. Node.js long-term support releases get critical fixes for about 30 months [O25]. Kubernetes is the restless one: roughly 14 months of support per version [O29], with about three new versions a year [O29].
The Oct–Nov 2026 upgrade cluster
Software End of support Python 3.10 1 Oct 2026 (already passed) [O28] Kubernetes 1.34 27 Oct 2026 [O29] .NET 8 (LTS) and .NET 9 (STS) 10 Nov 2026 [O24] PostgreSQL 14 12 Nov 2026 [O26] If your product runs on any of these, the upgrade work is already due.
Missing the date costs money too. On Amazon RDS, running a database engine past its standard support adds an Extended Support charge per vCPU per hour, starting "the day after the end of standard support" [O6]. AWS's US East example is $0.100 per vCPU-hour in year one, rising by year three [O6]. Standby copies are charged too [O6]. On a 4-vCPU database that's about $290 a month (our calculation: 4 × 730 hours × $0.10). Upgrading stops the charge [O6]. In other words, somebody's hours stop it.
Almost every product has backups. Far fewer have proof they work. CISA's ransomware guidance, co-authored with the FBI and NSA, tells organisations to "regularly test the availability and integrity of backups in a disaster recovery scenario" [O32].
The cloud makes the test itself cheap. AWS Backup charges $1.50 per recovery point evaluated in a restore test [O5]. What costs money is the engineer who schedules it, checks the restored data is complete, writes it up, and fixes whatever didn't come back. That's an afternoon, not $1.50.
A tenant is one customer account on your product. To show how running costs move as you grow, we built a simple model. Where published data exists, we cite it. Where it doesn't, the figure is labelled as our assumption. We've left hosting out, because the 5%-of-ARR benchmark already covers it [O14].
Illustrative model (our calculation)
| Per month (excl. hosting) | 10 tenants | 10,000 tenants |
|---|---|---|
| Fixed run work (40 h → 120 h at $93/h) | ~$3.7k | ~$11.2k |
| Pen test + SOC 2, annualised | ~$1.9k | ~$6.7k |
| Support tickets (0.25/tenant × $24.24) | ~$0.06k | ~$60.6k |
| Log ingestion (cloud-native) | ~$0 | ~$0.45k (Azure ~$2.1k) |
| Bug fixes & small improvements (42% of dev spend) | ~$13.6k | ~$92.4k |
| Total | ~$19.3k (~$1,930 per tenant) | ~$171k (~$17 per tenant) |
Inputs:
What the model shows:
Look at what barely shows up in either column: the logs themselves. Storing them is cheap. Reading them is the cost.
The best argument against all this is that the cloud now does much of it for you. AWS's own guidance recommends managed services "to reduce your security maintenance tasks", and says Amazon RDS "automates administration tasks such as hardware provisioning, database setup, patching, and backups" [O35]. Small teams can run very large services, too. WhatsApp had about 50 engineers when it was serving roughly 900 million users [O36].
But look at what's left. The same guidance says managed services free you up to focus on "securing your application", and that even on serverless you still own "security at the code level" [O35]. RDS still makes you do the major-version upgrade, and charges you if you don't [O6]. And WhatsApp was a consumer messaging app, not a B2B product with tenant-level support and enterprise customers asking for audits. AI isn't clearing the list yet, either. Google's DORA 2025 research found AI is now linked to faster delivery, but "software delivery instability continues to rise" [O37].
Managed services shrink the list. They don't empty it.
There's no single figure, but the median private B2B SaaS company spends 5% of ARR on hosting, 9% on customer support and success, and 22% on R&D [O14]. In our illustrative model (our calculation, excluding hosting), people's time and audits come to about $19,300 a month at 10 tenants and about $171,000 a month at 10,000 tenants.
Mostly engineering hours: bug fixes, small improvements, security patches, framework and database upgrades, restore tests and access reviews. Robert Glass put maintenance at 40 to 80% of software costs, averaging 60% [O10], and developers in Stripe's 2018 report spent about 42% of their week on maintenance [O9].
They reduce it. AWS says Amazon RDS automates patching and backups, but its own guidance says you still own security at the code level [O35]. RDS also charges an Extended Support fee if you run a database engine past its standard support [O6].
It stops getting standard support, and on Amazon RDS an Extended Support charge starts the day after standard support ends [O6]. AWS's US East example is $0.100 per vCPU-hour in year one [O6], which is about $290 a month for a 4-vCPU database (our calculation). Upgrading stops the charge [O6].
Yes. CISA, the FBI and the NSA advise organisations to "regularly test the availability and integrity of backups in a disaster recovery scenario" [O32]. The cloud makes the test cheap (AWS Backup charges $1.50 per recovery point evaluated [O5]). The real cost is the engineer's time to run, check and write up the restore.
Planning the year after launch? Budget the hours before the servers. Take the list above, put a name next to each job, and put a number of hours a month next to each name. Any line without a name is the one that turns into an outage, a failed audit or an unpatched database next November.
That's the kind of work we do at yousource: production hardening, code audits and ongoing maintenance of production software, so the upgrades, patches, restore tests and bug fixes get done by engineers who've done them before. See how yousource Dev works.
Still at the building stage? Start with what it costs to build a SaaS startup, then come back to this one. The build is the first bill. Running it is every bill after that.
