Project rescue
Someone else started it. Then it stopped.
A project that has gone quiet has rarely failed, and it is even more rarely worth throwing away. What it needs first is an independent answer to the one question your current supplier cannot answer neutrally: how much of this is finished?
You might recognise
There are demos, but nothing anybody uses.
The date has moved three times, each time by a month.
Nobody can tell you what is left to do in terms you understand.
You are paying monthly for progress you cannot see.
What that involves
- An independent read of the code, the tests and what works
- A written statement of what is worth keeping and what is not
- Taking the build over, or handing you the evidence to have the conversation yourself
- Getting a real release out early, so the project stops being theoretical
The same three stages
How it runs, for this kind of work.
01
Discovery
A review first, and a short one. We read what exists and report on it in plain English: completed, half-built, or a screen with nothing behind it. You own that report whether or not you go on to use us.
02
Implementation
Whatever is sound gets kept. The first goal is one working release in front of real users. That is what makes a stalled project feel alive again.
03
Full testing
Inherited code with no tests is the reason no one dares change it. Tests come first here, because everything else depends on them.
What you end up holding
- An independent written assessment of the existing work
- A fixed price and date for finishing it
- A release, early, that people can actually use
- Tests around the code you inherited
Sounds like the situation?
Describe it in your own words — the system, what stopped, or what you wish it did instead. You will get an honest read on whether we can help and what a discovery would cover.