The right choice when
- Your application is live and people rely on it every day.
- The team that built it has moved on, or has no time for upkeep.
- Small fixes and changes keep piling up with nobody to do them.
Support and maintenance
Software needs looking after once people depend on it. We monitor it, fix what breaks, keep its dependencies current and make the small changes that never justify a project. That includes software another team built.
By your team, your users or a monitoring alert.
Reproduced, prioritised with you, fixed and tested before release.
What happened, what changed and what would prevent it next time.
Releases go out at the quiet hours you choose.
01 / Is this the one
Support keeps a working system working. It is not the way to rebuild one, or to decide what to build.
02 / What the work covers
The plan is sized to your system. These are the usual parts.
We read the code, set up access and environments, and write down what we find before we change anything.
Uptime, errors and performance are watched, so a problem is often seen before a user reports it.
Issues are reproduced, fixed, tested and released, with a note of the cause.
Frameworks, libraries and servers are kept on supported versions, including security patches.
Minor features and adjustments from an agreed monthly allowance of hours.
03 / Limits and risks
Hosting providers, third-party APIs and app stores fail too. We agree response times with you in writing. We do not promise zero downtime.
With software we did not write, the first weeks go on learning it. Early fixes are slower than later ones.
When a platform is out of support, each fix costs more than the last. We will say when modernising is cheaper.
04 / What we can show
The habits a support plan depends on are the ones we use on software we operate ourselves.
A support contract for a named client. That work is not published, so we quote no response times or uptime figures from it.
05 / What to do next
The first step is a free call about the system and what worries you about it. We then look at the code and send a written plan and price.
A little clarity
Yes, including applications another team built. We start with an audit: we read the code, set up environments and write down what we find. Expect the first weeks to be slower while we learn the system.
Bug fixes, monitoring, performance work, dependency and security updates, and small changes from an agreed allowance of hours. Larger features are quoted as their own piece of work.
By releasing at the quiet hours you choose, testing each change before it goes live and keeping a way to roll back. We tell you before a release and after it. No one can promise a system will never be down, so we agree response times in writing instead.
Every build comes with 30 days of free bug fixes after launch. Ongoing maintenance after that is optional, not a condition of the handover.
It depends on the size of the system, how many hours of change you want each month and the response times you need. The price is agreed after a free call and a look at the code.
Start wherever you are
We’ll look at what it needs to stay healthy, and say plainly if patching it is no longer the sensible option.