Software project rescue and technical audit.
A build in trouble, an inherited codebase, or a vendor on the way out. It starts with a fixed-fee assessment of what was intended against what exists — then you decide what happens next, with us or without us.
What we do
- Intended versus actual
- What was meant to be built, reconstructed from the contract, the specifications, the tickets and the email threads — then compared with what actually exists and works.
- Code and architecture
- How the system is structured, what is tested, what it depends on, how it is deployed, and whether a new team could work in it without breaking things.
- Data and integrations
- Where the data lives, whether it can be trusted, and what each integration does when the other side is slow, down or wrong.
- Access and ownership
- Whether you actually hold the repository, the hosting accounts, the domains, the credentials and the licences. Often the most urgent finding, and the one to fix first.
- What finishing costs
- Component by component: keep, repair or rebuild, with the effort and the risk of each stated plainly.
- Recovery options
- Usually several — stabilise and finish, cut to a smaller first release, rebuild one part, or stop — each with its cost and trade-offs, and a recommendation with the reasoning shown.
How a rescue runs
It always starts with the assessment. What follows is your decision, and it does not have to involve us.
Where it usually hurts
If one of these sounds familiar, it is the kind of problem we are called in for.
- The vendor has been saying "two more weeks" for six months.
- The developer who built it has left, and the code is the only documentation.
- It works in the demo and fails with real data.
- The budget is spent, the scope is not, and nobody agrees on what was promised.
- You are not certain you own the code, the hosting account or the domain.
- A vendor is leaving, and someone needs to take the keys without losing what works.
Where this experience comes from
Our lead analyst's career history, described by sector — not an Elarion client list. More on the About page.
- Oversight of an offshore team delivering ERP enhancements at a forest products company: specifications, test scripts and acceptance before anything shipped.
- Retiring a legacy system at a transit authority: cutover planning, migration validation, and reconciling the new payroll results against the old system before sign-off.
- A portfolio of platform upgrades across ERP, database, identity, GIS and integration services, each with its integration touchpoints and its cutover and rollback strategy defined up front.
- A CRM platform migration in a regulated public-health organisation, with current- and future-state architecture documented to drive the migration decisions.
Questions buyers ask
- Will you just tell us to rebuild everything?
- No. A rebuild is one option among several and rarely the cheapest. The assessment says, component by component, what can be kept, and the recommendation has to justify itself in cost and risk rather than in taste.
- Do we have to hire you to finish it?
- No. The assessment is a fixed-fee piece of work that stands on its own. Take it to your current vendor, another team or your board. Many clients do ask us to finish, but the report is written to be useful either way.
- Our current vendor is still involved. Is that a problem?
- Not necessarily. Where the relationship is workable, we assess alongside them and the findings are stated as facts, not blame. Where it is ending, the priority is getting you the access, the code and the knowledge before it does.
- What do you need from us?
- Access to the code repository, the hosting environment and whatever documentation exists — contracts, specifications, tickets, emails — and time with the people who know the system best.
- How quickly can it start?
- Rescues are usually urgent and are treated that way. The assessment is scoped on the first call and starts as soon as access to the code and documents is in place.
Further reading
- Fix or rebuild? How to decide what to do with a failing software projectThe question usually arrives late, after the budget has gone and the confidence with it.
- Do you own your software? A source code and access checklistPaying for software and owning it are different things.
- Signs your software project is off track, and the questions to askSoftware projects rarely fail suddenly.
Related services
Project in trouble?
30 minutes, free. Bring the problem, or the change you already have in mind.