Projects Rarely Crash. They Drift. Here Is How I Spend the First Month Pulling One Back

Note: This story was written with AI assistance and edited by me.

Note: An earlier version of this piece, "The First 30 Days of a Rescue Project: How to Save a Software Build That Is Going Off the Rails," was published on DEV.

Ask anyone who has worked on a failing software project when it went wrong, and you will rarely get a single date. There is no crash. There is a slow slide: one missed milestone, a quiet budget change, a demo moved to next week and then the week after. When help finally arrives, the client is frustrated, the team is exhausted and nobody can say with confidence what actually works.

I have stepped into a number of these situations, first as a partner at a software consulting company that grew from about $6M to $60M in under three years, and later running a fully remote consultancy of my own. The recoveries that succeeded had a lot in common, especially in the first month.

The First Few Days: Do No More Harm

My first move is never a fix. It is a pause.

New features stop. Scope is frozen. Everyone agrees that the next several days are for learning, not shipping. That can feel strange on a project that is already behind, yet piling new work onto an unstable system only makes the eventual repair more expensive.

I also speak with the client right away. I do not offer a new deadline. I tell them we understand the situation, we are treating it seriously and they will get a straight plan within two weeks.

The First Week and a Half: Collect the Facts

Recovery depends on knowing what is true, and the truth usually lives in three places.

The first is the code itself. Can it be built and deployed cleanly? Are the tests trustworthy? Which areas does everyone avoid? A brief review by an experienced engineer who had no part in the original work tells you more than a month of status calls.

The second is the people. Who really understands the system? Who is close to burning out? Who is quietly keeping things running? Knowledge tends to sit with one or two individuals, and any plan has to protect them.

The third is what was promised. Read the contract, the scope document and the email trail. A surprising number of troubled projects are not technical failures. They are mismatched expectations that turned into pressure on the engineers.

Around Day Two Weeks: Have the Hard Conversation

Once the facts are clear, it is time to be honest with the client. I usually lay out three paths: what can be delivered by the original date, what can be delivered on a realistic new date and what it would take to deliver everything originally promised.

Nobody enjoys that meeting. Almost everybody respects it. Trust is rarely broken by bad news. It is broken by a second set of hopeful dates that also slip.

The result should be a smaller, written scope with a clear definition of done for each piece. An agreement that only exists in someone's memory is not an agreement.

The Third Week: Put Working Software on the Table

Confidence comes back fastest when people can see something that works. After the reset, the goal is to show the client a small, tested, visible piece of progress as soon as possible.

This is also when the habits that caused the drift get fixed. Short cycles, a weekly demo, one ranked list of work and a single decision owner on each side. None of this is exciting. All of it keeps a recovered project from sliding again.

The Last Few Days of the Month: Repair the Relationship

By day 30, the client should understand where things really stand, have a plan they agreed to and have seen at least one delivery that matched the promise.

That is the moment to talk about the working relationship itself. How do they want to be kept informed? How often? What would it take for them to recommend this team to someone else? A rescue is not done when the code runs. It is done when the trust is back.

Where Rescues Usually Go Wrong

The most frequent error is speed in the wrong direction. A fresh team shows up, declares the old code a disaster and starts rewriting in the first week. Sometimes a rewrite is the right call, but it should come out of the review, not out of instinct.

The other common error is shielding the client from the truth to buy time. It never buys enough. Every project I have seen recover was one where the client heard the hard news early, directly and alongside a plan.

In Short

Pause the scope. Learn the facts. Be honest. Shrink the plan. Deliver something real. Then rebuild trust deliberately. It is not complicated, but it is exactly the kind of discipline that disappears under pressure, which is when it matters most.

I took a firm from $6M to $60M in under three years.

If you are watching a project drift right now, start with the pause. Everything else gets easier once the bleeding stops.