Plan for roughly 15–25% of the original build cost per year to keep a custom app healthy — about €3,000–€5,000 a year on a €20,000 app — and €500–€3,000 a year for a business website. That budget covers hosting, third-party service fees, operating-system and dependency updates, security patches, bug fixes, monitoring and small improvements. Maintenance is the cost almost nobody quotes upfront, and it is not optional: the platforms your software runs on change constantly, and software that is never maintained quietly stops working.
What does app and website maintenance actually cost per year?
Here are realistic 2026 annual maintenance bands, based on how much custom software sits behind the thing you own.
| What you own | Typical yearly maintenance | Rule of thumb |
|---|---|---|
| Business website (simple) | €500–€1,500 | Hosting, updates, small content and design changes |
| Custom website / web app | €1,500–€6,000 | Real backend, integrations, booking or e-commerce |
| Mobile app (standard) | €3,000–€8,000 | ~15–25% of build cost; iOS + Android + backend |
| Complex product / platform | €8,000–€30,000+ | Scale, real-time features, multiple integrations, uptime |
The single biggest driver is how much custom software there is. A brochure website is cheap to keep alive; anything with accounts, payments, data syncing or a mobile app has real engineering behind it that ages and needs attention.
What are you actually paying for?
Maintenance is not a vague retainer — it is six concrete things:
- Hosting and infrastructure. Servers, databases and file storage cost money every month, whether ten people use the product or ten thousand.
- Third-party service and API fees. Payment providers, email and SMS, maps, an AI model, a CRM connection — most modern software rents capabilities from other services, and those bills are part of running it.
- Operating-system and dependency updates. Apple and Google ship a major OS release every year, browsers update constantly, and the open-source libraries underneath your app get new versions. Falling behind turns a one-hour update into a one-week migration.
- Security patches. Vulnerabilities are found in dependencies all the time. Patching them promptly is the difference between a routine update and a breach.
- Bug fixes. Real usage surfaces edge cases no test caught. Fixing them quickly is what keeps trust.
- Monitoring. Knowing the app is up, payments are going through and errors are being caught — before a customer emails you — is a cost, and a cheap one compared to silent failure.
Most owners also keep a small budget for improvements: the steady stream of little changes that keep the software useful as the business itself changes.
Why maintenance isn’t optional
Software is not a building that, once built, mostly stays standing. It runs on top of platforms — iOS, Android, browsers, cloud services, dozens of libraries — that change underneath it every single month. An app you stop maintaining does not stay frozen at “working.” It degrades:
- First a small thing breaks — a login, a form, a payment.
- Then a dependency with a known security hole goes unpatched.
- Then an annual OS update makes the app crash on launch, and the store pulls it.
Fixing a neglected codebase costs far more than maintaining it would have. The worst outcome in this business is common: a company pays to rebuild software it already owned, simply because nobody kept it running.
App maintenance vs website maintenance — how they differ
A website and a mobile app both need maintenance, but not the same amount. A website lives in the browser, updates when you deploy, and has no app store between you and your users — so keeping it healthy is mostly hosting, security and content. A mobile app has to be re-approved by Apple and Google, must keep pace with two operating systems and every new device size, and can be forcibly removed from the store if it falls too far behind. That is why app maintenance sits higher, at 15–25% of build cost, while a straightforward website is cheaper to run.
The real difference: a one-off build vs software that’s kept running
Here is the trap most businesses fall into. A freelancer or agency builds the app, invoices, and moves on — maintenance is “not included,” and six months later there’s no one who remembers how it works. You’re left choosing between paying a stranger to relearn your own codebase or watching it rot.
The alternative is a studio that builds and runs the software — the same person who wrote it keeps it alive. That is the whole point of the “build and run” model: one accountable person who ships the product and is still there in year two when iOS 20 lands, a dependency needs patching, or the business needs one more feature. It is the difference between owning software and owning a liability.
If you’re weighing who should build and maintain your software in the first place, we cover it in detail in freelancer vs agency vs studio and how to choose who builds your app.
How to keep maintenance costs low and predictable
- Own your code and accounts from day one. If you control the repository, the hosting and the third-party accounts, you are never locked in to one supplier and can bring in help without starting over.
- Keep dependencies current. Small, regular updates are cheap; a two-year backlog of skipped updates is a migration project. Maintenance is cheapest when it never stops.
- Pay for monitoring, not just fixes. Catching a problem before customers do is a fraction of the cost of a public outage.
- Prefer a predictable arrangement over emergencies. For anything the business depends on, a steady monthly setup costs less than urgent, out-of-context “it’s down!” fixes — and fewer things break because the software stays current.
The honest way to think about it: the build price is what it costs to get working software; the maintenance budget is what it costs to keep it working. Both are real, and the second one is where “who built it” starts to matter most. Custom software built and kept running end to end — apps, APIs, automations and AI — is how a real business problem stays solved, not just solved once.