Web Development
Website Maintenance: What Businesses Should Budget After Launch
Launch is the start of the bill, not the end of it. A live website needs updates, backups, uptime checks, and a way to change content without opening a crisis. Businesses that skip that work do not save money. They pay it later as a hacked form, a lapsed certificate, or a homepage that still advertises last year’s hours. This is a maintenance budget in plain language, written for owners who do not want to become sysadmins.
What “maintenance” covers (and what it does not)
Maintenance is the work that keeps the current site true and reachable. It is not a redesign, a new shop, or a marketing campaign. Mixing those in the same monthly retainer is how both sides get angry: the client thinks every idea is included, and the shop cannot plan. Write the boundary down.
- Included in maintenance: platform and plugin updates, SSL, backups and restore tests, uptime alerts, spam and malware triage, small copy and image swaps, dependency patches.
- Not included: new page templates, new integrations, SEO retainers, ad spend, photography, rewriting the offer.
- Grey area that should be priced: a new location page, a form field that changes the workflow, a third-party script the marketing team added without telling anyone.
A calendar instead of a vague retainer
If you only “update when something breaks,” you will update during an outage. Put the boring jobs on a calendar and assign a name to each one. The name can be an employee, a freelancer, or an agency. It cannot be “we’ll see.”
| Cadence | Task | Why it exists |
|---|---|---|
| Daily (automated) | Uptime check and backup job | You find out the site is down before a customer tells you on Monday |
| Weekly | Inbox for form spam, failed payments, certificate warnings | Quiet failures do not email the owner unless someone looks |
| Monthly | CMS, plugin, and dependency updates on staging first | Unpatched software is how most small-site compromises start |
| Quarterly | Restore a backup to a throwaway environment | A backup you have never restored is a hope, not a plan |
| Yearly | Domain, hosting, and DNS access review; prune unused admins | Former contractors with admin logins are a common hole |
Backups are a restore problem
Ask where backups live, how many days you keep, and whether they include the database, uploaded files, and environment configuration. A file-only backup of a PHP app is incomplete. A database dump without the .env or equivalent is incomplete for disaster recovery, even if you must store secrets more carefully than the public files. Test a restore on a schedule. The first time you try should not be the afternoon the disk dies.
Also decide the recovery target in business terms. “We can be down overnight” is a different hosting and backup design than “we take bookings every Saturday morning.” Do not buy enterprise uptime language for a site that can wait until the next business day, and do not host a booking calendar on a $5 VPS with no snapshot if Saturday is the business.
Updates, staging, and the fear of breaking the layout
The reason owners freeze updates is that a plugin once wrecked the header. The fix is not to freeze forever. It is to update on a staging copy, click the money paths (home, service, contact or checkout, login if you have one), then update production. If you have no staging, you are gambling. Many hosts include a staging site; use it. If the stack cannot be staged, that is a reason to simplify the stack, not a reason to skip patches. The security side of that argument is covered in secure web development practices.
Who is allowed to install things
Marketing tools love to add pixels, heatmaps, and chat bubbles. Each one is a third-party script with a performance and privacy cost. Maintenance should include a rule: nobody adds a script without naming the owner, the purpose, and a review date. Orphaned tags are a frequent cause of slow pages and surprise cookie banners.
Content maintenance is part of reliability
A technically healthy site that still lists a closed location is failing. Put seasonal hours, price lists, and staff bios on a checklist the operations manager owns. Developers should not be the ones who notice you moved offices. If those facts change often, they belong in fields a non-developer can edit, not in a banner image with text baked in.
- Hours, phone, and address — verify monthly if you have walk-in traffic.
- Service list and “we don’t do X” notes — verify when you hire or drop a service.
- Legal pages — review when you change forms, analytics, or payment processors.
- Broken links after URL changes — check whenever you publish a new IA.
- Expired offers and event pages — unpublish; do not leave dead CTAs in the nav.
What to budget without fake precision
Costs vary with stack and traffic. A static brochure site with almost no plugins is cheap to keep. A WordPress site with a shop, a page builder, and ten marketing scripts is not. A custom PHP app with a database is a different line again: you are paying for application care, not only CMS clicks. Ask for a monthly range that assumes routine updates, plus an hourly or ticket rate for anything that changes behaviour. Avoid “unlimited small changes” retainers unless “small” is defined in writing (for example: three copy edits under 30 minutes each).
Scriplit can take on this kind of care as part of web development services when we built the site or when the stack is something we are willing to own. If you need a second pair of eyes on an existing site, send the URL, the host, and how you currently get notified of downtime through the web development contact form. Bring access questions early: who holds the registrar, who holds the host, and who can still log into the CMS.