Website & Application Maintenance and Support
The second year is the one that matters.
Most software is funded to launch and then left to decay. Dependencies age, certificates lapse, and the person who built it moves on. Maintenance is unglamorous and it is the difference between an asset and a liability.
What people come to us with
The situation before the solution
The original developer is gone
No documentation, no handover, and nobody left who knows how it deploys. Every small change feels risky, so changes stop being made.
Security updates nobody is applying
Dependencies with known vulnerabilities, an expiring certificate and an admin login still using the default. None of it urgent, all of it accumulating.
It has got slower and nobody noticed
A page that loaded in a second now takes five, one small addition at a time, and the fall in enquiries is blamed on the market.
Small requests take weeks
There is no routine, so every change starts from cold. A regular cadence costs less than a sequence of emergencies.
Capabilities
What the work covers
Taking on inherited code
We start with an audit and documentation, so there is a written picture of the system before anyone changes it. This is most of what we are asked to do.
Security and dependency upkeep
Patches applied on a schedule, dependencies kept current in deliberate steps rather than one frightening leap every three years.
Performance work
Finding what actually got slow — queries, images, scripts, hosting — and fixing it, measured before and after.
Bug fixing and small enhancements
The steady backlog of corrections and improvements that keeps a system matching the business as it changes.
Monitoring and uptime
Knowing a site is down before a customer tells you, with errors tracked rather than discovered.
Working alongside your team
Covering a gap, taking the maintenance load off your in-house developers, or acting as the team of record — whichever fits.
How we approach it
The order we do things in, and why
- 01
Audit before touching anything
What it runs on, what it depends on, how it deploys, where the risks are. We will not make changes to a system we cannot yet describe.
- 02
Secure the basics first
Backups that have been tested by restoring one, access under control, and the urgent patches applied. Before improvements, before features.
- 03
Document as we learn
Written down as it is discovered, so the knowledge belongs to you rather than to whoever happened to do the work.
- 04
Settle into a rhythm
A regular cycle with a visible backlog, so you can see what was done and what is next instead of wondering what you are paying for.
Technologies
What we typically build this with
Questions
Things people ask first
Yes — inherited systems are most of this work. We begin with an audit and tell you honestly what we find, including the case where the responsible recommendation is to rebuild a part rather than keep patching it.
We agree these with you per engagement rather than publishing a tier we might not be able to honour for your specific system. Expect a direct conversation about what you need and what we can commit to.
Upkeep, security, fixes and small changes are maintenance. New features and substantial rework are quoted separately. We set the line out in writing at the start, because an unclear boundary is what sours these arrangements.
Not usually. We work with your existing hosting unless it is itself the problem, in which case we will explain why and what moving would involve before recommending it.
Often the best arrangement. We can carry the upkeep so your team stays on the product work, with the split of responsibilities agreed explicitly so nothing falls between us.
Start a project
Have a problem that looks like this?
Tell us what it costs you today.
Two fields to start. We will come back with an approach and an honest view of what it takes — not an instant quote.