Your software stays
current, stable, and
actually maintained.

Software maintenance keeps deployed software healthy: security patches, dependency updates, bug triage, performance monitoring. Ongoing development adds new features to the roadmap. The maintenance retainer covers operational health, not the product roadmap. If you need both, they run as separate scopes with separate budgets. Some clients run a maintenance retainer alongside a dedicated development team for exactly this separation.

Yes. All new maintenance engagements begin with a technical onboarding review: an abbreviated read of the codebase covering architecture, dependency state, known issues, and security posture. This gives the maintenance engineer enough context to respond effectively from day one. Most clients starting from a new codebase request the full code audit first, which is then credited toward the first month's retainer. The audit produces the baseline; the retainer maintains it.

Maintenance retainers run on a month-to-month basis after the initial onboarding period. The onboarding period is 2 to 4 weeks depending on codebase complexity: this is when the engineer reviews the code, sets up monitoring, and establishes the dependency baseline. After that, you can pause or cancel with 30 days written notice. There are no long-term lock-in clauses.

The report covers five sections: (1) Issues resolved this month with timestamps and root cause notes, (2) Dependency updates applied with a list of packages and versions, (3) Security advisories reviewed and actions taken, (4) Performance metrics compared to the previous month's baseline, (5) Recommended actions for next month with estimated effort. The report is delivered as a PDF and a shared document. All supporting commit hashes are linked so every claim is verifiable in the git history.

Every maintenance engagement has a designated secondary engineer who has reviewed the same codebase documentation. They carry the runbook and can respond within the P1 service level agreement window. Vacation or leave periods are communicated 2 weeks in advance, and the secondary engineer is explicitly briefed before any planned absence. The service level agreement commitments apply regardless of which engineer responds.