Eighteen months in.
Breaking at go-live.

A long development effort reached a difficult final stretch.

An AI SaaS product had been in development for eighteen months when things began breaking as go-live approached. The project was reaching the point where the development effort needed to become a launched product, but the failures were preventing that transition.

The immediate requirement was to recover the existing project and resolve the issues standing in the way of release.

The work was a recovery to launch.

Conso4s took on the rescue and fixed the problems preventing the product from going live. The engagement brought a troubled late-stage build through to launch in ten weeks.

The eighteen months and ten weeks describe different parts of the project’s history: the development period before the rescue situation, and the subsequent recovery period. They should not be read as equivalent scopes of work.

Why the timing of the failure matters

Problems emerging near go-live need to be understood in the context of the release. A recovery decision has to establish which failures prevent launch, which dependencies they touch and what the working outcome should be.

That is the starting point we recommend for another stalled SaaS project. The elapsed development time alone is not enough to decide what the repair should involve.

Start with the failure you can describe.

If your own product is breaking as launch approaches, bring examples of the expected behaviour and what happens instead. A first conversation can help establish the kind of investigation needed, before committing to a recovery scope.