Systems need running.
The hard part isn't getting a system to work once — it's keeping it working the hundredth time, after the model updates, the API changes, and the team starts asking “can it also do this?” The retainer is that ongoing attention, month to month after the first quarter.
- A system I built that your business now depends on
- AI workflows that need eval checks as models change
- A steady stream of small improvements and additions
- A direct line to the person who built it — no ticket queue
Monitoring and incident response
When something breaks or drifts, it's caught and fixed — usually before anyone notices.
Model and dependency updates
Models improve and deprecate on their own schedule. Updates get tested against your evals before they land.
Continuous small increments
The “can it also…” requests that make a system compound in value instead of rotting.
A standing channel
Questions answered by the person who built the system, not a support tier.
The retainer starts where a build or engagement ends — it exists so delivered systems stay delivered.
Three months to establish the rhythm: monitoring in place, update cadence set, backlog shaped.
After the first quarter it runs month to month. If the system is stable and the backlog is empty, pausing is fine.
A good fit when
- The system is load-bearing for your business
- You'd rather own outcomes than manage maintenance
Probably not, when
- Nothing has been built yet — start with a build
- The system is internal, non-critical, and rarely changes
Have a workflow, tool, or product that needs building?
Send me the messy version. I reply with an honest take — what I'd build, what I wouldn't, and what it would cost.
Start a project