Service 04 / Long-term Support
The part after launch.
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.
Feature work that keeps arriving
Software that stops changing starts dying. A retainer is how the small improvements — the ones never big enough to justify a project — actually get made.
Dependencies and security kept current
Updates applied steadily rather than in a panicked batch two years later, when every version jump is breaking and nobody remembers what the code does.
Monitoring that reaches me first
Error tracking wired to alerts, so problems get found by instrumentation rather than by a customer sending an email about a broken checkout.
Context that does not need rebuilding
The expensive part of maintenance is someone relearning a system every time. Continuity is the product here — I already know why the code is shaped the way it is.
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
A short conversation about what matters most this month, then the work. No ticket ceremony, no status meetings that cost more than the fix.
Ongoing
Quiet maintenance
Updates, monitoring, and the unglamorous work that keeps the loud problems from happening. Most of the value shows up as things that never break.
03 — Proof
Built to be maintained, from the start.
The Mendivil storefront carries 52 test files, error tracking, and catalog operations serialized behind a database-enforced lock with explicit states the owner can read. None of that was needed to launch. All of it is why the site can change in its second year without every deploy being a gamble — which is exactly what support work depends on.
Read the case study04 — Where I work
Based in Claremont. Working across the Pomona Valley.
Support relationships run for years, which makes proximity worth more than it is for a one-off build. Clients in Claremont, La Verne, Montclair, and across the Pomona Valley get someone who can come in and sit with the team when something needs working through in person.
- Claremont, CA
- Pomona, CA
- La Verne, CA
- San Dimas, CA
- Upland, CA
- Montclair, CA
- Ontario, CA
- Rancho Cucamonga, CA
05 — 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.
What if we do not use the hours in a given month?
Quiet months are the normal case for a stable system, and you should not be paying for busywork to justify a retainer. Unused time is better spent on the work that never makes it onto a roadmap: dependency upgrades, test coverage, performance, and the documentation gaps that make the next change expensive.
How fast do you respond when something is down?
Errors are monitored, so I usually know before you send the email. Response expectations get agreed explicitly at the start rather than left implied — what counts as an emergency, what can wait until the next working day, and how you reach me for each.
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.