Website & app maintenance
with a human on the end.
Ongoing updates, monitoring and a senior person to reach when something needs deciding.
- — Nobody has updated the CMS or dependencies in a year
- — When something breaks, you start by finding someone who remembers the build
- — Small changes queue up for months
The work should
change the numbers.
Software does not stay still. Dependencies release security patches, browsers change behaviour, platforms deprecate APIs, and a site that was excellent at launch quietly decays over eighteen months of nothing happening to it.
A maintenance retainer covers that drift and, more usefully, keeps a senior engineer who already understands your system available when something breaks or a decision needs making. Context is the expensive part of support; a retainer is largely a way of not paying for it twice.
Every retainer includes a small improvement allowance, because the difference between a site that ages well and one that does not is usually a couple of days of attention each month.
What the engagement
actually contains.
Dependency and platform updates
Core, framework, plugin and SDK updates applied on staging, tested, then released on a schedule.
Uptime and error monitoring
Synthetic checks, error tracking and alerting routed to us, so we usually know before you do.
Backups and verified restores
Automated backups with a restore rehearsed periodically rather than assumed to work.
Defined response times
Severity-based response commitments in writing, with an escalation path that reaches a person.
Improvement allowance
Included hours each month for the small changes that otherwise wait a year for a project.
Quarterly health review
Performance, security, accessibility and dependency risk reported with a prioritised action list.
- Monitoring and alerting configuration
- Monthly update and activity report
- Verified backup and restore procedure
- Written service levels and escalation path
- Quarterly technical health review
- Prioritised improvement backlog
- Nobody has updated the CMS or dependencies in a year
- When something breaks, you start by finding someone who remembers the build
- Small changes queue up for months
- Your last agency has moved on
What usually went wrong
before we were called.
- 01Leaving dependencies untouched for a year, then facing a major-version cliff
- 02Backups that have never been restored
- 03No agreed severity definitions, so everything is urgent
- 04Losing the only person who understood the build
- Uptime and time to detect
- Response time against agreed severities
- Dependency and patch currency
- Improvement hours used per month
Onboarding audit in week one, then continuous
What week one
actually looks like.
An onboarding audit: project running locally, deployment path documented, dependency and security risks recorded, monitoring and alerting pointed at us rather than at nobody.
- Repository, hosting and CMS access
- Domain and DNS control
- A primary contact for approvals
- Any existing documentation, however sparse
- New feature development beyond the improvement allowance
- Content writing or publishing
- 24/7 out-of-hours cover
- Third-party licence fees
Scope boundaries stated up front rather than discovered in a change request.
Four stages, visible throughout.
Assess
A baseline across performance, security, accessibility and dependency risk, with findings ranked by consequence.
Stabilise
The urgent items closed first: exposed surfaces, failing checks, missing backups, unpatched dependencies.
Automate
Budgets, scans and alerts moved into CI and monitoring, so regressions are caught by machines rather than customers.
Review
A quarterly session on what changed, what is drifting and what deserves next quarter’s attention.
Website & app maintenance, answered.
Typically four business hours for a critical outage, one business day for a functional defect, and a scheduled slot for improvements. The exact commitment goes in the agreement — vague promises about being responsive are worth nothing at 9am on a Monday.
Yes, after a short onboarding audit. We need to get the project running locally, understand the deployment path and record the risks we find. Occasionally that audit concludes the honest answer is a rebuild, and we will say so.
Improvement hours roll over for one month, so a quiet period is not wasted and you are not pressured into busywork. Monitoring, updates and incident response are not drawn from that allowance.
Security hardening & SSL
Hardening, patching, certificates and headers — the unglamorous work that prevents the bad week.
Hosting & domain management
Infrastructure, DNS and deploy pipelines managed so uptime stops being your problem.
Speed & performance optimisation
Core Web Vitals, bundle size and server response times taken seriously enough to move revenue.
QA & testing
Manual and automated coverage that finds the failure before your customers volunteer to.
Make website & app maintenance useful.
Bring us the hard thing. We will bring a point of view, a senior team and a clear next step.