Get stalled software projects back under control.

The agency stopped answering emails in March. Before that, the project had been two weeks from launch since Christmas. The business has a login to a hosting account, a code repository it has never opened, and invoices for most of the budget. What it doesn’t have is anyone who can say how close the software is to working.

Projects rarely stall for a single reason. Usually the scope grew faster than the plan, the code was written in a hurry with no tests to catch what broke, and the people who understood it moved on. By the time anyone looks closely, the original supplier has every reason to be optimistic, and nobody independent has looked at all.

Sometimes the honest answer is that the code is sound and the project needs a clearer plan and a steadier hand. Sometimes more of it needs rebuilding than anyone would like. We’ll tell you which, and we’ll tell you before you spend any more money.

We start with a technical audit. We read the code, check the architecture, security, hosting, tests and documentation, and talk to anyone who worked on it. You get a written report that says what to keep, what to fix and what to rebuild, with a cost and a timeline for each route.

If you go ahead, we stabilise the project before we extend it. That means getting the code into source control you own, putting backups, a deployment pipeline and monitoring in place, and writing tests around the parts that matter most, so every change from then on can be checked. Then we pick up the remaining work in an order that puts the software in front of users as early as possible.

The same approach works for software that’s already live but fragile: a system that breaks every time someone changes it, or one that only a departed developer understood.

The first thing you get back is an answer to the question nobody has been able to answer so far, which is how far the project really is from done.