Support that outlasts the build
What we actually do when you hand us a system that already exists, whether it has been running for eight years or stopped half way through being written.
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 are real. A backup nobody has ever restored is not a backup.
- 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.
None of that is interesting work and all of it is cheaper than finding out later.
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 can tell you what happened at three in the morning without anybody guessing.
That part is unglamorous and it is the difference between a system you can improve and a system everyone is afraid to touch. Once it is done, changes stop being events and become ordinary work.
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 actually 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
People usually want the hosting looked after as part of the same arrangement, so we do that as well. It adds a layer of work underneath the application. Operating system patches, runtime and framework upgrades, certificate renewals done with enough margin that nobody is doing them at midnight. Alerting that reaches a person rather than a shared mailbox.
Where it runs is your call. Microsoft Azure, Amazon Web Services, Google Cloud and DigitalOcean are the ones we use most. We work inside whichever account your company already has. Small community sites are the exception. There is usually nobody to hold an account, so we can do it ourselves.
Cost is part of it. Cloud bills drift upward on their own, usually through a test environment nobody switched off or a database still sized for a launch that happened two years ago. We look at the bill from time to time and tell you what can come off it.
Project rescue
Rescue is the same work starting from a worse position. The build stopped part way through. There may be no documentation, no environment that runs and nobody left to ask.
The approach does not change, it just takes longer at the start. We establish what runs, what was finished, what was started and abandoned and what was never begun at all. Then you get an honest read on whether the existing code is worth carrying forward or whether some part of it is better rewritten. That answer does not always suit us and you will get it anyway.
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.