How does retainer hour banking work — can unused hours roll over?

Short answer

Retainer hours bank within a 90-day rolling window: unused hours from a given month carry into the next two months, then expire. Hours do not accumulate indefinitely. This keeps the retainer in a true ongoing-engagement frame rather than a stored prepayment.

How it works

A standard Melina retainer commits a fixed monthly hour pool (typical sizes: 20, 40, 80 hours). Within a calendar month, hours are consumed against scheduled work — incremental review, recurring scope assessment, ad-hoc consultation, post-engagement deep-dive sessions.

If a month closes with unused hours, those hours bank into the next month. They remain available for up to 90 days from the original month they were committed. After 90 days they expire — the rationale is that a retainer is intended to maintain a continuous working relationship and embedded technical context, not to provide credit storage.

Why hours expire

Retainers work because the engaged engineer keeps the system context loaded — recent codebase changes, recent incidents, recent architectural decisions. That context decays over time. A six-month bank of unused hours, when finally consumed, would mean re-loading context from scratch — at which point the retainer model is no longer providing what it's designed to provide.

The 90-day rolling window is the compromise between client flexibility (uneven monthly demand) and the operational reality of keeping useful context loaded.

Adjustments we make on request

Where a client has a known cyclical workload (annual product launches, quarterly compliance cycles), we structure the retainer with explicit higher-allocation months rather than relying on bank rollover. This produces predictable capacity at the high-demand points without the rollover-expiration tradeoff.

Related

- Engagement models — Retainer detail - Engagement models — overview - How does the disclosure window interact with client PR timing?

---