Most software gets built once and looked after never.
The project ends, the team moves on, and the application is left to fend for itself. It runs fine, until a dependency goes end-of-life, a certificate expires, a traffic spike takes it down at the worst possible moment, or a vulnerability lands and nobody is watching the feed. By then the people who understood it are long gone.
There is a whole model of software built around handing the finished thing over and walking away. It is cheaper on day one and more expensive on every day after. We work the other way: we stay, and we have the relationships to prove it works.
The slow failures
The ones that build up quietly. A framework two versions behind. A dependency with an open advisory against it. A disk filling up, a backup nobody has tried to restore, a certificate three weeks from expiry. None of it is urgent until all of it is.
The sudden ones
The ones that need a person, now. A payment provider changes their API overnight. Traffic triples because of something you did not plan for. An error starts throwing at six on a Friday. Someone has to be watching, and know the system well enough to fix it rather than just restart it.
01Proactive maintenance
Runtime and framework upgrades, PHP versions kept current, dependencies updated before they go end-of-life, and security patching applied before an advisory becomes an incident. Database optimisation as data grows. The work that stops problems happening rarely shows up as anything visible, which is exactly why it gets skipped when nobody is minding it.
02Monitoring, backups and recovery
Logging and monitoring so issues surface while they are still small. Backups that have actually been restored in a test, not just written and hoped over. And a disaster recovery plan you could rely on, rather than one that exists only on paper.
03Reactive support from someone who knows your system
When a supplier changes their API overnight or traffic spikes without warning, you get a person who already understands the application, not a ticket in a queue behind fifty others. Knowing the system is most of what makes a fast fix possible.
04Hosting and infrastructure
We manage the AWS account behind the application: keeping the infrastructure patched, the bill sensible, and applying newer services where they genuinely help. The application and the platform under it are looked after by the same team, so nothing falls down the gap between them.
05Improvements, not just upkeep
New features, integrations and workflow changes handled by the team that already knows the code. Because the knowledge is already in place, change stays cheap and safe for years, instead of getting more expensive as the original team's memory fades.
Relationships measured in years.
We have built and run Jaguar Land Rover's tooling software since 2013, and we still do, which is the kind of relationship this service is built to produce. It runs on AWS more often than not, and we are an AWS Select Tier Services Partner running a Well-Architected review on every engagement, so resilience, cost and security get looked at deliberately rather than left to drift. It runs in your own AWS account and you hold a copy of everything throughout: the arrangement lasts because it is worth keeping, not because leaving would be painful.
The relationship between us is genuinely a partnership rather than a supplier/customer scenario. They have suggested changes which we would probably never have considered but which have added value.
Looking after software is a relationship, not a retainer you hope never to use.
- 01
Learn it
We start with an audit of the application, its hosting and its dependencies, so we know what good looks like before we are the ones on call for it. If we did not build it, this is where we make it ours.
- 02
Look after it
Proactive and reactive together: runtime and dependency upgrades, security patching, backups that are tested rather than assumed, monitoring and logging so we see trouble before you feel it. And a person on the other end who knows your system when something needs one.
- 03
Keep improving it
Maintenance is not only holding the line. The same relationship is where new features, integrations and cost savings come from, because we already know the system and we are already here. The work compounds instead of starting cold each time.
The things buyers ask us first.
We didn't build it with you. Will you still take it on?
Yes. Taking over applications other people built is normal work for us: PHP in any of the major frameworks, Node, and the hosting underneath. We start with an audit so we know exactly what we are taking responsibility for before we agree to carry it.
What if nothing is wrong right now?
That is when proactive maintenance is doing its job: the patch applied before the exploit, the upgrade done before the runtime goes end-of-life, the backup tested before you need it. Waiting for something to break is the expensive way round, and the one that tends to break at the worst time.
Is this just a retainer for firefighting?
No. Most of the work is proactive - upgrades, patching, monitoring, backups - precisely so there is less firefighting to do. When something does need a person urgently, you have one who already knows the system rather than one meeting it for the first time under pressure.
Will we be locked in?
No. It all runs in your own AWS account and you hold a copy throughout: the code, the infrastructure definitions and the deployment pipeline. The arrangement continues because it is worth continuing. We would rather earn the next year than trap you in it.