Software Maintenance Agreement: What Should It Cover?

A software maintenance agreement should spell out five things: how fast the developer responds when something breaks, which updates are included and how often, how backups and monitoring work, how many hours you get each month, and what happens when the agreement ends. If those five aren't in writing, what you really have is a phone number and good intentions.

I sell maintenance myself, so keep that in mind, but the checklist works whoever you sign with.

The short answer: match the agreement to how critical the system is

There's no single right agreement. The service level should reflect what downtime costs you. Here's my rule of thumb:

No solo freelancer can credibly promise the last column (more on that below).

For the work behind the paperwork, start with my guide to web application maintenance.

The checklist: 13 clauses your maintenance agreement needs

Use it when you review a draft contract or a quote, and ask about anything missing before you sign.

If the developer can access personal data in your app, they usually act as a data processor under the GDPR, and you need a written data processing agreement too. Article 28 GDPR lists what that contract must contain, from documented instructions to deleting or returning the data when the work ends. This isn't legal advice, so check with a lawyer if you're unsure.

Response times: acknowledgement is not a fix

The classic trap is the "2-hour response time". Often that only means someone confirms they've seen your ticket. It doesn't mean the problem is solved.

A useful agreement has two numbers for each severity level:

1. Response time: when the developer is actively investigating.
2. Resolution time: when the issue is fixed, or a workaround keeps the business running.

Resolution can rarely be guaranteed when the cause sits with someone else, like your host, payment provider or a third-party API. Write that down, so nobody argues about it mid-incident.

My own baseline is to reply to every request within 1 business day. That covers most feature requests and normal bugs. If critical issues need a response within hours, add that as a separate tier, because the developer has to plan their day around it.

Time zones belong in the contract too. I work from Denmark on Central European Time, which overlaps with UK and EU business hours and with mornings on the US East Coast. If your team is elsewhere, state which time zone "business hours" refers to.

Then ask about holidays. A freelancer is one person, and that is the model's biggest weakness. The honest answer is a named backup developer with access to the documentation, or a written fallback plan, like instructions for your host to restore the latest backup. No answer is a gap in the agreement.

Updates and backups: put the invisible work in writing

Most maintenance is invisible, which is why it gets skipped when things get busy.

Framework and PHP versions have an expiry date. Under Laravel's support policy, each major version gets bug fixes for 18 months and security fixes for 2 years. Security support for Laravel 11 ended on March 12, 2026, and PHP 8.2 has security support until December 31, 2026. Once your app runs on an unsupported version, newly found vulnerabilities stay open. If yours is already far behind, see the signs your legacy PHP system needs modernizing.

So the agreement should separate three kinds of updates:

• Security patches: applied quickly and included.
• Routine dependency updates: a fixed round, for example monthly, also included.
• Major versions: often a small project, quoted separately, but scheduled so you never end up unsupported.

I explain why postponing them gets expensive in why you should keep software dependencies up to date.

Backups follow the same pattern. Many hosts take backups, but that tells you nothing about whether a restore works. My web app backup strategy guide covers the setup, and the roundup of uptime monitoring tools for web apps covers the other half: spotting failures before your customers do.

Hours and billing: how to avoid surprises on the invoice

Maintenance is usually billed in one of three ways:

• Monthly retainer with included hours: predictable, and the developer reserves time for you, but you pay in quiet months too.
• Prepaid block of hours: flexible, but it rarely comes with guaranteed response times.
• Pay as you go: no fixed cost, but no commitment to respond quickly either.

The trade-offs between the first two get their own post on developer retainer agreements. Whichever model you pick, three things must be clear: what included hours cover, what happens to unused hours, and how you're warned before the allowance runs out.

My recommendation is to put updates, backup checks and monitoring in a fixed monthly fee, and bill feature requests by the hour. That way the essential work doesn't get pushed aside by the fun stuff.

When a freelancer is the wrong fit

I'd rather say this upfront than promise something I can't deliver:

• You need 24/7 on-call cover. If an hour of downtime at 3 a.m. costs real money, you need a team with an on-call rotation. One person can't provide that.
• Your customers require formal guarantees. Documented processes, audits or penalties for missed response times fit an agency or a managed hosting provider better.
• The system is too simple to need an agreement. A small marketing site often just needs managed hosting and a developer you call when needed.

If none of these apply, a freelancer with a clear agreement often fits well: you deal directly with the person who knows the code.

Next steps: from checklist to signed agreement

1. Write down what an hour, a day and a week of downtime would cost you. That sets the service level.
2. Go through the checklist and mark every clause your current agreement or quote doesn't cover.
3. Ask the developer to answer the missing points in writing.
4. Check that the code, hosting and domain are in your company's name before you sign.

You can see how I set this up on my page about ongoing maintenance and development, and my rates are on the pricing page.

Frequently asked questions

How much does a software maintenance agreement cost?+

It depends on how critical the system is and how many hours you reserve each month. The price should follow from two things: included hours and response time. A reply within a few hours costs more than one within 1 business day, because the developer has to keep time free. Ask for a breakdown so you can see what you pay for.

Is a maintenance agreement the same as an SLA?+

Not quite. An SLA (service level agreement) describes the service level: response times, uptime and severity levels. A maintenance agreement is broader and also covers updates, backups, hours, ownership and termination. The terms are often used interchangeably, so check the contents, not the title.

Can I get a maintenance agreement for an app someone else built?+

Yes, but expect an onboarding phase first. A new developer needs to review the code, hosting and dependencies before promising response times. That review often turns up outdated packages or missing backups to fix first. It's a one-off cost, and cheaper than finding the gaps during a critical incident.

How long should a maintenance agreement run?+

There's no fixed standard, but I recommend a rolling agreement with one to three months' notice rather than a 12-month commitment before you've tested the relationship. Check that the notice period applies both ways, so you have time to find someone new and get access and documentation handed over if the developer is the one who stops.