Maintenance and support
Most of this work starts the same way: the original developer has gone, documentation is thin, and nobody wants to touch it. We read the code first and tell you what state it is really in before quoting anything.
Ask for a takeover assessment Compare all five models
The assessment is a fixed piece of work and the report is yours either way.
| Can it be built and deployed By someone new, from the repository | Week 1 |
|---|---|
| What is unsupported Libraries and runtimes past end of life | Week 1 |
| Where the risk sits The parts nobody dares change | Week 1 |
| What is undocumented Knowledge that left with someone | Week 1 |
| Rebuild or maintain An honest recommendation | Week 2 |
The honest question first
Support contracts on software that should be replaced are how companies spend a rebuild budget without getting a rebuild.
Consider replacing when
We will say this plainly even though a support contract would earn us more.
Worth maintaining when
Then the job is stability, plus enough documentation that you are never trapped again.
Plain definitions
Support agreements go wrong when these are left vague, because both sides then remember them differently.
Four kinds of work, and they compete for the same budget. Corrective work fixes what is broken. Adaptive work keeps the system running as the platforms underneath it change. Perfective work makes small improvements users ask for. Preventive work pays down the risks that would otherwise become outages.
Most disappointment here comes from buying corrective cover and expecting perfective work. Agree the split in advance, in hours or in proportion, and revisit it every quarter rather than arguing about it during an incident.
Severity levels defined by business impact rather than by technical symptom. A response time for each, meaning when a human starts work, which is different from a fix time. Cover hours in a named time zone. And what happens when the target is missed.
Response and resolution are the pair people conflate. We commit to response times and we give honest estimates on resolution, because promising a fix time for a fault nobody has seen yet is a number invented to win a contract.
What support includes
What people ask us for
The first two are the most common, and both start with somebody having left.
Our work
Case study, United Kingdom
Hydrajaws had testing software that was poorly documented and whose code they did not own. Rather than patch around it, we rebuilt it as two apps from one codebase with identity behind Azure AD B2C, then kept working on it as the product grew into new markets.
On new builds we include a warranty period as standard. The Norwegian school platform had 60 days after go-live.
Commercials and governance
The structure matters more than the number, and it is where most support relationships quietly fail.
Who does the work
Support is where a small team is a genuine advantage. The person who answers your ticket in year two is likely to be the person who read the code in month one, and that continuity is most of what you are paying for.
You meet whoever will hold your system. Ask what they would want to fix first after reading it, because a useful answer means they actually read it.
How we work
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
A team that works only on your product, with a lead on our side running delivery.
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
04
One price for a scope that is genuinely settled, with the overrun carried by us.
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
FAQs
Yes, and it is most of this work. We do the assessment first so both sides know what we are agreeing to.
Normal. We write it as we learn, and you keep it. That is often the most valuable part of the first year.
Sometimes. Send the details and we will say honestly whether we would be any good at it.
We cover the hours your users are active. Genuine round the clock cover needs a team sized for it, and we will tell you if that is what you actually need.
Then we say so in the assessment, and you can take that recommendation to anyone including us.
Your company, including everything we add during support.
Monthly retainer, time and materials, or per incident, and we recommend based on your actual volume rather than on what is largest. As a sanity check, the convention people quote is 15 to 20 percent of the original build cost per year, which is a way of testing whether a quote is reasonable rather than a price we are offering. Send the system and you get a real figure. Which engagement model you pick decides how work beyond the retainer is billed, and the models are set out above.
We commit to response times by severity, and we agree them after a discovery period rather than in a proposal. As a shape, a system-down severity is measured in tens of minutes during cover hours, a high-priority fault in hours, and a routine request in business days. Resolution times get an honest estimate per fault, because committing to a fix time for something nobody has seen is a sales number.
We can cover extended hours and we are honest about the limits of a team of twenty. Genuine around-the-clock cover with a rota that survives illness and holiday needs more people than we have, so if your system truly requires it, we will say so and help you scope what does. Most systems that ask for it turn out to need extended hours and a tested escalation path instead.
Two weeks later you will have an honest report on its state and a recommendation, including the recommendation to replace it.
