Website, App and Software Maintenance Costs After Launch: What to Budget
What website, app and software maintenance cost after launch: hosting, security patches, dependency updates, bug fixing, retainers — and keeping it predictable.
The build budget gets a spreadsheet, a signature, and a launch party. The maintenance budget usually gets a shrug — and then a surprise invoice in month four when a framework upgrade, an expired certificate, and a payment provider's API change land in the same week. Software maintenance cost is not a tax on a finished product; it is the running cost of a product that exists. This guide breaks down what website, app and software maintenance actually include, what to expect for each line, how a support retainer keeps the number predictable, and how to balance maintenance vs new features without letting either starve.
What Maintenance Actually Includes
"Maintenance" hides five different kinds of work with different rhythms. Budgeting for them separately is what makes the post launch budget credible.
- Corrective — bug fixing: defects reported by users or found in monitoring. Continuous, spiky after releases.
- Preventive — dependency updates, security patches, framework and runtime upgrades, certificate renewals. Scheduled, and catastrophic when skipped.
- Adaptive — changes forced by the outside world: an API you integrate with changes, an app store policy changes, a browser deprecates something you relied on.
- Perfective — small improvements that are not features: performance tuning, accessibility fixes, copy changes, analytics adjustments.
- Operational — hosting costs, third-party services, monitoring, backups, and someone who responds when an alert fires.
Most founders budget for the first and the last and are blindsided by the middle three.
Website Maintenance Cost vs App Maintenance Cost
The categories are the same for a marketing site, a web application, and a mobile app, but the weights differ.
A website maintenance cost is dominated by hosting, a CMS and plugin updates, security patches, and content-related changes. It is the cheapest of the three to keep healthy, and the easiest to neglect because nothing appears to break until it does.
A web application adds a database, background jobs, integrations, and user-facing bugs. Dependency updates matter more because the codebase is larger, and monitoring matters more because users notice downtime immediately.
An app maintenance cost for iOS and Android adds a rhythm you do not control: operating system releases, store policy changes, device fragmentation, and the certificates and provisioning profiles that expire quietly. A mobile app that receives no updates for a year is often unpublishable by the end of it. The moment to think about this is before launch, not after the first rejected build.
The Budget Lines and What Drives Each
Rather than a single number, think in lines. Here is how they behave in our projects.
Hosting and third-party services
Hosting costs scale with users and data, not with features. Add the services around the application — email delivery, error tracking, analytics, file storage, the payment provider's fees — and review the top three line items monthly against active users. The failure mode is a plan chosen at launch that is still running at ten times the traffic.
Security patches and dependency updates
This is the most skipped line and the most expensive to skip. Modern applications depend on hundreds of packages, and every month some of them publish fixes for real vulnerabilities. Keeping up is a small, regular effort: a scheduled update pass, automated checks in the pipeline, and a rule that critical security patches ship within days. Falling behind turns the same work into a multi-week upgrade project with risk attached, which is the usual origin story of the "we need a rewrite" conversation. If your deployment pipeline cannot ship a patch safely on a Tuesday afternoon, fixing that comes first — our guide to setting up CI/CD in a few days is the minimum.
Bug fixing and small changes
Bugs never stop because users never stop finding new paths through the product. Expect a steady trickle, a spike after every release, and a spike after every operating system update. Small changes — a new field, a copy tweak, a report column — belong here too, and they are where scope creep hides if nobody is watching the boundary between maintenance and features.
Monitoring, backups, and on-call
Uptime monitoring from outside your infrastructure, error tracking, log retention, tested backups, and a human who is reachable when something fails. The cost is mostly people's time and a few tools. The cost of not having it is finding out about an outage from a customer.
Technical debt
Every product accumulates technical debt: shortcuts that were right at the time and expensive later. A fixed slice of maintenance time for paying it down — refactoring the module everyone fears, deleting dead code, improving test coverage where bugs cluster — is what keeps the other lines from growing every year. The hardening work described in our article on upgrading an MVP's architecture without a rewrite is largely this line, done deliberately.
How Much to Budget: Ranges From Our Projects
We deliberately avoid a universal percentage, because the honest answer depends on the size of the codebase, the number of integrations, and how much of the stack is managed for you. What we can say from our own projects:
- A content website with a managed CMS needs a few hours a month plus hosting, as long as updates are applied on schedule.
- A web application for a small business, with a handful of integrations, needs a part-time engineer's attention every month for updates, fixes, and monitoring, plus hosting that grows with usage.
- A product with mobile apps needs that plus a predictable pulse of work around every operating system release and store policy change.
- Any product with payments, personal data, or regulated workflows needs a higher preventive and operational line, because the cost of a missed security patch is not a bug, it is an incident.
The useful exercise is not to guess a percentage but to write the lines above with an hours-per-month estimate against each, then compare that with what the team actually spent in the first three months after launch. The real number appears quickly.
A Support Retainer: Making the Number Predictable
The unpredictable way to pay for maintenance is emergencies: nobody on the hook, a scramble to find whoever built it, premium rates for urgent work. The predictable way is a support retainer with an engineering partner or an internal allocation that behaves like one.
A retainer that works has:
- A fixed monthly block of hours, sized from the lines above, with unused hours rolling over within limits.
- An SLA that defines response and resolution targets by severity — a payment outage is not a typo.
- A monthly review that decides what to fix, what to defer, and what to promote into the feature roadmap.
- A named team that knows the codebase, so every incident does not start with archaeology.
- Reporting that shows hours by category, so you can see when preventive work is being crowded out by fixes — an early warning that debt is growing.
This is what application maintenance services should mean in practice: not a ticket queue, but ownership of the product's health with a budget you can plan around.
Maintenance vs New Features: The Ratio That Keeps a Product Healthy
Maintenance vs new features is a false fight, but it is one the roadmap has every quarter. Products that spend nothing on maintenance ship features faster for about a year and then slow to a crawl. Products that spend everything on maintenance are beautifully engineered and commercially dead.
The pattern that holds up: protect a fixed share of every sprint for the preventive and debt lines, let the corrective line float with reality, and put everything perfective and adaptive through the same prioritisation as features. When the fixed share keeps getting raided for features, that is the signal to grow the team, not to skip the updates.
For WasteHero, a smart-city waste management platform with dashboards, routing and operations tooling that municipalities rely on daily, the maintenance share was never optional — integrations with vehicles and sensors change, and the product had to keep absorbing those changes while new capabilities shipped alongside them.
Total Cost of Ownership Over Five Years
The build is a one-time cost; maintenance is a recurring one, and over a product's life it is usually the larger of the two. That is why total cost of ownership, not the build quote, is the number to compare when deciding whether to build, buy, or keep an existing system alive. Our guide on custom software versus off-the-shelf tools walks through that calculation; the maintenance lines in this article are the inputs it needs.
The decisions that lower five-year cost are mostly made at build time: a mainstream stack with a deep hiring pool, managed services for commodity functions, automated deployment from day one, and tests where bugs cluster. Everything else is discipline.
Post-Launch Budget Checklist
Before launch, or right now if you have already launched:
- Maintenance budget written as lines: hosting and services, security patches and updates, bug fixing, monitoring and on-call, technical debt
- Hours per month estimated per line, reviewed against actuals after three months
- Automated dependency and vulnerability checks running in the pipeline
- Deployment pipeline able to ship a patch safely on short notice
- External uptime monitoring, error tracking, and tested backups in place
- Support retainer or internal allocation with an SLA, a named team, and a monthly review
- Fixed share of each sprint protected for preventive work and debt
- Mobile: operating system and store deadlines tracked, certificates and profiles on a renewal calendar
FAQ
How much does software maintenance cost per year? It depends on codebase size, integrations, and platform, which is why we recommend budgeting by line rather than by percentage. Write the lines, estimate hours per line, and calibrate against the first three months of real spend.
Can we skip maintenance for the first year to save money? You can defer features; you cannot safely defer security patches, expiring certificates, or store requirements. Skipping preventive work does not save money, it moves the cost to a larger, riskier project later.
What should a support retainer cover? Corrective fixes with an SLA, scheduled preventive updates, monitoring response, and a monthly review that feeds the roadmap. Larger changes are scoped separately so the retainer stays predictable.
How do we know if our maintenance spend is too high? Look at the split. If most hours go to bug fixing and emergencies while preventive work is starved, the product is accumulating debt and the spend will keep rising. If preventive work is regular and fixes are declining, the spend is doing its job.
When does maintenance turn into a rewrite? Rarely, and usually only when the platform is unsupported or nobody can work on the code. Most "rewrite" conversations are really deferred maintenance; our article on when it is time to revamp your app covers the signals that actually justify a redesign.
If your product has launched and the maintenance plan is still "we'll see", we can audit the codebase, size the budget lines, and take on the retainer with a real SLA. Talk to IvorySoft and we will start with what your first three months of production have already told you.
