The Developer Is Gone. The App Isn't. Now What?

The call usually comes about two weeks after it stopped being fine. The freelancer who built your dispatch tool stops answering emails, and everyone assumes he's just busy, until three weeks turn into three months. Or the developer who's been quietly maintaining your quoting system for four years hands in notice on a Friday, and nobody thought to ask where the deployment credentials live. Or the agency that built your customer portal shuts down entirely — website gone, phone disconnected, invoice from last quarter unanswered. Whatever the version, you end up in the same spot: the software is still running your business, and the only person who understood it is not available to ask.

Left no documentation. Left no handover notes. Left a repo you may or may not have access to, on infrastructure billed to a card nobody currently controls. The business runs on it anyway, because the alternative is going back to the spreadsheet everyone secretly ran the business on before this thing existed. This piece is for the company in that spot — not the solo founder patching a weekend project, not the office still running a database from thirty years ago. A real business, with a real system, and no one left who built it.

Don't ask for a quote yet. Ask for an audit.

Anyone who gives you a number before reading the code is guessing, and you're paying for the guess either way — just later, and with a change order attached. You cannot price a fix for a system you haven't opened. You cannot promise a timeline for logic nobody has traced yet. The honest first step, when you're trying to take over an abandoned software project, is a paid, scoped audit with a defined output — not a free call that ends in a sales pitch.

That's what our discovery week is for. It's flat rate — $4,800 — and if you decide to continue with us, it's credited back in full. It's not a loss leader disguised as generosity; it's priced like the real work it is, because a code audit before hiring a developer takes real hours from someone senior enough to read the mess correctly. It ends in three things you can hold: a written scope, an architecture sketch, and a fixed estimate. Not a range. Not "depends on what we find" — because by the end of that week, we've found it.

Sometimes the honest answer is: don't patch it, replace it

We turn down projects a specialist would do better, or that an off-the-shelf product already solves for a tenth of the price. That applies here too, and it's the least popular thing we say in a first call, because it's the smaller job for us. But if the codebase fights the business at every turn — if every small change takes a week because nothing is where logic says it should be — patching it is the expensive option, not the cheap one. You're paying to preserve decisions nobody can explain anymore.

Part of why some rescues go badly has nothing to do with the age of the code and everything to do with what it was built on. We choose boring, established technology on purpose, because novelty is a cost paid every year after launch, by the client — and a system built on something clever and unmaintained is exactly how you end up making this same call again in two years. An honest audit tells you which situation you're in: a system worth saving, or one worth replacing on something that will still have documentation and hires available in five years.

Before anyone touches the code, settle who owns it

This has to be a precondition, not a discussion that happens after work starts. You own the code outright from day one. The repos live in your organization, not a contractor's personal account. The infrastructure runs in your cloud account, not the vendor's — which matters enormously in a rescue, because half of these situations start with nobody being sure whose AWS bill it actually is.

We work under NDA by default, and we complete vendor security questionnaires as part of onboarding — not as a favor, as a normal step, the same way it would be for healthcare or fintech clients handling regulated data on a new build. On inherited codebase rescue work specifically, this ordering matters more than usual: you're granting access to a system you may not fully understand yet, to a vendor you haven't worked with before. Get the ownership terms settled before anyone gets a login, not after.

Why a named lead matters more here than on a new build

On a new build, if your lead developer gets pulled onto something else mid-project, it's disruptive but recoverable — there's a spec, there's a plan, someone else can pick it up. On a rescue, there's no original developer left to explain why a decision was made five years ago. If the person who did the audit isn't the person doing the work, you've re-created the exact problem you called about: knowledge that lives in one head and leaves when that head does.

That's why our named lead stays from the scoping call through launch. No handoff to a junior team partway through. On legacy system rescue work, the audit and the fix have to be done by the same person, because half the value of the audit is the judgment calls made while reading the code — and judgment doesn't transfer cleanly in a handoff memo.

How the number gets locked, and stays locked

The architecture sketch, the written scope, and the fixed number all come out of discovery — that's the point of paying for it up front instead of skipping to a quote. Once we're past that, a fixed-scope project runs from $28,000 per phase, billed on milestones: typically 30% at kickoff, the rest on phase acceptance. Every fixed-scope engagement includes 30 days of post-launch fixes, so the number covers the shakeout period too, not just the day the thing ships. Billing terms are Net 14.

The prices we publish are starting points, not the final word — the discovery is what locks the actual number for your specific system. And if something comes up mid-project that wasn't in the original scope — a data migration that turns out messier than expected, an integration nobody mentioned in the first call — that gets priced before the work starts, not billed after the fact as a surprise. The number holds because it was never a guess to begin with.

What happens after the rescue, so there isn't a repeat

A rescue that ends at launch just resets the clock. Software is never finished — ongoing care and improvement is part of the product, not an afterthought bolted on if you ask nicely. That's what Cloud, DevOps & Care is for: starting from $4.5k a month, cancel with 30 days' notice, no long lock-in.

Concretely, that means infrastructure as code sitting in your own cloud account — so if this relationship ends too, you're not stranded the same way. It means uptime monitoring with a named on-call person, not a shared inbox. It means monthly dependency and security patching, so the system doesn't quietly rot the way the last one did. The whole point of this stage is that it's boring — nothing dramatic happens, which is exactly what you were missing the first time around.

Questions to ask before you sign anyone up for this

Bring these to the first call, whoever you're talking to:

Who owns the code and the infrastructure when this ends? If the answer isn't "you, immediately," keep looking.

How do you bill? Vague answers here predict vague invoices later.

What happens if the estimate turns out to be wrong? There should be a mechanism for this, not a shrug.

Do you sign NDAs and security reviews? This should be routine, not a special request.

Do you take equity or offer deferred payment? We don't — it muddies the relationship and has never once made the software better. Cash, milestones, clear scope.

And ask what happens when it's over: a good vendor should offer a full handover with an architecture walkthrough, runbooks, and two weeks of support — the same thing you wish you'd gotten from whoever left you here.

Start with the discovery week, not the pitch

You don't need a pitch right now. You need someone to read the actual code and tell you, honestly, what's in it. That's what the discovery week is built for — flat $4,800, credited back in full if you continue with us. It's the same first step whether you're rescuing something or building from nothing, and for good reason: neither one should start with a guess.