Software maintenance cost: the line item every non-technical founder underestimates

A founder-first guide to what you actually pay after launch, why “15% of build” is the wrong rule for early-stage startups, and the five-question diagnostic to estimate your real number before it hits.

A founder we worked with last year shipped a clean $86,000 MVP. Stripe checkout, an admin dashboard, a small mobile app. He closed his seed round on time, told the board the technical risk was behind him. Nine months later he forwarded us a $14,200 invoice and asked what had happened.

What had happened was ordinary. AWS deprecated the Node 14 runtime his Lambda functions ran on. His payment provider sent a 60-day notice on a webhook signature change he could not read. The Android target SDK was about to fall below the Play Store minimum, which would have pulled the app from the store entirely. Sentry, added on a free plan in month one, had quietly crossed onto a $79/month tier. And his sole developer had moved to another gig three months earlier, so the founder had to bring in a contractor at $190/hour to chase all of it down.

None of that was a surprise to anyone who has shipped software for a living. All of it was a surprise to him.

Software maintenance cost is the recurring operating cost of keeping a live software system running, secure, and useful after launch. It is separate from the build cost. It is not 15% of anything in a meaningful way. And for early-stage startups, it is the single most consistently underestimated line item in the first eighteen months of a real product being live.

This piece is a budget framework for non-technical founders. It names the three things you are actually paying for, explains why the standard percentage rule of thumb fails for your stage, lists the hidden costs nobody quotes you, and gives you a five-question diagnostic to estimate your real number before you sign anything.

The three things you are actually paying for

Every credible quote for software maintenance covers some mix of three categories. Most quotes do not separate them. Most founders, as a result, cannot tell which one they are buying enough of.

Keep-the-lights-on

The work that has to happen for your product to stay alive, with or without any new feature. Security patches. Dependency updates. Runtime upgrades when the cloud provider deprecates the one you are on. Certificate renewals. Backup verification. Payment-provider migration when Stripe or your local equivalent changes a webhook contract. Browser and mobile-OS breaking changes.

This is non-negotiable work. If you skip it, your product eventually breaks in a way that is more expensive to fix than the work would have been. The founder above paid $14,200 in a month largely because nine months of skipped keep-the-lights-on caught up with him at once.

For a typical pre-A to Series A SaaS or marketplace product with one to three services in production, budget 8 to 25 hours per month of focused engineering time. That maps to roughly $1,500 to $5,000 per month at competent contractor rates.

Small-fixes

Bugs in production. Edge cases your beta missed. A specific customer cannot log in. An export generates a malformed CSV. A timezone off-by-one breaks a daily report. The signup form rejects a real email format.

Most non-technical founders see this category as “things going wrong.” It is more accurate to think of it as the irreducible noise of running a real product with real users. A product with zero small-fixes work is a product nobody is using.

Volume here scales with daily active users and release cadence, not code base size. A B2B product with 40 customers generates two to six small-fixes per month. A B2C product with 5,000 active users generates twenty. Budget 15 to 40 hours per month for early-stage products. Founders consistently underestimate this category by half because the testing they personally did before launch surfaced a small fraction of what real users will surface.

Evolve

The work that is not really maintenance and not really new product. It is keeping the software shaped like your business as your business changes. The pricing page you shipped at launch had three tiers; the sales motion you actually use has four. Onboarding assumed self-serve; your real customers are guided demos. The admin dashboard works for one operator; you now have three and they all need different filters.

If you do not budget for evolve work, every business change becomes a debate about whether to do it or wait for the next big release. That debate is more expensive than the work. For a startup actively iterating on its model, budget 20 to 60 hours per month in the first eighteen months after launch, dropping as the model stabilizes.

These three categories add up. They do not substitute for each other. A quote that does not name them is a quote you cannot pressure-test.

Why the “15% of build cost” rule is wrong for founders

Ask the internet how much software maintenance costs and you get a percentage. Fifteen percent of build. Twenty. Sometimes thirty. That rule comes from enterprise software lifecycle management, where the scope is stable, the user base is bounded, and most maintenance work is keep-the-lights-on plus minor patches over a five-to-ten-year horizon.

That world is not your world.

