Software project rescue, for a build that has already missed its dates.
A project that has stopped moving is a hard thing to report on. The date has moved more than once, the updates have stopped saying anything, and nobody in the room can tell you how much of what exists is usable. Until somebody has read the code, every estimate for finishing it is a guess.
We take those projects over. An IT project recovery starts with a recovery assessment, which is us reading what you already have and telling you what is worth keeping. It ends with a fixed price and a date to reach a working product, both signed before the work starts, so you have something specific to take back to the people who approved the project.
How a recovery runs.
Three steps, and the first one stands on its own. You know what we make of the code, in writing, before you commit to anything past the assessment.
A recovery assessment
We read the code you already have and tell you what is worth keeping and what is not. You get a straight answer about the state of it, including the answer where the honest one is that most of it should go.
A fixed price and a date
The assessment ends in a fixed price and a date to reach a working product. Both are agreed and signed before the work starts, so the recovery has an end you can put in front of your own leadership.
We take it over and finish it
We pick the work up and carry it to a product that is in use. The repository and the deployment documentation are yours on final payment. No lock-in.
A recovery runs on the same engagement model as any other build: a written scope, a signed statement of work, and a system you own at the end. The detail is on how we engage.
What the assessment settles.
The assessment exists to replace opinion with something written down. Four questions, and the answers are yours whether or not you go any further with us.
What the code actually does today
We read what has been written and we run it. The gap between what the repository contains and what the project was supposed to deliver is the first thing to establish, because most of the disagreement about a stalled build lives inside that gap.
What is worth keeping
Some of what exists will be sound, some will be a shell with nothing behind it, and some will be work that has to be done again. We separate the three and tell you which is which. Starting over is sometimes the right answer, and we say so plainly when it is.
What finishing it would take
Once the state of the code is settled, finishing becomes a scope rather than an argument. That scope is what turns into the fixed price and the date, and it is written down, so you can read the reasoning behind the number instead of taking it on trust.
What is still an open question
Anything the assessment cannot settle is named as an open question rather than buried inside an estimate. A recovery that starts by hiding the unknowns is the same project you already have, with a new invoice attached to it.
Getting access, and taking it over.
An assessment needs the work itself rather than a description of it. Bring as much of this as you can get hold of.
- Access to the repository, including its history if the history still exists.
- The accounts and credentials the system runs on: hosting, the database, and anything it sends mail or messages through.
- Whatever documentation exists, in whatever state it is in. A ticket backlog and a chat thread both count.
- The scope that was originally agreed, and any written record of what changed after it was signed.
Missing pieces are normal, and they are part of what the assessment establishes. If nobody can find the deployment credentials, or the repository history stops before the last release, that is information about the state of the project rather than a reason to wait. Tell us what you have and we start from there.
You do not have to have ended the arrangement with whoever built it before you talk to us. These conversations often happen while the other contract is still running, and what you need first is a second reading of the code, not a decision. We work from whatever you can get access to, and we will tell you what else is worth asking for while there is still somebody to ask.
What you have at the end of it.
A recovery that leaves you dependent on a second vendor has moved the problem rather than solved it. So the finish line is the same one every other project here has.
The repository, and what it takes to run it
The full repository transfers to you on final payment, together with the deployment documentation. Whether you keep working with us after that is a decision you make on the merits rather than one the code makes for you.
A system on technology you can hire for
Recovered work comes out on the same technology we build everything else on. It is widely used, it is documented everywhere, and the engineers you hire next will already know it, whether that is your own team or somebody else entirely.
Paperwork that says who is responsible
We work under a master service agreement with a statement of work for each project, and we carry general liability and professional liability insurance. Standard terms and a certificate are available on request.
The technology a recovered project comes out on is the same short list everything else we build runs on, and it is published in full on our technology stack page.
Scope and price are fixed and signed before work starts here as on any other project. What we charge for discovery, for a build, and for optional support afterwards is on our pricing page.
If the stalled build is an early-stage product rather than an internal system, the same work written for startup founders is on our page for startups.
Send us the repository.
Book a 30-minute call. Tell us where the project stopped, and we will tell you what a recovery assessment would involve.