Get a stalled project moving again

Find the failure before choosing the fix

A build may stall because its scope keeps changing, releases are unreliable or a dependency nobody owns blocks the team. Those problems require different repairs. Adding developers before understanding the constraint can make coordination slower without bringing a usable release closer.

We inspect the actual path from a change in the repository to a person using it. That includes credentials, environments, release steps and the data the system depends on. We ask what has stopped working and reproduce the failure with your team.

Protect the useful work

Existing behaviour may matter even when the code is difficult to understand. We identify the journeys people rely on and add checks around them before changing the risky parts. The aim is to restore confidence in a release, not to win an argument about a preferred framework.

A recovery plan names the first repair, who can approve it and how to back it out. Where replacement is necessary, we move a bounded part of the system and keep a way to compare old and new behaviour. Repair or rewrite explains that decision in more detail.

Timing and triage

The first triage depends on access to the system, logs and people who understand the failure. We agree those dependencies at the start, along with any immediate containment work.

Triage produces evidence and priorities. Recovery gets its own stopping point: a journey works, a release can be repeated or an operational fault has been contained and checked.

Make progress visible

You see what we investigated and what changed. We keep a short decision record that distinguishes confirmed causes from remaining questions, so your team can challenge the reasoning without reconstructing a private investigation.

We establish an incident baseline and agree the measurement period before assessing the repair. We do not treat a working demo as evidence that production is healthy.

Leave the system easier to run

A rescue is incomplete if the same failure returns when a particular engineer is away. We leave release and recovery instructions, usable monitoring and named responsibility for follow-up work. Read the stalled-build guide for the practical checks we use before considering a rewrite.