Web Application Maintenance: The Complete Guide to Life After Launch

Web application maintenance is the ongoing work that keeps an app secure and running after launch: framework and dependency updates, monitoring, backups, incident response, hosting and new development. Much of the work in a web app's life happens after it ships, and the decision that matters most is who owns each of those jobs before something breaks.

I offer maintenance and ongoing development myself, so keep that in mind as you read. I've tried to be just as clear about when you can handle it in-house, and when a solo developer like me is the wrong fit.

The short answer: six jobs that start at launch

Use the table as a map. Each job has its own detailed post, linked in the sections below. The rest of this guide covers why the work is unavoidable, how to organize it, who should own what, what it costs, and a step-by-step plan to put it all in place.

Why web apps decay even when nobody changes the code

Code doesn't rot on its own, but everything around it moves. The language, the framework and the packages your app depends on keep shipping new versions, and older ones lose support on a published schedule.

PHP gives every release two years of active support followed by two years of security-only fixes, four years in total (PHP supported versions). Laravel gives each major release 18 months of bug fixes and two years of security fixes (Laravel support policy). Launch on the latest Laravel, change nothing, and in roughly two years you're running a version that no longer gets security patches.

Other things change without asking you first:

• Payment providers, email services and other APIs retire old versions, and your integration stops working.
• Browsers update, and an old JavaScript package starts behaving differently.
• Your hosting provider drops old PHP versions or operating systems and moves you to newer ones, ready or not.
• Data grows. A page that loads instantly with a thousand rows can crawl with a million.

None of this is hard in small, regular steps. It gets expensive when an app sits untouched for 3-4 years and every update has to happen at once. A few hours a month turns into a project, and at worst into a full legacy PHP modernization. I've written in more detail about why you should keep software dependencies updated and about Laravel's version support policy.

Web application maintenance in practice

Here's what each job looks like for a typical web app, such as a customer portal, a booking system or a SaaS product built on Laravel. Some of it runs on autopilot once it's set up. Some of it needs a human decision every month.

Dependency updates and security patches

Updates come in three sizes. Patch releases fix bugs and security holes and usually install without code changes. Minor releases add functionality without breaking anything. Major releases can require changes to your code and need planning.

I recommend a fixed monthly routine for the small stuff. Run composer audit and npm audit to check packages against known vulnerabilities, update, run the automated tests, and check the result on a staging environment (a copy of the app used for testing) before it goes to production. GitHub's Dependabot can open update pull requests automatically, but someone still has to review and test them.

I treat major upgrades as small projects with their own estimate. Laravel's yearly release is a natural moment to review the rest of the stack too.

Security is more than updates. Access should be revoked when staff or contractors leave, secrets should be rotated, and apps that handle sensitive data deserve an outside look. An external code review or a penetration test for your web app can pay for itself, especially once an enterprise customer or a procurement process starts asking security questions.

Monitoring and error tracking

Monitoring means you hear about problems before your users email you. Three layers matter:

• Uptime: an external service checks your app every minute or two and alerts you when it doesn't respond. The same service can warn you before SSL certificates or domains expire.
• Application errors: an error tracking tool such as Sentry or Flare captures exceptions with the context a developer needs to fix them.
• Background jobs: many apps send emails, generate invoices or sync data in queues. When those stop, nothing visibly breaks until a customer asks where their invoice went.

The key decision is who gets the alert. An alert that lands in a shared inbox nobody reads is no alert at all. See my picks for uptime monitoring tools for web apps and my comparison of error tracking tools.

Backups and restores

A backup has to cover the database, user uploads and the configuration needed to bring the app back. It should live outside the server, and ideally outside the hosting account, so it survives if either disappears. The 3-2-1 rule sums it up: three copies, on two types of storage, with one off-site.

The part most teams skip is the restore test. A backup you've never restored from is an assumption. Restore to a test environment a couple of times a year and time it. That number is your realistic downtime in a real disaster.

If your app handles personal data and you operate in the EU, this is also a legal expectation. GDPR Article 32 asks for the ability to restore availability of and access to personal data in a timely manner after an incident, and for regular testing of your security measures. My web app backup strategy guide covers what to test.

Incident response

Sooner or later something breaks: a change at a third party, a full disk, a bug in a new release. What matters is how fast someone responds and whether they have the access they need. Agree on these in advance:

• who receives alerts, and who covers holidays and sick days
• what counts as critical (the app is down, payments fail) and what can wait until the next business day
• one channel for bug reports, so they don't arrive in five different email threads
• who keeps customers informed while the fix is underway

If a breach involves personal data, GDPR requires the controller to notify the supervisory authority without undue delay and, where feasible, within 72 hours of becoming aware of it, unless the breach is unlikely to put people at risk (GDPR Article 33). That clock is hard to beat if nobody knows who investigates. If you're in the middle of an outage right now, read what to do when your website or app is down.

Hosting and infrastructure

Hosting is more than a server. It's the domain, DNS, certificates, transactional email, file storage and every subscription the app relies on. A classic and entirely avoidable outage: a domain or a credit card expires because the account sits in the name of a former employee or the original developer.

The real choice is between managed hosting, where the provider keeps the operating system and database patched, and a server that you or your developer maintain. Managed hosting costs a bit more each month but removes a whole category of work, and for most small and mid-sized companies it's what I recommend. For European businesses, keeping servers and backups in an EU region also keeps GDPR transfer questions simple. If you need to switch providers later, careful planning lets you migrate web app hosting without downtime.

Ongoing development

Once the app is live, you learn what users actually do. That's the best input for prioritizing, and it's also when the wish list grows fastest. Without a plan, development follows whoever shouts loudest.

