Incremental feature work
Software earns most of its value after launch, in the accumulated small improvements that come from watching real people use it. This is a standing arrangement to deliver those, at a pace matched to your budget.
Improvements that have to be projects
Every change, however small, needs a scope, a quote, and an approval cycle — so only large changes are ever worth the overhead. The small frictions that annoy users daily never clear the bar, and the product slowly stops fitting the business while everyone waits for a rewrite to be funded.
You’ll recognise this if
- Small improvements never happen because the process costs more than the change
- You have a backlog of good ideas nobody has touched in a year
- Users have stopped reporting friction because nothing came of it
- The gap between the product and the business keeps widening
What we actually deliver
A predictable delivery cadence
Work shipped on a regular rhythm rather than accumulated for a quarterly release. Small, frequent changes are easier to review, safer to deploy, and simpler to reverse.
A backlog kept honest
Requests captured, sized, and ordered by value against effort — with the things that will never be worth doing marked as such rather than left to haunt the list.
Changes informed by actual use
Where instrumentation exists, we use it. Which features are used, where people abandon a flow, what they retry — a far better guide to what to build than a request list.
Refactoring in proportion
A portion of the capacity kept for paying down the accumulated debt that would otherwise make each subsequent change slower and riskier.
The way we approach it
Small enough to reverse
Changes sized and shipped so that any one of them can be rolled back without ceremony. That is what makes a fast cadence safe rather than reckless.
Prioritise together, monthly
A short regular session to re-order the list against what has changed in your business. Priorities set once at the start of a year are wrong by March.
Say when something isn't worth building
Sometimes the honest answer to a request is that the effort exceeds the benefit, or that a configuration change achieves the same thing. We would rather say so than bill for it.
What changes
- Steady, visible improvement rather than long silent gaps
- A backlog that reflects real priorities and gets shorter
- Changes small enough to deploy and reverse without drama
- A product that keeps pace with the business
Asked often enough to answer here
How is this different from maintenance?
Maintenance keeps what exists working; this makes it better. Most clients want both, and they are usually combined in one retainer with the split between them agreed and visible.
What size of team does this involve?
It scales to the budget — for many clients it is a fraction of one engineer's month, which is enough for meaningful steady progress. We would rather be honest about what a given budget buys than imply a larger team.
Can we pause it?
Yes. Budgets move and priorities change. We would rather you pause and come back than feel locked into spending that is not currently earning its place.
Related
Wherever you’re starting from, let’s figure out the next step.
Tell us what you’re building — we’ll tell you honestly whether we’re the right team for it.