The developer left, the vendor folded, or the contractor stopped returning calls. What's left is a system the business runs on, with no documentation, no tests, and no safe way to change it. That system can still be brought back under control — but reading it comes before quoting it. The first deliverable is a written map of what you actually have.
Every one of these is recoverable. The order you tackle them in is the part that matters.
No handover, no documentation, and a system the business runs on. Everyone has quietly agreed not to touch it in case it stops working.
The code is there, but nothing anyone does produces a running copy. The only working version is the one already deployed, and nobody knows how it got there.
One box, one disk, and a backup nobody has ever restored from. The recovery plan is a phone call to somebody who left the company.
A one-line fix might break something unrelated, and there are no tests to say which. So the backlog grows and nothing ships.
An unsupported language version, a framework whose last release predates your newest hire, and security patches that stopped arriving years ago.
The shop folded, the contractor went quiet, or the price of a small change became absurd. You own the system on paper and cannot change it in practice.
Four stages, in order — each one is only safe because the one before it happened.
The first deliverable is a written map of your system, not a line of code.
Characterization tests that pin down behaviour nobody can explain any more.
End-of-life runtimes, known-CVE packages, expired certificates, secrets in the repo.
A named person who answers, an agreed response time, and a second pair of eyes.
If the platform underneath it is genuinely dead — unsupported, unlicensable, or welded to hardware you can't replace — then the honest recommendation is a phased migration, and the documentation and tests we build become the specification it runs on. If the complaint is really about the process the software encodes rather than the software itself, point Lean Six Sigma at it before anyone changes a line.
Either way, the first deliverable is unchanged: a written map — what the system does, what it touches, what will break first, and what it would cost to fix each part. That document is yours whether the next step is us, your own team, or nobody at all for another two years. An assessment that ends right there is a legitimate result, not a failed sale.
Handing over a codebase is a real thing to ask. Scoped access, an NDA when you want one, and terms written down before we read a line.
We won't quote a fix for a system we haven't read. The assessment comes first, and it's short, fixed-price, and yours to keep.
Support runs as a retainer you can end, with documentation and access handed back on the way out. Further development works on the same terms.
When the verdict is replace rather than repair, that becomes a migration with a parallel run — not a weekend and a prayer.
Yes — that is the job. We start from what is actually running: the server, the database, the scheduled jobs, and the people who use it every day. Missing source makes it a harder start, not an impossible one; a running system tells you most of what it does. The first deliverable is a written map of what you have, and you keep that whether or not you hire us for anything after it.
Sometimes, and we will say so plainly. But rewriting a system nobody understands is how companies end up running two broken systems instead of one — the rewrite always misses the rules nobody wrote down. Documenting and testing first is cheaper, and it produces the specification the rewrite needed anyway. If replacement really is the answer, it becomes a phased migration with a parallel run, not a big-bang weekend.
Characterization tests. Rather than asserting what the code should do, we record what it does today — outputs, files, reports, resulting database state — and lock that in. Existing bugs get pinned along with everything else, deliberately, because the point is to detect change rather than to judge correctness. Once that net exists, an upgrade stops being a gamble and becomes a diff you can check.
Under an NDA whenever you want one, with access scoped to the people doing the work and revoked at the end. We work inside your repositories and your accounts wherever that is possible, take the least data that does the job, and test against masked or reduced copies when production data isn't necessary. Our confidentiality page states the whole arrangement in plain terms.
Not on day one, and the reason is worth stating plainly. Promising a response time on a system we have never read is a promise we cannot keep honestly — at 3am we would be reading the code for the first time, on your outage. A short assessment gets us to the point where a response commitment means something. After that, a retainer is the normal arrangement.
The assessment is fixed-price and short, because it is the only part anyone can scope before reading the code. What it produces is a prioritized list with estimates: what is urgent, what is merely ugly, and what you can safely leave alone for years. You can stop there and hand that document to your own team — it is written to be used that way.
Point us at it. What comes back is a written assessment: what it does, what state it's genuinely in, and what making it safe to change would involve.