In the first eighteen months after launch, your scope is not stable. You are still finding product-market fit. Your evolve bucket is sometimes larger than your build cost because every customer conversation reshapes the surface area. Your user base is growing by an order of magnitude per quarter, which means every small-fixes bug appears in front of ten times as many people each month. Your stack is younger and less stable than an enterprise codebase, so dependency churn hits harder. And your team is smaller, so there is nobody to absorb a deprecation email without billing for it.

For a typical seed-to-Series-A startup, real annual software maintenance cost in years one and two often lands at 40% to 80% of original build cost, not 15%. By year three, as scope settles, that number can drop toward 20% to 30% if the engineering work has been done well. If it has not been done well, the second-year number is even higher because every shortcut from the build has come due.

The 15% rule is not a lie. It is a measurement from a different system, applied to yours, and it is one of the most expensive borrowed numbers in early-stage software. If a vendor quotes you a maintenance package at 15% of build cost, ask which of the three categories that covers. They are almost certainly only quoting you keep-the-lights-on.

The hidden line items nobody quotes you

When you ask a vendor for a maintenance quote, you get a number that includes their engineering hours. You almost never get the rest of the bill.

Third-party SaaS dependencies. Sentry, Postmark, Datadog, Auth0, Twilio, Segment, Mixpanel, Stripe Billing, Plaid, your CDN, your transactional email provider, your captcha, your scheduled-job runner. Most have a free tier you fit into at launch and a real tier you grow into around month four. The cumulative monthly burn for a typical Series A product is $400 to $2,000, almost none of it in your original quote.

Infrastructure cost growth. Your AWS or GCP bill on day one is small because your traffic is small. The growth is rarely linear; one query that worked fine at 1,000 rows becomes a daily timeout at 100,000. The founder who skips a quarterly infra review is the founder whose cloud bill suddenly tripled in October.

API price changes from your dependencies. OpenAI raises model prices. Stripe takes a higher cut on a payment method you depend on. Your geocoding provider tightens their rate limit on the plan you grandfathered onto. None of these are negotiable in the moment; all of them have to be absorbed or routed around with engineering work.

On-call coverage. If your product needs to be up at 2 a.m. and the only person who knows the system is asleep, you do not have a maintained product, you have a fragile one. On-call is either an explicit line item (a fractional CTO with a defined response window, an external SRE, a contractor on retainer) or an implicit cost that shows up as your one developer quietly burning out.

Security incident response. Probability per year of a security event that requires real work is non-trivial even for small products. An exposed API key on GitHub. A credential leak. A WAF rule that blocks a real customer. A DDoS that costs you a weekend. The response is paid for in hours that did not exist in your maintenance plan.

Third-party deprecations. This is what got the founder above. Cloud providers deprecate runtimes. Payment providers change webhook signatures. Email providers tighten DMARC. Mobile-OS vendors raise target-SDK floors. None of these are emergencies the day the email arrives; all of them are emergencies six months later when nobody followed up.

A maintenance budget that does not have an explicit line for each of these is not a budget. It is a guess.

Five questions to estimate your real maintenance cost

Before you sign any maintenance agreement, or before you decide how much in-house engineering capacity to keep available, work through these five questions honestly with your developer or vendor. They take an afternoon. They will save you from the second-year shock.

1. How many production services do we run, and what is the patch cadence of each? Two services with weekly dependency updates is a different bill from one monolith with annual updates. Count them, list the cadence, and ask who is responsible for each.

2. What is our combined monthly bill across all third-party SaaS, infra, and APIs we depend on, and which of those have free tiers we will grow out of in the next six months? Pull every receipt. List every service. Mark the ones that scale with usage. The list is always longer than the founder thinks.

3. Who is on call, what is their response time commitment, and what does it cost? If the answer is “our sole developer when he sees the message”, you have your answer. Then estimate what it would cost to make that less brittle.

4. What is our planned release cadence and feature roadmap for the next two quarters, and how much of that is evolve work on existing surfaces vs. genuine new product? If 60% of your roadmap is rewriting the onboarding, the checkout, and the admin dashboard, your evolve bucket is huge and you should budget it as such.

5. What is our worst-case scenario in the next twelve months, and what would it cost to recover? Sole developer leaves. Major customer triggers a feature request that touches everything. Cloud provider deprecates a runtime with 90 days notice. Pick the two most likely. Cost the recovery. Add a buffer.

A founder who can answer these five questions has a real maintenance number. A founder who cannot has a wish.

