Is your project in trouble, and what kind
Most projects do not fail loudly. They accumulate small, reasonable-sounding problems until the date stops meaning anything. Tick whatever sounds familiar and you will get an honest read on how far along that path you are.
Nothing ticked yet
Work down the list on the left. Nothing is recorded or sent anywhere. This runs entirely in your browser, and we only hear from you if you decide to get in touch.
A checklist is not a diagnosis. It tells you whether a conversation is worth having; reading the actual code is what tells you what finishing it takes.
Projects rarely go wrong for interesting reasons
Almost every build we are called into went sideways the same ordinary way: the scope moved, someone key left, a deadline that was never real got committed to anyway, and the work that would have caught it kept losing to the work that was visible. None of that requires anyone to have been careless. It is what happens when a team is asked to move fast for long enough.
The reason projects become unrecoverable is not the original problem. It is how long it stays unexamined. Asking someone to look is not an admission of failure. It is the cheapest thing available to you right now.
FAQ
Mostly the ones that stop someone getting in touch at all. If yours is not here, ask it directly. A straight answer costs you nothing.
There's almost no documentation. Is that a problem?
No. It is the norm. Undocumented systems are one of the most common reasons a project stalls in the first place, and reading an unfamiliar codebase is a core part of what an assessment is for. We reconstruct the picture from the code, the infrastructure, the commit history, and conversations with whoever is still around. Producing the documentation that was missing is part of what we hand back.
Will you recommend rewriting everything from scratch?
Rarely, and never as an opening position. A rewrite is the most expensive option and usually the slowest route to a working product, so the assessment tests whether it is genuinely necessary rather than assuming it. Most engagements keep the majority of what exists, stabilize it, and finish the remaining work. When we do recommend replacing a component, you get the reasoning and the cost of both paths.
What if the code really cannot be saved?
Then we say so during the assessment, in writing, with the evidence. That is a more useful outcome than six months of sunk cost, and it is one of the reasons the assessment is scoped and paid for separately. The finding is yours regardless of what you decide to do next, including deciding not to work with us.
We still have an existing vendor or team. Does that complicate things?
It is a normal situation and does not have to be adversarial. We can work alongside an incumbent, take over a defined slice while they continue, or handle a full transition. What matters is that ownership boundaries are written down before work starts, so two teams are not silently changing the same thing.
Who owns the code and the IP?
You do, from the first commit, including anything produced during the assessment. Work happens under a mutual NDA signed before we look at a repository, and access is scoped and time-bound. There is no arrangement in which finishing your project makes you dependent on us to keep running it.
How quickly can you start?
An assessment can usually begin within a couple of weeks of an NDA and repository access. Full delivery engagements depend on current capacity. The banner on the home page reflects which quarters we are actively booking. If a situation is genuinely urgent, say so in your first message and we will tell you honestly whether we can help on that timeline.
What does this cost?
The assessment is a fixed-scope, fixed-fee piece of work, so you know the number before it starts. Delivery engagements are quoted after the assessment, because quoting a completion before anyone has read the code is guesswork, and an estimate given on that basis is the same mistake that stalls most of the projects we are called in to finish.
Will you tell us if we don't need you?
Yes. Some projects need a decision rather than a development team, and some are closer to done than the people inside them believe. If that is what the assessment finds, that is what it will say.
Rather just describe it in your own words?
Tell us where the project stands, whatever its current state, and we will come back with an honest assessment of what finishing it involves.