Ongoing Maintenance & Support
I maintain existing web applications on a monthly retainer: bug fixes, small features, dependency and security updates, cloud infrastructure and deployment pipelines.
This is the service for products whose original developer has moved on, or for a business that needs a dependable engineer without hiring one full-time. You get a named person who already knows your codebase, not a ticket queue.
What does a retainer actually include?
An agreed block of hours per month, spent on whatever you need most, plus an agreed response time when something is broken.
Unused hours do not silently vanish into my margin — we agree up front whether they roll over or the retainer flexes. Whatever we agree, you get a monthly summary of what the hours went to, so the arrangement stays legible rather than becoming a subscription you forget you are paying for.
- Bug fixes, prioritised with you
- Small features and improvements
- Dependency updates and security patches
- Cloud infrastructure and cost review
- Deployment pipeline maintenance
- Monitoring, and being the person who responds when it alerts
- A written monthly summary of where the time went
Can you take over a codebase you did not write?
Yes — this is most of what this service is.
It starts with a paid handover period, typically one to two weeks, where I get the project running locally, read it properly, document what exists, and write down what worries me. You get that assessment as a deliverable regardless of whether we continue.
I would rather tell you honestly that a codebase is in poor shape and what that means for the cost of every future change, than take a retainer and quietly struggle with it while charging you for the confusion.
What if the previous developer left no documentation?
Normal, and expected. Undocumented handover is the default case, not the exception.
The handover period covers exactly this: getting it building from a clean checkout, mapping the architecture, identifying the deployment path, finding where the secrets and infrastructure live, and listing the risks — unsupported dependency versions, no backups, a server nobody can log into, a domain registered to someone who left.
That last category is what actually takes businesses down, and it is usually cheap to fix once someone has looked.
What about the infrastructure?
AWS in most cases, plus the deployment pipeline. Containerised services, managed databases, object storage, background workers, and CI/CD so a deploy is a merge rather than a person following a checklist over SSH.
I also review what you are paying for. Idle instances, oversized databases and forgotten storage are extremely common on inherited infrastructure, and the saving frequently covers a meaningful part of the retainer.
What you get
- Agreed monthly hours with a defined response time for outages
- Handover documentation for an inherited codebase
- Dependency and security update cadence
- Monitoring, alerting and someone who answers the alert
- Working CI/CD deployment pipeline
- Cloud cost review
- Monthly written summary of work done
Tools I use for this
A good fit if
- A working product whose original developer or agency has moved on
- A business dependent on software with nobody responsible for it
- A team wanting steady small improvements rather than a big project
- An owner who needs someone to answer when the site goes down at the weekend
Not a fit if
- 24/7 on-call with a minutes-level SLA — one person cannot honestly offer that, and you should not accept it from anyone who does
- Stacks outside my range (PHP/Laravel, .NET, Java, Ruby on Rails); I will not learn your production system on your budget
- Retainers that are really a full-time job in instalments — at that point hire someone, and I will help you interview
- Products the owner has decided to shut down; you need a migration and export plan, which is a different, shorter engagement
Work that shows this
Questions clients ask
What is the minimum retainer?
Retainers start in the region of twenty hours a month — below that there is not enough continuity for me to stay usefully current with your codebase, and you end up paying for context reloading rather than work. For occasional smaller needs, ad-hoc hourly is the honest arrangement and I will suggest it instead.
How quickly do you respond when something breaks?
We agree the response time in the retainer, matched to what your product actually needs. For most business applications same-business-day on a real outage is both realistic and sufficient. I will not promise a fifteen-minute response as a solo engineer, because I would not be able to keep it and you would find that out at the worst moment.
Can we start small and see how it goes?
That is the sensible way to do it. Start with the paid handover and assessment, then a month or two on a short-notice rolling arrangement before committing to anything longer. No long lock-in — a retainer that only survives because of a contract is not one either of us should want.
What happens if you become unavailable?
You keep everything: your repository, your infrastructure accounts, your documentation. That is the point of documenting the handover properly and keeping infrastructure in your own accounts rather than mine. Single-person dependency is a real risk and the correct mitigation is that nothing is locked inside my head or my accounts. Ask any developer this question before you hire them.
Need ongoing maintenance & support?
Tell me what you're building and what's in your way. I reply within 24 hours with honest questions and a rough estimate — no sales sequence.