What a maintenance agreement should cover

You've just learned that your software system needs regular maintenance, but you're not sure what you're actually paying for. Is it just fixing bugs when they pop up? Should the agreement cover preventive work? What happens when something breaks at midnight on a Sunday? A maintenance agreement sets these expectations in writing, so you and your developer are on the same page and there's no confusion when problems arise.

Maintenance agreements vary wildly in scope and quality. Some are bare-bones — react only to reported issues — while others include monitoring, updates, security patches and performance reviews. The difference between a cheap, narrow agreement and one that serves your business well often comes down to what's actually written into the contract.

What must be in the agreement

Start with response time. Define what "urgent" means to your business and specify how quickly the developer will acknowledge a critical bug report (same day, within two hours, etc.). Include escalation: if something is truly breaking your operations, what does "critical" look like, and will they drop other work to address it? This matters enormously if your software is revenue-facing or time-sensitive.

Scope of work should be explicit. Will the agreement cover bug fixes only, or also minor feature requests? Does it include security patches, dependency updates, and system library upgrades — the unglamorous work that prevents your system from becoming outdated and vulnerable? Make sure there's clarity on what's *excluded* too: new features, major rewrites, third-party integrations, or database migrations often warrant separate quotes.

Define the support channel and hours. Can you email questions, or do you need a phone line? Will the developer respond during business hours only, or is there on-call coverage? Some agreements include a monthly check-in call; others don't. If your system rarely breaks but you want assurance someone is available, that's a legitimate ask — but it will show in the cost.

Include provisions for testing and transparency. The developer should test bug fixes before shipping them. They should tell you what they fixed, why it broke, and what changed. A maintenance agreement without a changelog or ticket trail is a red flag; you won't know what work was actually done.

Address version control and access. Confirm the developer has write access to the codebase (or that you'll grant it without delay) and that they're working from the latest version. If the original developer is long gone and the code is scattered across old machines or USB drives, maintenance becomes theatre. The agreement should make clear that proper version control is a prerequisite.

What *not* to miss

Include a schedule for backups and disaster recovery testing. If your database goes down, can your developer restore it? Do they have a tested plan, or are you hoping for the best? A strong maintenance agreement names a backup provider and confirms that restores are tested regularly.

Cover payment and cancellation terms. Will you pay monthly or quarterly? Can either party cancel with notice, or are you locked in? If the developer goes silent, what's your exit? Some agreements include a minimum term (say, six months) but allow cancellation with 30 days' notice thereafter. That's fair; open-ended contracts with no exit clause are not.

Confirm who owns the code and credentials. You should own the code outright; the developer is the custodian during the maintenance period. Passwords, API keys, hosting credentials and third-party accounts should be stored securely and accessible to you (or another trusted person) if the developer becomes unavailable.

Ask what success looks like. Will the developer provide uptime reports, performance metrics, or a quarterly summary? Without measurable outcomes, you can't tell whether the maintenance is actually working or just costing you money.

A solid maintenance agreement is a contract that lets you sleep at night. It removes guesswork about cost, availability, and scope. When you're ready to find someone who offers clear, documented maintenance terms, use Strove to compare developers and read verified client feedback on how they actually handle ongoing support.