Service 04
Keep it running. Make it better.
Retainer support for software already in production — feature work, dependency and security updates, monitoring, and iteration from someone who already knows the codebase. For businesses in Claremont and the Pomona Valley who need their software to keep working without hiring a full-time engineer to make sure it does.
- Commitment
- Month to month
- Monitoring
- Included
- Based in
- Claremont
01 — What you get
What a retainer covers.
The small changes that keep arriving
The improvements too small to justify a separate project still need a place to go. A retainer gives them one, without turning every change into a new sales conversation.
Dependencies and security kept current
I review dependency and security updates, apply the relevant changes, and check the workflows your business depends on before release. The work is scheduled so updates receive regular attention.
Monitoring and continuity
Error tracking brings recorded failures to my attention. I also keep the context behind the code, so each change does not start with someone relearning how the system works.
02 — How it runs
How it works.
Start
Review and baseline
For systems I did not build, a paid review first: what is there, what is at risk, what needs attention soonest. You get that in writing whether or not we continue.
Monthly
Agreed priorities
We agree the month's priorities and the work that fits the available time. Routine changes are batched every couple of weeks, so you know what is next and when to review it.
Ongoing
Scheduled maintenance and repairs
Dependency updates, monitoring, and repairs continue between feature requests. When a problem appears, I investigate it; when a change is planned, I check it against existing behavior before release.
03 — Proof
Catalog changes an owner can follow.
On Mendivil, catalog changes run one at a time, and the owner can see whether an update is still building, live, or needs attention. Changing today's price leaves historical order amounts intact. Tests and error tracking support the work of finding faults and checking later changes.
Read the case study04 — Questions
Before you ask.
Do you support software you did not build?
Yes, after a paid review of the codebase. I need to see what is actually there before committing to keep it running — inheriting a system sight unseen is how support arrangements turn bad for both sides. The review is useful on its own even if we stop there; you get a written account of the risks.
What does a retainer actually cover?
Feature work, fixes, dependency and security updates, monitoring, and being reachable when something breaks. It is a block of time per month, spent on whatever matters most that month — not a fixed list of tasks that stops being relevant by the second quarter.
How fast do you respond when something is down?
For existing clients, I acknowledge emergencies — a site down, broken checkout, or data at risk — within four hours, any day, and begin work immediately. We agree how to reach me and what counts as an emergency at the outset. Routine changes are batched every couple of weeks.
Are we locked in?
No. Retainers run month to month and the code, infrastructure, and accounts are yours throughout. If you want to bring the work in-house or hand it to another developer, the documentation and tests exist to make that a normal handover rather than an excavation.
Already have something running?
Tell me what it is, what it runs on, and what worries you about it. If a retainer is not the right answer — if what you need is one fix, or a different developer entirely — I will tell you that instead of selling you a monthly commitment.