Software Project Rescue
Rescue it. Then decide whether to rebuild.
Abandoned, late and still billing, failing in production, or a prototype that will not go live. A troubled application is diagnosed, not restarted. Five days to a written verdict.
You leave knowing whether this is stabilise, repair or replace, and what week one looks like.
Not your situation?
Secure your access before anyone touches the code
Rescuing a software project starts with control, not with code.
Access is lost permanently. Code is not.
- The source repositoryOwner access, not collaborator access, plus a full clone including every branch and tag held somewhere you control.
- The cloud and hosting accountsOrganisation-owner access, with the billing relationship in your company name rather than someone’s personal card.
- DNS and the domain registrarWhoever controls DNS controls where your product resolves and who can issue certificates for it. Frequently overlooked and rarely recoverable quickly.
- CI and the deploy pipelineNot visibility. The ability to actually run a release without one specific person being available.
- Secrets, keys and third-party accountsPayments, email, storage, error tracking, any model provider. Inventory them, then rotate every credential anyone leaving the project has seen. Rotation is the point.
- A database backup you have restoredTake one today, prove you can restore it into an environment you own, and keep a copy off the vendor’s infrastructure. A backup nobody has restored is a belief.
Five days to a written verdict
Time-boxed because your money is burning while you decide, and an open-ended audit bills for the deciding. A live system that is failing now gets a first read before day five.
- Access and orientationRepository, deploy record, incident history, and the business’s own account of what was promised. Nothing is changed on day one.
- Commit and deploy archaeologyWhat shipped, when, by whom, and how releases actually happen versus how they are described.
- Reading the code that mattersThe business-critical paths, the data model, the integrations, and the test suite that exists measured against the one that was claimed.
- People and constraintsThe current team, the incumbent vendor, the contract exposure, and the dates the business genuinely cannot move.
- The verdict, written downStabilise, repair or replace, with the reasoning, the evidence behind it, and the ordered list of what to do first.
A rewrite is only defensible when you understand the requirements better than you understand the code. Everything else is repair, wrapping, or incremental replacement.
Portable, even if you stop here
Written to be used by somebody else. A verdict you cannot take elsewhere is not a verdict, it is a quote.
- A written verdict — stabilise, repair or replace — with the reasoning and the evidence it rests on
- The real state of the system: what deploys, what is tested, where the business logic actually lives
- An ordered stabilisation list, with what to do first and why
- The access, credential and IP gaps found, with the urgent ones marked
- The questions any next vendor should be made to answer before they quote
“He is going to tell me to rebuild it”
It is the right suspicion, because a rebuild is the largest engagement I could sell you. A promise not to say it would be worth nothing. So the rule that decides it is published above instead, before you have paid anything, and the verdict is reasoned from evidence you can check rather than asserted.
The verdict is yours to take to any vendor, including one that is not me. It is written for an engineer who has never spoken to me. Delivery through ViitorCloud is a separate decision you make afterwards, and you can make it differently.
No project commitment. No predetermined technology. No pressure to proceed when the evidence says stop. And no figure quoted for work that has not been scoped.
Questions people ask first
Will you tell me to rebuild it?
Only if the evidence says so, and the evidence is written down where you or any other engineer can check it. The rule is published on this page rather than applied privately: a rewrite is only defensible when you understand the requirements better than you understand the code. The verdict is reasoned rather than asserted, so the argument can be attacked on its merits instead of taken on trust.
What if I do not have access to my own code?
Then that is the first problem, ahead of the code itself, and it is why the checklist on this page comes before anything I sell. Secure everything you already have the right to access, and take legal advice before pressing for anything you do not. Where there is no repository at all, a diagnosis can still run against the running system, the deploy record and the contract. It is a weaker read and I will tell you it is weaker rather than dress it up.
Do I have to fire my current developers?
No, and it is the wrong week to decide. The people who built it hold information that exists nowhere else, and they usually expect to be blamed, which is the fastest way to lose that information permanently. Establish the facts first. If a change of team is the right call it will still be the right call in week two, and by then you will be able to explain why in terms the team, the board and the next vendor can all follow.
How long before I know whether this is salvageable?
Five working days for the written verdict. A production system that is actively failing gets a first read sooner than that, because stabilising something that is losing money now does not wait for a document. It is time-boxed because your money is burning while you decide, and an open-ended audit bills for the deciding.
Establish the facts first
Bring whatever you have: a repository you cannot deploy, a vendor still invoicing, or a production system failing in front of customers. Five days, then a written verdict you own.
In the age of AI
The advantage was never the model. It's knowing what to build with it — and having a team that can actually ship it.
That's the part I help with: finding where AI genuinely makes your business faster, deciding what's worth building, and standing behind it once it's live.
Four offices, one very full passport
Every dot on this map is a conversation I still remember.
- Where I've spoken
- Office