I recommend separate budget lines for maintenance and development. Maintenance keeps the app working. Development is an investment you choose when there's a clear need. Mix the two and updates tend to lose to new features, which is exactly how apps end up on unsupported versions.

Let real usage data guide the choices. I've written about prioritizing your product roadmap after launch and about choosing between GA4, Plausible and PostHog for product analytics.

Retainer, pay-as-you-go or in-house?

There are three basic ways to organize maintenance. None fits everyone, and many companies mix them.

A maintenance retainer

You pay a fixed monthly fee or a block of hours, and the developer handles updates, monitoring and backups on an agreed schedule. This suits most business-critical apps at companies without their own developers. The upside is that the work happens without you having to remember it. The downside is that you pay even in months when nothing visible happens.

Pay-as-you-go hours

You get in touch when something comes up and pay for the time spent. This works for internal tools with few users, where a day of downtime isn't a disaster. The risk is that nobody starts the updates because nobody owns them, and the developer has to get back up to speed every time.

An in-house developer

If you employ developers, maintenance is part of their week. That makes sense when software is the core of your business. Still give updates a fixed slot in planning, or they'll keep losing to features.

When a solo freelancer is the wrong choice

I'm based in Denmark (CET) and reply within one business day. That lines up well with UK and EU working hours and is enough for most B2B systems, but it isn't 24/7 on-call. If your app needs someone responding within minutes at night and on weekends, you need an agency or a managed service provider with an on-call rotation, or your own team. One person can't honestly promise that.

You also don't need a retainer for a simple marketing site on a platform that handles its own updates, or for an app you're shutting down within six months. Monitoring, backups and security fixes as needed will do.

Who owns what after launch

Maintenance rarely fails because the work is hard. It fails because everyone assumes someone else has it. The host assumes the developer runs backups, the developer assumes the host does, and the owner assumes it's all included. Write down a split like this one and put it in your contract.

The exact split depends on your setup. What matters is that every row has one owner, not three people each assuming it belongs to someone else. This belongs in a written agreement with response times and prices, and I've listed what a software maintenance agreement should cover.

If you sell software to companies covered by the EU's NIS2 directive, expect them to pass supply-chain security requirements on to you, such as documentation and incident handling. I've covered what NIS2 means for software suppliers separately.

What web app maintenance costs

Cost depends more on the app's condition than on its size. My rule of thumb is to budget 10-20% of the original build cost per year for maintenance, before new features. If the app cost €40,000 to build, that's roughly €4,000-8,000 a year. Treat it as a budgeting estimate, not a quote.

What pushes the number up or down:

• How far behind the versions are. An up-to-date app is cheap to keep current. One that's three major versions behind needs a catch-up project first.
• Automated tests. Good tests make each update quick to verify. Without them, everything gets checked by hand.
• Number of integrations. Every connection to another system can change without notice.
• Response time requirements. Fast response outside business hours costs extra wherever you buy it.
• Sensitive data. Personal data and payments call for more careful security work.

Rates vary a lot across Europe, from Eastern European agencies to Nordic and UK contractors, so compare scope and response times rather than just the hourly or day rate. Hosting and third-party services come on top. A small app on managed hosting can often run for under €100 a month, while apps with many users, queues and separate databases quickly cost more. Here's how the bill is usually structured:

For worked examples, see my breakdown of annual web app maintenance cost.

How to set up maintenance after launch: a 7-step plan

Work through these in order, even if your app has been live for a while without a plan.

1. Collect access and ownership. Domain, DNS, hosting, the code repository and every third-party service should be in the company's name, with credentials in a shared password manager.
2. Write a short runbook (a one-page operations note). Cover what the app is built with, which versions and integrations it has, where data lives, and how a new release goes to production.
3. Set up monitoring and decide who gets the alerts. Cover uptime, application errors and background jobs, with a named owner and a backup person.
4. Set up backups and run a restore test. Write down how long it took. That's your realistic downtime in a serious incident.
5. Agree on an update rhythm. Small updates every month and a dated plan for the next framework and PHP major version.
6. Put responsibilities in writing. Use the split above and get it into a maintenance agreement with response times, prices and rules for out-of-hours work.
7. Hold a short quarterly review. Go through versions, incidents, budget and the next items on the roadmap.

Next steps

If the checklist exposed gaps, start with ownership and backups. They're the two most expensive things to be missing, and neither needs a big contract. Tackle the rest in whatever order your budget allows.

If you'd like help, here's how I handle maintenance and ongoing development for existing web apps. You work directly with the developer doing the work, and you own the code.

Frequently asked questions

Can a new developer take over maintenance of an app someone else built?+

Yes, but it starts with an audit. A new developer needs access to the code, servers and third-party services, plus time to understand how the app fits together. Good documentation and tests make this much faster. Expect the first hours to go into mapping versions, risks and urgent issues before regular updates begin.

Do I need a data processing agreement with my developer?+

Usually, yes, if your developer can access personal data in your production database or backups. They are then processing data on your behalf, and GDPR Article 28 requires a written contract with processors. The same typically applies to your hosting provider. This isn't legal advice, so check with a lawyer if you handle sensitive data.

Does my web app have to be hosted in the EU?+

Not necessarily. GDPR doesn't require EU hosting, but transferring personal data outside the EU/EEA needs a valid transfer mechanism, such as an adequacy decision or standard contractual clauses. Hosting servers and backups in an EU region avoids most of those questions, which is why I usually recommend it for European businesses. Get legal advice if you handle sensitive data.

How long does a Laravel major version upgrade take?+

It depends on how many versions you skip and how many third-party packages the app uses. Laravel itself says it aims for upgrades to the next major release to take a day or less. That holds best for apps that are kept current and have automated tests. Skipping several versions takes longer.