Push harder with the same plan
Choose it when
The plan is sound and the delay was a one-off.
What it costs
Usually more of the same. Stalled projects rarely finish by adding pressure.
Rescue a software project that has stalled.
Real users get working software instead of another demo. We review the code, design, and infrastructure, define the smallest useful release with acceptance criteria, and ship it with tests, a security review, and documentation.
You know this is you when
- The project has been “almost done” for months.
- Each demo shows features, and nothing has shipped to real users.
- The scope has grown and nobody can say what the first release is.
- The team, the agency, or the vendor has changed part way through.
- The business has stopped believing the dates.
Why it is happening now
Projects stall for a few reasons that repeat: no defined first release, a foundation that could not carry the scope, a team that lost its senior people, or a client and a vendor who stopped agreeing on what done means. The way out is the same in every case: find out what actually exists, decide what the smallest useful release is, and ship it.
Illustration of a software rescue plan built by Baybloom: access recovered, backups and monitoring in place, the failing flows fixed, and the stalled build finished in phases.
What we would do first
The first steps, in order.
- 01
Review what exists
The code, the design, the tests, the infrastructure, and the gap between what was promised and what works.
- 02
Define the smallest useful release
One core workflow for real users, with acceptance criteria, written down and agreed on.
- 03
Ship it
Finished to a standard: tests, a security review, documentation, and a release process.
- 04
Plan the rest from evidence
The next release scoped from what users did with the first, not from the original wish list.
What it looks like after
Real users have working software. The business knows what exists, what it cost, and what the next release contains. The original scope becomes a plan with priorities rather than a promise with a date.
Services company
Customers sign in to a working portal that covers accounts, requests, and status.
A stalled customer portal often has plenty of demo screens, contributions from several agencies, and nothing real users can rely on. A review separates what works from what only looks finished, and usually finds a usable core, such as accounts, service requests, and status updates. That core ships to a first group of customers with tests, a security review, and documentation, and everything else moves to a list with priorities. The next release is scoped from what those customers actually do, not from the original wish list.
The path from here
What we would build, and for whom.
The service
Software rescue and codebase takeoverStabilize, finish, or replace software the first team left behind.
ReadWhat we build
Customer portals and service requestsClients report issues, check progress, and download invoices and documents in one place instead of calling your team.
ReadBy industry
Technology-enabled businessesThe internal tools and customer-facing apps your service runs on, built by a senior team before you are ready to hire engineers.
ReadA guide
How to scope the first release of an operational application.Written for the decision, not the sale.
ReadQuestions
Before you decide.
What companies in this situation ask us first.
Can you work with the existing code?
Usually. The review decides. Where the foundation is sound, we finish it; where it is not, we say so before you spend more.
What about the previous vendor?
We work alongside them where they are still involved, and take over where they are not. Access is secured first either way.
How do you stop it stalling again?
A written scope for the first release, with acceptance criteria, a fixed price, and real users as the finish line. New ideas go on the list for the next release.
What if nothing is worth keeping?
Then the review says so, in writing, and the restart is scoped as a first release rather than the whole original wish list.
Describe the project.
Tell us the situation and the systems around it.We’ll come back with what we would do first, and what it would take.