Engagement model
Engineering capacity that is there when the live system needs it
Reserved senior capacity for a product already in production. Not a full standing team, and not a scramble for availability every time something needs doing — a known amount of engineering, held for you.
- Best for
- A live product with continuous needs but not a full team’s worth.
- Engagement type
- Reserved capacity on a recurring commitment.
- Your involvement
- You prioritise the backlog. We work it.
- Our responsibility
- Availability, engineering quality and the health of what we touch.
- Primary outcome
- A live product that keeps improving instead of drifting.
You probably need this when
This model exists for the awkward middle: too much ongoing work to handle ad hoc, not enough to justify a permanent team.
The build finished but the work did not
The project team has gone and the product is live. Changes still need making, and there is no longer anyone whose job that is.
Nobody is reliably available when production breaks
Incidents get handled by whoever is free, which means slowly, and by someone relearning the system each time.
Integrations and third parties keep needing attention
A partner changes an API, a payment provider deprecates something. None of it is large; all of it needs an engineer who knows the system.
Technical debt is accumulating with nobody paying it
Everyone agrees it should be dealt with and it never survives prioritisation against feature work, because there is no reserved capacity for it.
Performance is degrading as usage grows
The system was fine at launch volumes and is not fine now, and diagnosing it properly keeps being deferred.
What this engagement means
You are buying availability against a live system. The capacity is reserved for you whether or not you use all of it in a given period — that is what makes it dependable.
This isn’t
- A full standing team working a roadmap
- An unlimited support arrangement — the capacity is defined and finite
- A managed service that runs your infrastructure for you
- A fixed scope with an agreed end state
- Capacity that rolls up indefinitely if you do not use it
This is
- A defined amount of senior engineering capacity, reserved for your product
- A prioritised backlog you control, worked through at an agreed cadence
- Support when production needs attention, from engineers who know the system
- Ongoing product changes, integrations, performance work and technical debt
- Engineers who stay with your system, so context is not rebuilt each time
What you get
The output is a live system that keeps getting better, and the confidence that someone is holding time for it.
- An agreed amount of senior engineering time held for your product
- A prioritised backlog worked at a predictable cadence
- Engineers who already know the system when something is needed
- Performance and reliability work as usage changes
- Technical debt reduced deliberately rather than opportunistically
- Dependency and platform upgrades kept current
- Support during incidents affecting the live system
- Diagnosis and fixes, plus the change that stops a recurrence
- Product changes and integration work as they arise
How we work together
You decide what matters; we decide how it is built and answer for the engineering. Priorities are the one genuinely shared line, because a live system does not always respect a backlog order.
| Responsibility | Client | Shared | CipherCru |
|---|---|---|---|
| Roadmap and product decisions | Included | Not included | Not included |
| Backlog prioritisation | Included | Not included | Not included |
| Day-to-day priorities | Not included | Included | Not included |
| Technical decisions | Not included | Not included | Included |
| Engineering standards | Not included | Not included | Included |
| Quality assurance | Not included | Not included | Included |
| Incident response | Not included | Included | Not included |
| Reporting on capacity used | Not included | Not included | Included |
How the engagement runs
A repeating cycle rather than a project with an end. The first two stages happen once; the rest keep going.
System handover
We learn the product properly — architecture, deployment, dependencies, the parts everyone is nervous about — so we are useful before the first incident rather than after it.
Capacity agreement
We agree how much capacity is reserved, how it is prioritised, and how urgent work interrupts planned work.
Prioritisation
You set the order. We are explicit about what fits in the reserved capacity and what does not, so the trade-off is visible rather than discovered later.
Delivery cycle
Work is delivered at an agreed cadence — changes, integrations, improvements — with production support taking precedence when it has to.
Review
We report what the capacity was spent on and what the system needs next, so the arrangement can be adjusted rather than assumed.
Is this right for you?
Retained capacity suits a system that is live and staying live. If the work is a defined push or a full roadmap, other models fit better.
A strong fit when
The product is in production and the need is continuous but moderate.
- You have a live system with a steady stream of changes and fixes
- You need availability you can depend on rather than ad hoc bookings
- Technical debt and performance work keep losing to feature work
- A full standing team would be more capacity than you need
Consider another model when
The volume of work has outgrown a retainer, or it has a defined end.
- There is enough sustained work to keep a full team busy
- You have a defined piece of work with a clear end state
- You want engineers working under your own process and leadership
- You need someone accountable for a business outcome, not for capacity
Another model may suit you better: Dedicated Engineering Team — The work has grown past a retainer and needs a standing team against a roadmap. Staff Augmentation — You would rather direct the engineers yourself, inside your own team and process.
This sounds like what we need.
Tell us about the system and what keeps needing doing to it. We will help work out how much reserved capacity it actually warrants.
How it works commercially
A retainer buys reserved availability. That is a different thing from buying a number of hours, and it is priced accordingly.
Retainer levels are agreed per engagement. Contractual detail lives in our engagement terms.
Compare relevant models
All three put senior engineers on a system you already have. The difference is how much, and who directs them.
| Retained Engineering | Dedicated Engineering Team | Staff Augmentation | |
|---|---|---|---|
| Is capacity ongoing? | Yes, reserved | Yes, a full team | Yes, per engineer |
| Who directs the work? | You prioritise, we sequence | CipherCru, to your roadmap | You do, daily |
| Suits which stage? | Live and evolving | Active roadmap | Any, if you have leadership |
| Whose engineering standards? | Ours | Ours | Yours |
| How much management from you? | Prioritisation only | Roadmap and review | Daily |
Other ways to work with us
If the work has grown past a retainer, or you want to run it yourself, these are the adjacent models.
Dedicated Engineering Team
A standing team that works to your roadmap with our own delivery lead, engineering standards and quality bar. It ramps up and stays with the product.
Best when the roadmap is long and the requirements keep moving.
- Where it fits: a product roadmap that runs longer than any single project.
- A named delivery lead who is in the standups, not reporting on them.
- You own direction and priorities; we own how the team delivers them.
Staff Augmentation
Senior engineers inside your team, under your process, your standards and your review. You direct the work day to day.
Best when you know what to build and lack the people.
- Where it fits: a roadmap that is agreed, funded and behind schedule.
- Knowledge transfer is a deliverable, so capacity does not become dependency.
- You own the backlog, the priorities and the delivery risk.
Not sure which model fits? Tell us the situation and we will point you at the right one. See all seven engagement models
Common questions
What clients ask before putting a live system on a retainer.
What happens when production breaks?
What if we don’t use the capacity in a quiet month?
Who decides what gets worked on?
What if a piece of work is bigger than the retainer?
Do you need to have built the system originally?
Can a retainer become a full team later?
Stop finding out who is free when something breaks
Tell us about the system and what it keeps needing. We will tell you how much capacity it warrants — and if the answer is none, we will say that too.
Retained Engineering
Engagement model