What a retainer covers
A retainer covers the work that begins the day a product meets real users.
Feature development
Against a rolling priority list.
The work that never appears on a roadmap
Responding to what usage data reveals. Paying down the deliberate shortcuts taken to hit a launch date. Keeping dependencies and security patches current. Holding the architecture together as the product grows in directions nobody scoped.
Senior technical judgement
Which build-versus-buy call to make, when a rewrite is genuinely warranted and when it is procrastination, and what to tell an investor asking about technical risk.
It also covers the operational work a launched product acquires. Monitoring that tells you something is wrong before a customer does. Backups that have actually been restored at least once. Security updates applied before they become urgent. Enough documentation that a future hire is productive in days rather than weeks.
None of this appears on a roadmap, and all of it is the difference between a product that can be scaled and one that has to be rescued.
Why continuity is the point
The most expensive thing about post-launch development is re-explaining the system.
Every new agency, contractor or hire costs weeks of context before they are net positive, and early-stage products rarely have documentation good enough to shorten that. A retainer with the team that wrote the architecture removes that cost entirely: the person deciding whether a change is safe is the person who chose the data model.
This is the same reason we decline staff augmentation work, where engineers are treated as interchangeable capacity. The value we add is judgement accumulated on your specific product, and that does not transfer between bodies.
There is a second cost that is harder to see: judgement quality falls when context is missing. An engineer without history will make a defensible decision that happens to be wrong for reasons written down nowhere, and the consequence surfaces months later.
Continuity is what keeps the decisions consistent with the architecture they sit inside.
How it runs in practice
The retainer runs month to month at an agreed monthly rate, with a working agreement on rhythm and priorities rather than a ticket queue.
Priorities are set with the founder, not handed down. What changes this month is a commercial decision. The engineering input is what each option would cost, and what it would rule out later.
Because the retainer is monthly rather than annual, it is easy to scale down as an in-house team grows — which is usually the intended path. A successful retainer ends with the founder’s own engineers owning the product, and the handover being uneventful because they have had repository access all along.
Scope moves within the month rather than being fixed, because post-launch priorities move faster than a scoping process can follow. What stays fixed is the rate and the rhythm, so the budget is predictable even when the work is not. Where a month holds unusual work — a fundraise, a compliance review, a migration — that is discussed in advance rather than absorbed quietly or billed as a surprise.
Fractional CTO support inside a retainer
For most clients the retainer is where fractional CTO support lives.
It is deliberately part-time. A founder at this stage needs a CTO’s judgement far more often than a CTO’s full-time salary. Hiring the wrong full-time CTO early is far more expensive than waiting.
Where AI features are in play, the same retainer covers model and evaluation work as usage patterns shift.
The distinction between development capacity and technical leadership matters here, and a retainer usually contains both. Capacity alone leaves the founder making architecture decisions they are not equipped to make; leadership alone leaves good decisions unimplemented. Retainers are sized to whichever mix the product needs at the time, and that mix changes as an in-house team grows.
Terms
You own 100% of the code and intellectual property, as on every other engagement, and repository access is continuous rather than granted at handover.
Equity participation is available where there is genuine alignment, and always sits alongside fees rather than replacing them. Founders who would rather keep their cap table clean are not treated differently.
Retainers usually follow an MVP build, but we also take on products built elsewhere. In that case the first month is spent reading the codebase and writing an honest assessment of what it can and cannot support, before anything is changed.
Retainers can be paused or ended with reasonable notice, and we would rather a client stopped than continued out of inertia. A retainer that is not producing value should be a short conversation, not a renewal negotiation.
The measure we hold it to is simple: at the end of each month, the founder should be able to name what changed and why it mattered.