We're hiring Head of Marketing, and always listening for the next →

Services · Support · Development support

Development retainers. Named people, a visible queue.

Ongoing capacity for the work that comes after launch. You should never have to raise a purchase order to fix a typo.

Launch is the point the real backlog starts

The list does not stop at go-live. A page needs a new section, a campaign needs a landing template, a form needs another integration, and something small breaks. Handled as individual projects, each one costs a scoping call, an estimate and two weeks of waiting for work that takes an afternoon.

A retainer replaces that with standing capacity: an agreed amount of engineering time each month, named people who already know your codebase, and a backlog you can see and reorder.

It is deliberately not an unlimited-work promise, because that is not a real thing. It is a defined amount of time, spent on whatever you decide matters most that month, and any unused capacity goes into the improvements we think you need rather than being quietly billed for nothing.

How we actually do it

Transparent capacity, your priorities.

01 · Agree the capacity honestly
A defined number of days per month, sized against the backlog you actually have. We would rather size it correctly than sell you more than you will use.
02 · Keep the backlog visible
A shared board you can see and reorder. You decide priority each cycle; we flag the technical debt and risks that will not surface on their own.
03 · Same people, every month
Named engineers who already know the codebase. Continuity is most of the value, a new developer spends the first two days reading before they can be useful.
04 · Report time against outcomes
Where the days went and what shipped, every month. If capacity is consistently short or consistently unused, we resize rather than let it drift.

What you get

Deliverables, not adjectives.

  • Agreed monthly engineering capacity with named people
  • A shared, reorderable backlog you control
  • Defined response expectations for urgent issues
  • Monthly reporting on time spent against what shipped
  • Proactive flagging of technical debt, dependencies and risk

Questions, answered straight

No fluff, as promised.

What if we do not use the full capacity in a month?

We will propose improvements worth spending it on, performance, accessibility, dependency updates, technical debt. We will also tell you if the retainer is consistently too big and should be resized down.

What is the difference between this and hosting and maintenance?

Hosting and maintenance keeps the site running: patching, monitoring, backups. A retainer is capacity to change and improve it. Most clients on a retainer have both.

Can you support a site you did not build?

Yes, after a code review so we understand what we are taking on. Occasionally that review concludes the honest answer is a rebuild rather than a retainer, and we will say so.

Need capacity
after launch?

Tell us what you're working on. You'll get an honest answer about whether we can help, and exactly how.