Maintenance and bug fixes
Reserved capacity for the software you already have running: fixing what breaks, keeping dependencies current, and handling the small changes that would otherwise sit in a backlog for a year.
The agency that finished and moved on
The build was delivered, the team was reassigned, and now a bug takes three weeks to get looked at because it has to be squeezed between other clients' projects. Meanwhile dependencies age, small annoyances accumulate, and the software slowly becomes something people work around rather than with.
You’ll recognise this if
- Bugs wait weeks because whoever built it has moved on
- Dependencies are years out of date and nobody dares update them
- Small changes are quoted as projects with a lead time
- One internal developer is the only person who understands it
What we actually deliver
Capacity actually reserved for you
A monthly allocation held on our side, so your work is scheduled rather than fitted in. Response times are committed to and measured rather than described in general terms.
Dependency and security updates
Kept current continuously rather than in a frightening annual leap. Regular small updates are cheap; a three-year jump is a project in its own right.
Fixes traced to the cause
We fix the underlying defect rather than the symptom, and add a test so the same fault cannot return quietly. Suppressing symptoms is how a codebase becomes unmaintainable.
A written record of what changed
A monthly summary of what was fixed, what was updated, and what we think deserves attention next. Enough for you to see what you are paying for.
The way we approach it
Triage by consequence
Not everything reported is urgent and not everything urgent is loud. We agree severity levels with you up front so triage is a shared standard rather than a negotiation each time.
Reserve time for the underlying rot
A share of each month goes to the things nobody raises tickets about — flaky tests, slow queries, the module everyone avoids. Left alone, these are what make future work expensive.
Stay ready to hand over
Documentation stays current throughout, so ending the arrangement is straightforward. A retainer should continue because it is worth it, not because leaving is painful.
What changes
- Issues resolved in days, against a committed response time
- Dependencies current, without a periodic upgrade crisis
- Fixes that address causes and stay fixed
- A visible monthly record of the work done
Asked often enough to answer here
Can you maintain software you didn't build?
Yes, and a good share of this work is exactly that. We begin with a short review to understand the codebase and flag anything urgent, then move into the normal arrangement.
What if we don't use the full allocation?
We will tell you, and suggest either putting the time toward improvements or reducing the retainer. Billing for reserved capacity that is not needed is a good way to lose a client we would rather keep.
What counts as a bug versus a new feature?
We define it in the agreement so it is not argued case by case. Broadly: if it does not do what it was built to do, it is a bug; if it is being asked to do something new, that is feature work — which we also do, just tracked separately.
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.