Most of what we build rolls into a maintenance relationship after launch. We prefer retainers over ad-hoc invoices because software that gets maintained on a schedule costs less, breaks less, and wakes people up at 3am less often than software that only gets attention when something’s already on fire.
What a retainer covers
Every retainer is priced against a written scope agreed with the client. The shape of that scope varies, but the common components are:
- Named engineer. A single point of contact inside the studio who knows the codebase, the history, and the decisions behind it.
- On-call coverage. An agreed response window for production incidents, with escalation paths documented before they are needed.
- Scheduled upgrades. Framework, language, and dependency upgrades on a regular cadence, with written changelogs and a rollback plan for each.
- Feature work. Small feature additions and refinements, either against a monthly hour budget or billed on request.
What it does not cover
A maintenance retainer is not a replacement for the internal engineering team a product eventually needs. It is appropriate for the first year after launch, for products that remain small enough to be operated by a few engineers, or for infrastructure that a client intends to keep rather than rebuild in-house.
For products that outgrow this model, we do handover work: documentation, knowledge transfer, and introductions to engineers suitable for the next phase. The retainer can end whenever the client's internal team is ready to take over.
Engagement terms
Retainers are priced monthly and billed on the first of each month. Cancellation terms are written into the engagement; no retainer is locked into a term longer than a single quarter. Response windows, on-call rotations, and update cadences are agreed before work begins and documented in the contract.