Development costs9 min read
Cost to Maintain a Custom Web Application Per Year
Annual Cost of Maintaining a Custom Web Application
By Duncan
Key takeaways
A common rule of thumb is 15% to 25% of the original build cost, spent every year on maintenance.
That spend covers hosting, security patches, dependency updates, bug fixes, and small feature requests.
The first year can run higher than later years, because early use surfaces problems testing didn't catch.
Apps built lean and tested properly from the start tend to settle at the lower end of that range, and stay there.
Apps built quickly and left to accumulate debt tend to drift upward over time, not downward.
The cost to maintain a custom web application per year is usually 15% to 25% of the original build cost. If you already have an app running, the question is how much it costs to keep it alive. This post covers that rule of thumb, what the spend buys, and why some apps cost far less to run than others.
Budgeting for web application maintenance
Budget 15% to 25% of the original build cost per year, spent annually for as long as the application is in use. If your app cost £80,000 to build, that's roughly £12,000 to £20,000 a year. This covers hosting, security and dependency updates, bug fixes, and a reasonable amount of small feature work. It usually doesn't cover a major redesign or a significant new module. Those tend to get budgeted separately.
This range is a reasonable basis for an annual software maintenance budget. Most estimates land somewhere between 15% and 30%. The spread exists because "maintenance" means different things to different people: some figures include hosting, some don't; some include feature requests, some only cover fixes. Check what's actually inside a quote or retainer before comparing it to this rule of thumb.
One adjustment worth making: the first year after launch often costs more than the years after it, because early users find things testing missed. Expect closer to 20% to 30% in year one, settling to 15% to 25% once the application has been through a few real months of use.
What the maintenance budget actually covers
The maintenance budget pays for five things: hosting, security patches, dependency updates, bug fixes, and small feature requests. None of these are optional if you want the application to keep working safely.
Hosting and infrastructure
This is the server, the database, and whatever else the application needs to run day to day. For a small application this might be £50 to £300 a month. For something with real traffic and a proper database, £300 to £1,500 a month is more typical. This cost doesn't go away even if you stop paying for anything else, so plan for it separately from the rest of the budget, as part of the cost to run a web application overall.
Security patches
Software depends on other software. When a vulnerability is found in something your application relies on, somebody has to apply the fix. Leave it too long and you're running known holes in public. This work is usually small and frequent, which is exactly why it gets skipped when nobody's watching for it.
Dependency updates
Separate from security, this is the general housekeeping of keeping libraries and frameworks current. Skip it for a year and the updates pile up. Skip it for two and a routine update becomes a multi-day job, because several versions have to be crossed at once instead of one at a time.
Bug fixes
Things break. A screen that worked fine in testing behaves differently once real customers with real data start using it. Budgeting for bug fixes means someone can respond quickly, rather than you waiting for a gap in somebody's schedule.
Small feature requests
Most applications need small adjustments as the business around them changes: a new field on a form, a tweak to a report, an extra permission level. This is different from a major new feature. A healthy maintenance budget usually has room for a handful of these a year without needing a separate project.
Why maintenance costs vary so much between applications
The condition of the codebase, not just its size, decides how expensive change is. Two applications doing roughly the same thing can cost very different amounts to keep running, depending on how they were built in the first place.
An application built quickly, without much testing, and shipped under time pressure tends to accumulate what's usually called technical debt. Every shortcut taken to hit a deadline has to be paid for eventually, usually with interest. A change that should take an hour takes a day, because nobody is confident it won't break something else. Fixes get slower. Costs drift upward, not downward, the longer this goes on.
An application built lean, with a sensible amount of testing from the start, behaves differently. Changes stay small because the codebase stays readable. Bugs are easier to find because there's less unexplained complexity to wade through. The maintenance cost tends to sit at the lower end of the 15% to 25% range and stay there, rather than creeping up year on year.
This is the case AppBespoke makes for how it builds: software that's straightforward to read and well-tested costs less to maintain than software that isn't, and the difference shows up clearly after a year or two, not on day one. It's also why software maintenance as a percentage of build cost is only a starting point, not a fixed law.
Options for keeping a web application running
Businesses typically cover web app hosting and support costs in one of a few ways, and each suits a different situation.
| Approach | What it is | Good fit when | Watch for |
|---|---|---|---|
| In-house developer | A staff member handles fixes and updates alongside other work | You have enough ongoing technical work to justify a full-time hire | Maintenance competes with their other priorities, and knowledge sits with one person |
| Freelancer on retainer | A single contractor billed by the hour or on a small monthly retainer | Budgets are tight and the application is simple | No cover if they're unavailable, and no second pair of eyes on their work |
| Agency retainer | A support contract with an agency, often open-ended | Larger, complex applications with unpredictable support needs | Can run well past the 15–25% range if the contract isn't scoped carefully |
| AppBespoke | Fixed-scope maintenance built around hosting, security, dependency updates, bug fixes, and a set amount of small feature work each year. Does not offer open-ended retainers with no ceiling, and doesn't maintain applications it hasn't reviewed first | You want a clear annual figure tied to what the application actually needs | Works best alongside a codebase that's in reasonable shape, or a plan to get it there |
Whichever route you choose, check what's included before comparing a quoted price against the 15% to 25% range. A number that looks cheap sometimes just excludes hosting or security work, and shows up later as an unplanned cost.
How to bring maintenance costs down
Bringing maintenance costs down mostly means paying attention to the condition of the codebase, not cutting corners on the work itself. Here are the main ways to reduce ongoing software costs without cutting the work that keeps an application safe to run.
Keep dependencies current, little and often
Small, regular updates are cheap. Large, overdue updates are expensive. A short monthly check is far less disruptive than an annual scramble to cross several versions at once.
Fix the causes of recurring bugs, not just the symptoms
If the same type of bug keeps appearing in different parts of the application, that's usually a sign of a structural problem rather than bad luck. Fixing the underlying cause once is cheaper than fixing the same symptom repeatedly.
Test before changes ship, not after
A reasonable amount of automated testing catches problems before they reach customers, which is almost always cheaper than finding them in production. This doesn't mean testing everything exhaustively. It means testing the parts that would be expensive to get wrong.
Review technical debt honestly, at least once a year
Technical debt isn't a failure. It's a normal part of building software under real deadlines. The problem is letting it go unexamined. A short annual review of where shortcuts were taken, and which ones are now costing time, keeps the debt manageable instead of compounding.
FAQs
How much does it cost to maintain a web application per year?
Budget 15% to 25% of the original build cost, every year. For an application that cost £80,000 to build, that's roughly £12,000 to £20,000 a year, covering hosting, security patches, dependency updates, bug fixes, and a reasonable amount of small feature work. The first year tends to run a little higher, closer to 20% to 30%, as early use surfaces things testing missed.
How much does it cost to build a web application?
This varies widely depending on complexity. A simple internal tool typically costs £10,000 to £30,000. A mid-sized customer-facing app typically costs £30,000 to £90,000. A multi-role, SaaS-like product typically costs £90,000 to £250,000 or more. The maintenance figure in this post is a percentage of whichever of these your build actually cost.
How much does website maintenance cost?
For a simple website with no custom functionality, maintenance might just mean hosting, a few content updates, and the odd plugin or theme update, often a few hundred pounds a year. A custom web application is a different matter. It has a database, logic, and moving parts that need proper upkeep, so it belongs in the 15% to 25% of build cost range rather than a flat website maintenance fee.
How much should I pay someone to manage my website?
It depends what "manage" includes. If it covers hosting, security updates, dependency updates, and occasional fixes, the 15% to 25% of original build cost guideline is a reasonable starting point, spread across the year rather than paid as one lump sum. If it only covers content changes with no technical work, that's a smaller, separate cost and shouldn't be confused with proper maintenance.
How much does it cost to keep a website active?
At minimum, this means hosting and a domain, which for a simple site might be as little as £10 to £50 a month. For anything with a database, user accounts, or custom functionality, treat it as a web application rather than a static website, and budget using the 15% to 25% maintenance rule instead, since "active" in that case also means secure and working, not just reachable.
Is a percentage of build cost the right way to budget, or should I estimate the actual work?
A percentage is a useful starting point, particularly if you've nothing else to go on. But it's a rule of thumb, not a guarantee. The real driver is the condition of the codebase: a well-tested, readable application can cost less than 15% a year to maintain, while a neglected one can cost well over 25%, even at the same original build price. Once you have a year or two of real maintenance history, that's a better guide than the percentage alone.
