Maintenance & Support
The team that built it keeps it healthy
Updates, tested backups, monitoring and a fix when something breaks - by the people who know the code, with a monthly report of exactly what was done.
A demo month on a demo shop - the shape of the report you get.
What a month of care includes
The quiet work that keeps a product from ageing, done on a rhythm and written down, so nothing depends on anyone remembering.
Updates, tested first
Frameworks and packages brought current on a fixed rhythm, checked on staging before they reach production.
Backups that are restored, not just taken
A backup nobody has restored is a guess. We restore one to a spare database and note that it worked.
Monitoring on what matters
Uptime, errors, slow pages and the jobs that run at night - with alerts that reach an engineer, not an inbox.
Security patches
Known vulnerabilities in your dependencies are tracked and patched, and access that is no longer needed is removed.
Small improvements
The fixes and small features that never make a roadmap - a slow screen, an export, a confusing form - picked with you.
A monthly report
What was updated, patched, fixed and added, what broke and why, and what we would look at next.
When something breaks
Things do break. What you are paying for is what happens next: it is noticed, owned, fixed properly and explained to you.
An example incident on a demo shop. Real response times are agreed with you and written into the plan.
- 14:02
Alert
Monitoring sees checkout getting slow and pages the engineer on the account - before anyone has to write in.
- 14:06
Acknowledged
Someone who knows the code picks it up, and you hear that it is being looked at, in the channel you already use.
- 14:41
Fixed
The cause is found and the fix goes out the normal way - reviewed, tested, deployed - not patched live on the server.
- 17:30
Explained
A short write-up: what happened, who it affected, what changed so it does not happen the same way again.
Taking over a site we did not build
Not every product comes to us from our own team. When it does not, we do not start by promising anything - we start by looking.
- First, an audit
- Access to hosting, DNS and the code; whether backups restore; how far behind the dependencies are; known vulnerabilities; how it deploys; where the secrets live; what is watched.
- Then, the urgent part
- Anything that needs attention - a backup that has never been restored, a reachable vulnerability - is fixed first, and you see the list before we do it.
- Then, the normal month
- Once the ground is solid it joins the same rhythm as everything we built ourselves, with the same monthly report.
If the audit turns up deeper security questions, that is a security audit of its own.
CheckedNeeds attention first
Questions we get asked
Do you only look after software you built?
No. For a product someone else built we start with an audit - access, backups, dependencies, known vulnerabilities, deploys, secrets and monitoring - and fix what needs fixing before we take it on.
How fast do you respond when something breaks?
Response times are agreed with you up front, based on how critical the product is, and written into the plan. Every incident ends with a short write-up.
What is in the monthly report?
What was updated, patched, fixed and added that month, any incident and what caused it, and what we would look at next.
Are backups actually tested?
Yes. Part of each month is restoring a backup to a spare database and noting that it worked.
Can small features go into the plan?
Yes. Small improvements are part of the month and picked with you. Anything larger is scoped as its own piece of work.
How is it priced?
Tell us what the product runs on and how critical it is - we come back with what a month would include and what it costs.
Launched, and now it needs looking after?
Tell us what it runs on and how critical it is - we come back with what a month would include.