Rescue and Support
Take on the software nobody wants to touch.
What usually goes wrong
Working software and safe software are two different things, and the gap only shows up on the worst possible day. When we look inside software built in a hurry, we usually find the same handful of problems. The passwords to the system are sitting somewhere anyone who looks can find them. There is no backup, or there is one that nobody has ever tried to restore. Faults happen and nobody is told. The people who built it were not careless. They were working fast, with tools that never mention which parts are missing.
What you end up with
- A plain English report on what is actually wrong and what each problem would cost you
- The passwords to your system changed and properly hidden
- Backups that work, which you have watched being restored
- Someone told when something breaks, before your customers notice
Inside rescue work
A full check
Three to five days going through everything, including the history of every change ever made, which is where old passwords tend to hide. It ends in a written report with every problem rated by how serious it is, and an hour on a call going through it with you.
Fixing what matters
Passwords changed and hidden properly. The lock moved to the right side of the door. Backups switched on and restored in front of you. Alerts wired up so a person is told. Out of date parts brought up to date carefully. A tested way to undo a bad change.
Ongoing support
Security updates on a schedule, backups tested rather than assumed, someone watching for faults so you are not the one who finds them, and a short written report each month. This is what stops everything drifting back.
Writing it all down
Most software we take on has no instructions at all. We write them as we go, so how it works is not trapped inside whoever touched it last.
Taking over from someone who left
Where the original developer or agency is gone, we work out how everything fits together by reading it, then take responsibility for it.
Building on it again
Once it is stable and we know it properly, we can add to it. We will not add features to software we have not read.
What you get
- A written report with a plain English summary at the front for whoever is not technical
- Every problem rated by how serious it is, with the real world consequence spelled out
- A list of what to fix first, ordered by risk rather than by how easy it is
- Backups that work and a tested way to undo a bad change
- Alerts that reach a person
What is not included
Saying this plainly saves everyone a call.
- Formal security certification. We find the obvious problems, we are not an accredited auditor.
- A promise that a check finds every fault. Nobody can honestly offer that.
- Selling you a patch when the honest answer is starting again. If that is the answer, we say so, even when it costs us the work.
- New features before the software is safe to change
How this runs
- 01
Sign a confidentiality agreement
Signed before you give us access to anything. It covers your software, your information and anything else we happen to see.
- 02
Read only access
Checking your software means reading it, not changing it. We do not ask for the ability to change anything, and we do not ask for your customers' information.
- 03
The check
Three to five days of reading. If we find something genuinely urgent, you hear about it the same hour rather than waiting for the report.
- 04
Report and walkthrough
The written report, then an hour on a call going through it. What you do next is entirely your decision. Taking the report to your own developer is a perfectly good outcome.
- 05
Fix, then keep it working
If you want us to do the work, it arrives in small pieces you can check. Your live site is untouched until you approve.
How this is usually arranged
We do not publish rates, because a number without a clear scope would mislead you. You get a real, fixed figure in writing after one conversation.
Fixed price project
A defined result, a fixed price and a delivery date, all agreed before work starts. If you want something added later, it is priced separately rather than absorbed quietly or argued about at the end.
Best for
A well understood piece of work: a website, an app, a check of existing software.
Monthly support
A set amount of our time each month for looking after your software, making small changes and improving things gradually. It rolls on monthly, can be stopped with thirty days' notice, and always ends with a handover document.
Best for
Software that is live and needs to stay safe, up to date and working.
What people ask about this
We need to be able to read it, and that is all. We sign a confidentiality agreement before you give us anything. We do not need the ability to change anything, and we do not need your customers' information, to tell you what is wrong.
No, and not out of politeness. Almost everything we open looks like this, because it was built under time pressure by people trying to get something working. The mess is the job. What we care about is what it would cost you if it broke, not how it got that way.
It is common, and it is fixable. These tools are good at producing something that works and poor at the parts nobody sees: backups, keeping passwords safe, telling someone when a fault happens. Knowing which tool was used mostly tells us where to look first. It does not change the price or the approach.
Only the people actually working on it. We do not pass your work to another company, an outsourced team, or a rotating group of contractors. Access is given narrowly and taken away when the work ends.
Anything you send us goes into a locked password manager, never into email, chat or a shared document. We ask for the least access that lets us do the job, and we ask you to remove it when we are finished. If we find your passwords sitting somewhere unsafe inside your own software, changing them is the first thing in the report.
You get written instructions and a walkthrough with whoever will look after it. Then either your own team runs it, or we keep looking after it for a monthly fee. Both are fine, and we will tell you which one we think suits you. What we will not do is disappear on launch day and leave you with something nobody understands.
You might also need
- 01Websites and Web AppsCompany websites, online shops, customer portals and internal tools, built so they stay fast and stay easy to change.
- 02Online ProductsSubscription products and platforms, including the accounts, payments, permissions and behind the scenes work a product needs once paying customers arrive.
Talk to us about this
Thirty minutes, nothing to prepare. We will tell you honestly whether we are the right studio for it.