Service
Project rescue for software that stalled, slipped or got abandoned
Get an honest read on what you have, a clear salvage-or-rewrite recommendation and a stabilization sprint that gets you to a launch you can defend.
A failing project rarely looks like a failure at first. It looks like a missed milestone, a demo that was postponed, a developer who is suddenly hard to reach. By the time you are thinking about a rescue, you probably have partly built code, a budget that is already spent and a lot of stakeholders asking for a date.
We start with a fixed-price review rather than a promise. In a short, bounded engagement we read the repositories, run the build, check the deployment path, look at how secrets and data are handled and compare what exists with what was promised. You receive a written memo with the real state of “done”, the risks, and a recommendation: salvage, partial rewrite or start fresh.
If salvage makes sense, we run a stabilization sprint aimed at the blockers that stop launch, with demos every week so you can see recovery rather than take our word for it. If the honest answer is that the foundation cannot ship, we will say so and give you the memo to take wherever you like.
The problems
What usually goes wrong
A build with no working demo
Weeks of updates, yet nothing you can open and click. You cannot tell whether the project is nearly there or nowhere close.
Code nobody can explain
No documentation, no tests, and the original authors are gone or defensive. Every estimate to continue is padded with fear.
Blocked at the last mile
Features exist but deployment, authentication, data migration or payments are broken. The launch date keeps slipping on infrastructure, not design.
No independent opinion
The vendor says it needs another three months, and you have no way to verify it. Another sales pitch will not fix the information gap.
What you get
Deliverables
Audit memo
Architecture, code quality, test coverage, security hygiene and deployment readiness, written for both engineers and executives.
Salvage versus rewrite recommendation
A reasoned call with trade-offs and cost ranges. We prefer salvage when the foundation can carry the product, and say so when it cannot.
Prioritized stabilization backlog
The defects and gaps that block launch, ordered by what unblocks you fastest, with the rest parked deliberately.
Revised launch plan
A realistic plan with milestones and dependencies, built from what we found rather than what was previously promised.
Access and knowledge transfer
A map of repositories, hosting accounts, domains, third-party services and credentials, moved under your control.
Runbooks and handover notes
How to build, deploy, roll back and debug the system, so your next team does not start from zero.
How it works
Step by step
01
Triage call
You describe what was promised, what exists and where trust broke down. We confirm whether a review is worth doing and what access we need.
02
Fixed-price review
We audit the code, environments and process within a bounded timeframe, so the cost of finding out is known before it starts.
03
Findings and decision
We walk you through the memo and the recommendation. You can stop there with a document you own, or continue with us.
04
Stabilization sprint
We fix the launch blockers first: authentication, data integrity, deployment, critical defects. Demos show progress each week.
05
Launch, transition or continue
We take the remaining milestones through launch, hand the project to your next team with full documentation, or continue on a retainer.
06
Prevent the next rescue
We put basic guardrails in place so the project does not slip again: a written scope, weekly demos, a deployment pipeline and ownership of every account, whoever builds the remainder.
Timeline
How long it typically takes
A review is often completed in about one to two weeks once we have repository and environment access, depending on the size of the codebase. Stabilization sprints commonly run two to six weeks, and complete rewrites, if they are warranted, are scoped separately with their own timeline. Access delays from the previous vendor are the most common source of slippage.
Who it's for
- Founders mid-build who no longer trust the delivery status they are getting
- Teams that inherited a codebase with no documentation or original authors
- Buyers who want an independent second opinion before spending on a rewrite
Who it's not for
- Projects where the real problem is an undefined product, not broken delivery
- Teams hoping for a guaranteed save of a codebase before anyone has looked at it
- Situations that need legal dispute support with a former vendor, which is outside our scope
Keep exploring
Related pages
FAQ
Frequently asked questions
Will you recommend a rewrite to get more work?
We would rather not. The review is fixed price, so we have no incentive to inflate findings. We recommend salvage whenever the foundation can ship and a rewrite only when it clearly cannot.
What if the previous vendor will not hand over access?
We start with what you legally own and help you reclaim repositories, domains and cloud accounts. If critical access is blocked, we report that as a risk rather than guess around it.
Do you need to work with our existing stack?
Usually yes. If a stack is outside what we can support well, we tell you during the review instead of learning on your budget.
Can the review be used with another team?
Yes. The memo and backlog are yours. Plenty of buyers use them to brief a new vendor or their own engineers.
How do you keep a rescue from becoming open-ended?
Stabilization is scoped as a sprint with a defined list of blockers and weekly demos. Anything beyond that list is a separate decision you make with the facts in front of you.
How much does a rescue cost?
The review is a fixed price confirmed before it starts. Stabilization is scoped as a sprint after the findings, and a full rebuild, if needed, is priced separately. We will not quote a rescue before we have seen the code.
Next step
Tell us what you want to build
A short call, then a written scope in plain language before any build starts.
- Fixed scope
- Weekly demos
- You own the code