Support that outlasts the build
What we do when you hand us a system that is already running, from the first look through to the day to day.
Software is rarely retired because it stopped working. It gets retired because nobody left understands it well enough to change it safely. Support is the work that keeps a system on the right side of that line.
We look after software we built and software we did not. In practice the second kind is more common. Somebody wrote it, it did its job for years and then that person moved to another company or another department and the code quietly became nobody's.
What the first look involves
We do not quote on an existing system without spending time inside it first. That normally means:
- Reading the code and getting it running locally, which is often the first time in years anybody has tried.
- Working out how it gets deployed and whether that process exists anywhere other than in somebody's memory.
- Finding where the data lives, how much of it there is and whether the backups can be restored.
- Listing what has no tests, what has no logging and what would fail without anybody noticing.
- Checking what has fallen out of support. Framework and runtime versions, the operating system, certificates and any library with known problems.
Finding these things now costs far less than finding them after something fails.
What you get out of it
A written summary in plain language. What the system is, what condition it is in, what would break first and roughly what it would take to deal with each item. It is ordered by risk rather than by effort, so you can decide what is worth doing now, what can wait and what is fine left alone.
Sometimes that document says the system is in decent shape and needs very little. We would rather tell you that than invent a project.
Making it safe to change
If work follows the review, the first stretch is usually not new features. It is getting the system into a state where changing it is not a gamble. Source control, if there is none. A build that produces the same result twice. Somewhere to test that is not production. Logging that shows what happened overnight without anybody guessing.
It is not exciting work, but without it every change is a risk. Once it is done, changes become routine.
What ongoing support looks like
Once a system is stable, support settles into a rhythm. We agree what gets watched, how often updates are applied and how quickly we respond when something breaks. All of that gets written down, so neither side is working from an assumption.
The day to day is mostly small. Patching, dependency updates, certificate renewals, database housekeeping and the steady stream of minor fixes and improvements that come from people using the software. Larger pieces of work get scoped and quoted on their own rather than absorbed quietly into a monthly bill.
When the hosting is ours to run
Most people want the hosting looked after as part of the same arrangement, so we do that as well. Operating system patches, runtime upgrades, certificate renewals and alerting that reaches a person rather than a shared mailbox. It runs in a cloud account opened in your name.
The managed hosting page has more on how that is set up and who holds what.
Project rescue
Rescue is the same work on a build that stopped before it was finished, often with no documentation and nobody left to ask. It takes longer at the start. At the end of the review you know which parts are worth keeping.
The project rescue page goes through a rescue step by step.
If you only want the review
Some people want the assessment and nothing else, either to decide what to do next or to have something concrete to take to whoever holds the budget. That is a perfectly good outcome. You get the document, you keep the code and you take it from there. Nothing is conditional on continuing with us.