Most software projects do not fail in one dramatic moment. They drift. A deadline slips, then another. The budget gets "adjusted." Demos get postponed. By the time someone calls for help, the client has lost trust, the team is tired and nobody is quite sure what has actually been built.

Over the years I have been brought in to take over more than a few of these projects, first as a partner growing a software consulting company from about $6M to $60M in under three years, and later as the founder of a fully remote consultancy. The rescues that worked all followed a similar rhythm in the first 30 days. Here is that rhythm.

Days 1 to 3: Stop the Bleeding

The first job is not to fix anything. It is to stop making things worse.

That means pausing new feature work, freezing scope and getting everyone to agree that the next few days are about understanding, not shipping. It feels counterintuitive when a project is already late. But every new feature added to an unstable codebase raises the cost of the eventual repair.

In the same window, I talk to the client directly. Not to promise a new date, but to say three things clearly: we see the problem, we are taking it seriously and we will come back with an honest plan within two weeks.

Days 4 to 10: Audit the Code, the Team and the Promises

A rescue needs facts, and there are three places to get them.

The code. Can it be built and deployed from scratch? Is there test coverage worth trusting? Where are the parts nobody wants to touch? A short technical audit by a senior engineer who was not involved in the original build is worth more than weeks of status meetings.

The team. Who actually knows how the system works? Who is burned out? Who is quietly holding everything together? Often one or two people carry most of the knowledge, and the plan has to protect them.

The promises. What exactly was sold to the client? Pull the contract, the statement of work and the emails. Many rescue projects are not engineering failures at all. They are expectation failures that turned into engineering pressure.

Days 11 to 14: Reset the Scope

With the facts in hand, the honest conversation can happen. I usually bring the client three options: what we can deliver by the original date, what we can deliver with a realistic new date and what it would cost to deliver everything that was promised.

Clients rarely enjoy this meeting. They almost always respect it. What destroys trust is not bad news. It is a second round of optimistic dates that also slip.

The output of this step is a written, smaller scope with a clear definition of done for each item. If it is not written down, it is not agreed.

Days 15 to 25: Ship Something Real

Nothing rebuilds confidence like working software. Once scope is reset, the team should aim to put a small, visible, tested piece in front of the client as quickly as possible.

This is also the time to fix the delivery habits that caused the drift: short iterations, a weekly demo, a single prioritized backlog and one person on each side who owns decisions. These are not glamorous. They are what keeps a rescued project from slipping back.

Days 26 to 30: Rebuild the Relationship

By the end of the first month, the client should be able to see three things: the real state of the project, a plan they agreed to and at least one delivery that matched what was promised.

That is the point to step back and talk about the relationship itself. What does the client need to feel informed? How often do they want updates? What would make them comfortable recommending the team again? A rescue is only finished when trust is back, not just when the code works.

What Most Rescues Get Wrong

The most common mistake is moving too fast in the wrong direction. A new team arrives, decides the old code is terrible and starts a rewrite in week one. Sometimes a rewrite is right. It should be a decision made from the audit, not a reflex.

The second mistake is hiding the truth from the client to buy time. It never buys enough. The projects I have seen recover were the ones where the client heard the bad news early, from us, with a plan attached.

The Short Version

Freeze scope. Get the facts. Tell the truth. Shrink the plan. Ship something real. Then rebuild trust on purpose. None of it is complicated. All of it is easy to skip when everyone is under pressure, and that is exactly when it matters most.

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

If you have a software project that is drifting and want an experienced team to take a hard look, visit https://tdzpro.com.

Ashkan Rajaee is the founder of TDZ Pro. As a partner, he helped grow a software consulting company from about $6M to $60M in under three years, and he founded and scaled a fully remote software consultancy.