A website may look fine on launch day, yet six months later its certificate can expire, plugins can conflict, forms can fail, former employee accounts can remain active, content can become impossible to edit, and backups may never have been tested. Maintenance is not simply “call a developer when something breaks.” It also means detecting problems, reducing their likelihood, and recovering quickly after a failure.
Per-request, monthly, and annual maintenance are not inherently better or worse. The choice depends on how often the website changes, how much the business depends on it, internal capability, and acceptable downtime risk. Clarify these factors before comparing quotes.
01 Distinguish Warranty, Maintenance, and New Development
A warranty generally addresses issues within the delivered scope caused by the original code or configuration. Maintenance includes upgrades, monitoring, backups, content support, and routine minor changes. New pages, features, business integrations, and full redesigns are new requirements. Combining all three under “one year of free maintenance” creates different expectations on each side.
The contract should define what counts as a bug, what counts as an environmental change, which revisions have labor caps, and whether third-party service changes are included. Otherwise, responsibility is difficult to determine when a browser update causes a compatibility issue or the client’s own code change causes a failure.
02 Per-Request Maintenance: For Low-Frequency, Low-Dependency Websites
Per-request service has no fixed monthly fee. Labor and scheduling are evaluated when a need arises. It suits stable, presentation-focused websites with few content updates where brief downtime does not directly affect core operations.
The downside is that response time may not be guaranteed and the vendor may not retain full project context. Relearning the environment creates startup costs, and finding urgent help during an incident is often more expensive than routine maintenance.
Suitable For | Not Suitable For | Contract Focus |
|---|---|---|
Only a few content or style changes per year | Websites dependent on form leads or frequent campaigns | Minimum billing, response time, and environment access |
An internal owner manages the domain and server | No one controls accounts and backups | Urgency handling and cost to relearn legacy code |
Website can tolerate a longer repair window | Downtime directly affects transactions or services | Quote approval method and acceptance criteria |

03 Monthly Maintenance: Buying Continuously Available Response Capacity
Monthly service suits companies that publish content continuously, launch campaign landing pages, frequently adjust product materials, or depend heavily on the website for sales leads. A fixed allowance can cover routine inspections, small changes, version updates, and issue response.
A monthly fee should specify more than “monthly maintenance.” List included hours, response levels, monitoring scope, backup frequency, volume of content support, and overage pricing. Otherwise, the client may expect unlimited changes at any time while the team views the fee only as an availability retainer.
- Monthly available hours and whether they roll over;
- Response and handling targets for routine, important, and urgent issues;
- Scope of backups, recovery drills, uptime monitoring, and security updates;
- Volume limits for content publishing, image processing, and page adjustments;
- Whether third-party services, plugins, and server fees are billed separately.
04 Annual Maintenance: For Stable Budgets and Continuous Accountability
Annual contracts often combine monthly services, routine inspections, and an annual review. They suit companies seeking a stable budget, a consistent team, and fewer procurement cycles. They do not mean every redesign is included after a single payment.
The value of annual service is continuity: the team understands the website’s history, accounts, and technical debt and can plan upgrades and content changes in advance. The contract should still include quarterly or semiannual reviews so the service does not become an unused automatic renewal.

05 Let Business Risk Determine the SLA, Not a Template
A corporate website, recruiting site, campaign site, and customer portal have very different failure tolerance. An SLA can distinguish local page errors, broken forms, inability to publish through the admin system, and full-site outages. Define response, communication, and recovery targets for each level so every issue is not labeled “urgent.”
Cloud services, domain registrars, cyberattacks, and third-party API failures outside the vendor’s control should also have defined collaboration responsibilities. An SLA does not promise zero errors; it defines who does what and when after a problem occurs.
Incident Level | Example | Reasonable Commitment |
|---|---|---|
Routine | Copy error or non-core style issue | Add to the regular schedule |
Important | Some pages fail or admin publishing is blocked | Prioritize a response during business hours |
Critical | All forms fail or a key entry point is unavailable | Confirm quickly and provide a workaround and repair plan |
Emergency | Entire website is unavailable or a major security incident occurs | Communicate immediately, isolate risk, recover, and conduct a review |
06 Accounts and Exit Procedures Are Commonly Overlooked
Under any model, the company should retain highest-level access to the domain, server, code repository, CMS, analytics, and third-party platforms. A maintenance vendor may manage them, but handover must be clear when the engagement ends.
Exit terms should cover data and source-code export, account transfer, key rotation, final backups, unused hours, migration support, and information deletion. Without an exit process, long-term maintenance can easily become technical lock-in.

07 Compare the Three Options by Total Cost of Ownership
Per-request service may look inexpensive, but include emergency surcharges, repeated environment familiarization, and losses from failures. Monthly and annual service may have higher fixed costs, but can reduce downtime and internal coordination costs.
Review the past year’s actual needs—content updates, incidents, version upgrades, marketing campaigns, and internal effort—then estimate next year’s changes. The maintenance model should evolve with the website; it need not be a permanent choice.
08 Include an Example Exclusions Table in the Maintenance Contract
“New functionality is not included” remains too abstract. List common boundaries: changing existing copy versus adding a new page template; fixing a defect in original code versus adapting to a changed third-party API; restoring a backup versus reentering lost content. Examples reduce ad hoc disputes.
Also define responsibility after the client modifies code, installs plugins, changes servers, or exposes account credentials. The vendor may assist with diagnosis, but cannot accept unlimited responsibility for an uncontrolled environment.
After each maintenance task, record the issue, cause, action, and prevention step. At the annual review, these records help determine whether to upgrade the architecture, expand monitoring, or use a different maintenance model.
Frequently Asked Questions
Must a company purchase maintenance after launch?
Not necessarily, but it must identify who owns updates, backups, monitoring, accounts, and incident response. If an internal team can handle them, outsourcing is optional.
What does one year of complimentary maintenance usually include?
Follow the contract. It is usually closer to a warranty for delivery defects and should not be assumed to include new features, ongoing content operations, or third-party environment changes.
Can unused monthly maintenance hours roll over?
There is no universal rule; the contract must define it. Unlimited long-term rollover makes vendor scheduling difficult, so a limited carryover period is another option.
Are server and plugin fees included in maintenance?
Not necessarily. List third-party costs separately to avoid unclear asset ownership when maintenance fees change.
What is needed to change maintenance vendors?
At minimum: source code, deployment documentation, account permissions, an environment-variable inventory, backups, domain DNS, third-party services, and known issues.
Service | View |
|---|---|
Website Development Services | |
Website Project Handover Checklist | |
Project Consultation |