How to budget maintenance from year one: the 30-50-20 split

For every dollar of annual maintenance budget, allocate 30% to keep-the-lights-on, 50% to small-fixes and evolve combined, and 20% to buffer. The buffer is not slack; it is the line that absorbs the third-party deprecations, the security incident, and the surprise SaaS bill. Founders who do not budget a buffer pay for it anyway, just in panic.

In dollar terms, for a typical pre-A to Series A SaaS or marketplace product, that comes out to a year-one maintenance budget in the range of $30,000 to $90,000, sitting on top of the original build cost. The range reflects two real factors: how much of your product is already live (more live surface, more cost), and how stable your business model is (more change, more evolve work). If your build was $80,000 and your model is still moving every quarter, expect the higher end. If your build was $200,000 and your model is settled, you can be at the lower end as a fraction.

That is a starting number to test against the diagnostic above, not a final answer. The diagnostic gives you the final answer.

How to negotiate maintenance into a software development contract

The right time to negotiate maintenance is before you sign the build contract, not after the first deprecation email hits. We wrote about contract structure in our piece on fixed price vs time and materials; the maintenance clause is the part most founders skip on first read.

Three things to insist on before signing.

A named maintenance scope with the three categories separated. Not “ongoing support.” Keep-the-lights-on as one line with a defined response window, small-fixes as a second line with a monthly hours pool, evolve as a third line with a separate hourly rate. If the vendor will not separate them, you are buying one bucket and getting whichever category the vendor feels like serving that month.

Source code in your name from day one, and access to every third-party service in your accounts, not theirs. This is non-negotiable. Maintenance is impossible to switch providers on if the code lives in their GitHub and the AWS account is on their corporate card. Our software house piece covers the broader posture on vendor accountability.

A 30-day transition clause. If you decide to move maintenance in-house or to a different vendor, you have 30 days of paid handover with documentation, credential transfer, and a final dependency-update sprint. Without this clause, switching vendors costs you a forced rewrite.

For the broader question of who owns maintenance oversight when you do not have a CTO, our piece on fractional CTOs names the four alternatives. For the in-house vs outsourced decision specifically on maintenance, our in-house vs outsourcing piece gives the three-axis framework. Outsourcing keep-the-lights-on is almost always the right call for early-stage; bringing small-fixes in-house starts to make sense when you have enough volume to justify a dedicated person; evolve work is the last category to bring in-house, because that is where business knowledge compounds. The full piece on how much it costs to build an app is the cost-side companion to this one; reading both gives you the full two-year picture.

FAQ

How much does it cost to maintain a software?
For a typical pre-A to Series A SaaS or marketplace product, annual maintenance lands in the range of $30,000 to $90,000 in years one and two, on top of original build cost. That breaks into three categories: keep-the-lights-on, small-fixes, and evolve. The 15-to-20-percent-of-build rule of thumb you will find on most agency sites is borrowed from enterprise software and consistently understates the real cost for startups whose scope is still moving.

How do you estimate software maintenance cost?
Answer five questions honestly with your developer or vendor: how many production services you run and their patch cadence; the combined monthly bill of every third-party SaaS, infra, and API you depend on; who is on call and at what cost; your release cadence and the split between evolve work and genuine new product; and your worst-case scenario for the next twelve months. Add the five answers, add a 20% buffer. Anyone who quotes you a maintenance figure without working through these five inputs is quoting you a guess.

What is the typical maintenance cost percentage?
The 15-to-20% rule comes from enterprise software with stable scope. For early-stage startups, real annual maintenance in years one and two is typically 40% to 80% of original build cost, dropping toward 20% to 30% by year three if the engineering work has been done well. The percentage framing is less useful than the category framing; ask what you are paying for, not what fraction of build it equals.

Why is software maintenance expensive?
Three reasons. The world around your software keeps moving (cloud providers, payment processors, mobile OS vendors, and third-party APIs all force changes you have to absorb). Your users surface bugs and edge cases that no amount of internal testing finds. And your business changes faster than your code, so your software keeps having to be reshaped to fit the business. The combination is what makes maintenance more expensive than founders expect, and what makes the “15% of build” rule consistently low.

A live product is not a finished product. The cost of running one honestly is its own line item, and the founders who plan for it in month one are the founders whose month-nine email is about a new customer, not a $14,000 invoice.