Support
Maintenance and support after the release, with a named scope
A launch is not the end of the system. We offer maintenance for products we built or that we have taken time to understand: defect fixes, small changes, dependency updates, and a path for incidents.
- Defect repair
- Small enhancements
- Security upkeep
- Operability
Support needs a boundary
“Unlimited changes” is how support contracts become unpaid product work, and then how quality slips. We agree what counts as a defect, what counts as a small change, and what needs a new quote. Response expectations are written to match the cover you are actually buying.
Keeping a system safe over time
Frameworks and libraries age. A maintenance engagement includes a cadence for updates that matter, especially where a known vulnerability is exploitable in your setup. We do not freeze a stack and hope.
Care after the release
Covered as support
- Defects in what we shipped
- Small changes you can describe
- Security updates you have agreed to take
A new quote
- A new module
- Unlimited redesign
- Someone else’s unmarked codebase with no handover
What changes a support agreement
The hours
Office-hours cover and a night desk are different products. We write the one you are buying.
The codebase
We can support what we built, or a system we have had time to read. Not a surprise repository.
The line
A defect, a small change, and a new feature need different answers or the work becomes unpaid product.
What a support agreement needs
- 01
The codebase
What we built, or a system we have had time to read.
- 02
The hours
Office cover, or a night desk. They are different.
- 03
A defect
An example of what you would call broken.
- 04
A small change
An example of what you would call a tweak, not a new module.
Marks support is a system
- 01
A ticket has an owner
Every request sits with a person, not in a shared inbox with no name.
- 02
A fix has a check
The change that closed the bug can be run again so it stays closed.
- 03
The backlog is visible
Waiting work is listed with a priority, so a date is not a surprise.
- 04
An incident has a note
What broke, what was done, and what to watch next are written down.
What we build
Defect repair
Reproduced, fixed, and covered by a check so the same failure is less likely to return.
Small enhancements
A monthly or quarterly allowance for changes that do not redesign the product.
Security upkeep
Dependency updates and configuration fixes, prioritised by exposure.
Operability
Help with deployments, failed jobs, and the questions your team hits in the first months.
How an engagement runs
- 01
Learn the system
Repository, hosting, data, and the incidents already in the backlog.
- 02
Agree the channel
How a request arrives, how severity is judged, and who may approve a change.
- 03
Keep a rhythm
A regular look at errors, updates, and the small list of improvements worth doing.
Questions we hear
Do you support software another company wrote?
Yes, after a paid discovery so we are not guessing. If the code or the hosting is too opaque, we will say what has to be clarified before a support promise is real.
Is this a 24/7 war room?
Only if that cover is contracted and staffed. Otherwise we agree business-hours response and an emergency path that matches the risk.
Can support include an AI feature later?
New AI features are product work. They can follow a maintenance relationship, but they are scoped separately so the support fund is not silently consumed.