Support and maintenance
Keeping live software running, fixing what breaks, and taking over a codebase someone else built. Four different things get called “support”, and they are priced differently.
Certificates that expire, dependency updates, security patches, a hosting account that needs paying, backups that should be tested rather than assumed. Nothing visible happens — that is the point. Predictable, and the cheapest thing on this list to do properly and the most expensive to neglect.
Something worked and now does not. Unpredictable by nature, which is why it is priced by response arrangement rather than by hours, and why what counts as “broken” has to be written down.
A new field, a changed rule, an extra column in a report. Not faults, and the category that quietly consumes a retainer if nobody agreed where a change stops being small.
Someone to ask when a person cannot work out how to do something. A different job from the three above, needing availability rather than engineering, and frequently a sign the interface needs work instead.
Where a takeover starts
Nobody can look after software they cannot build, deploy or log into. So the first deliverable is not a fix — it is a list of what you hold and what nobody can find.
Inheriting a codebase
Once the inventory above exists, the rest of a takeover is a sequence. You get told which of these steps produced a surprise, because that is usually what decides whether the software is worth keeping.
Confirm, account by account, who the repository, domain, hosting, database, app-store accounts, certificate and email records are registered to — and get anything held elsewhere transferred before work starts.
Until the software can be built and run on a machine that is not the original developer's, nobody can safely change anything. This is where undocumented steps and missing configuration surface.
Old software is not automatically unsafe, but unpatched components with published vulnerabilities are. This produces a list ordered by real exposure rather than by version number.
The business rules that exist only in the code, the manual step someone does every month, the thing that must not be touched. If the previous developer is reachable, this is the hour to use.
Sometimes the answer is a small amount of tidying and a quiet retainer. Sometimes it is that the software should be replaced within the year. You get told which, with the reasoning, before signing anything ongoing.
Use this against any supplier
Replying within four hours and fixing within four hours are different commitments at different prices. An agreement that names only one of them has not been thought about.
And explicitly what happens outside them. “Business hours” with no timezone is not a term.
The boundary that decides whether a retainer holds or is exhausted early. It needs a definition both sides would recognise, written before the first disagreement rather than during it.
They should be in your name, with your supplier given access. If the arrangement is the other way round, you cannot leave, and that is not a small detail.
Third-party outages, changes to systems you do not control, and problems caused by someone else's edits. Sensible exclusions; they should be visible rather than discovered.
What you receive on the last day: the code, the credentials, the documentation, the deployment instructions. An agreement without an exit clause is a dependency, not a service.
A retainer set once and never examined drifts: either you are paying for capacity you do not use, or small changes have quietly consumed it. A scheduled review of what was spent and what is waiting keeps it honest both ways, and belongs in the agreement.
Everyone agrees urgent work should be urgent until it has to be defined. The useful test is consequence: the site is down, money cannot be taken, data is being lost, a legal deadline is at risk. Everything else is ordinary work with a date on it.
Tell us what the software does and who built it. The first useful answer is usually about access rather than code, and it comes before any commitment.