You're not stuck with a broken app. You're stuck with an unknown one.
The application probably works. That's what makes this confusing — nothing is obviously wrong, and yet nothing can move.
What's actually wrong is that nobody can answer basic questions about it. What happens if this goes down at 2am. Whether this change will break something else. Where the passwords are. Which of these services you're still paying for. Whether customer data is exposed. What it would cost to add the feature someone asked for last week.
Every one of those is unanswerable, so every decision gets deferred. A customer requests something and you say you'll look into it. A contractor quotes and you can't tell whether the number is reasonable. A security questionnaire arrives and you have nothing to put in it.
The product stops moving — not because it's broken, but because changing it feels like a risk nobody can size.
And it compounds quietly. Dependencies age. Certificates expire. A provider deprecates an API. None of it is urgent until all of it is, usually on the same afternoon.
It's worth knowing how you ended up here, because it changes what needs doing.
Eight ways this happens
Situation | What it looks like in practice |
Your developer left | One person built it, held all the context, and is now unreachable or unwilling. Nothing was documented because nothing needed to be while they were there. |
The freelancer disappeared | Work stopped mid-project. You may not have full repository access, deployment credentials, or a clear picture of what was actually finished. |
The agency engagement ended | Delivered and handed over, technically. In practice nobody on your side can read it, and their retainer quote made continuing look impossible. |
You built it yourself with AI | Lovable, Bolt, Cursor, Replit — it got you a real product. Now it needs changes you can't make, and you can't hire for it either, because nobody will touch a codebase they don't understand. |
Your CTO or lead engineer resigned | The team can run it. Nobody can make architectural decisions about it, and the next significant change is stalled. |
You acquired it | The codebase came with the deal. Due diligence covered the business; nobody read the software properly. |
An internal team disbanded | Reorganisation, layoffs, people moving on. The application outlived the team that built it. |
The contractor is still there but unreliable | Responses take days, changes break things, and you're paying for access to knowledge rather than for work. |
If more than one of these applies, the codebase has been orphaned more than once — which usually means two or three competing approaches sitting in the same repository.
The hardest part is usually the part nobody warns you about.
The access problem comes first
Most takeovers start with a partial picture. That's normal, and it's the first thing that has to be sorted.
The usual gaps:
The repository sits in a personal GitHub or GitLab account rather than an organisation
Hosting, domain or DNS registered to someone who's left — Vercel, Netlify, Railway, AWS, Cloudflare
Supabase, Firebase, Stripe or SendGrid accounts under an old email address
API keys in active use with nobody knowing which service they belong to
A deployment that only ever ran from one person's machine
No record of which vendors are being paid, or on whose card
Environment variables that exist in production and nowhere else, so nobody knows what they contain
You don't need to solve any of this before contacting us. Working out what exists and what's missing is part of the audit. Where something genuinely can't be recovered, we'll tell you what it costs to replace rather than leaving it as an open question you can't close.
Before going further — there's a question worth answering honestly.
"Should I just hire a developer instead?"
Often, yes. Here's when that works and when it doesn't.
Hiring works when the codebase is comprehensible, the stack is mainstream, and you have someone technical who can evaluate candidates and onboard them. If all three are true, hire — it's cheaper and you end up with the knowledge in-house.
Hiring struggles when none of those are true. A new developer joining an undocumented, AI-generated codebase with no tests spends their first two months doing exactly what a takeover does — except you're paying a salary while they do it, they're learning alone with nobody to ask, and if they leave in month four you're back here with an extra month of their changes to understand.
The sequence that usually works best is both. Takeover first, then hire. The documentation, architecture notes and working deployment produced by a takeover are precisely what make a hire successful — and they cut onboarding from months to days.
A fair number of clients do exactly this, and we'd rather that than a retainer nobody needs.
What a takeover actually involves.
We establish what nobody currently knows
A takeover isn't a rescue and it isn't a rebuild. It's the transfer of responsibility from someone who isn't there to someone who is.
Area | What we establish |
What it does | Every workflow, screen and business rule, written in language you can read — including the ones nobody remembered were in there. |
How it's built | Architecture, data model, dependencies, integrations, and where the important logic actually lives. |
What's risky | Security gaps, unmaintained packages, single points of failure, and anything that only works because one setting somewhere hasn't changed. |
Where everything lives | Repositories, hosting, domains, databases, third-party accounts, API keys — inventoried and moved into your ownership. |
How it ships | A deployment process someone other than the original author can run, with staging separated from production. |
What it costs to run | Every service you're paying for, what it's for, and what can be cancelled. |
What comes next | A prioritised list: what needs fixing now, what can wait, and what it would take to build the things you've been putting off. |
What we won't do
Recreate the problem we were hired to remove. If the knowledge ends up in one head again, nothing has been solved.
Rewrite it. Rewriting an application nobody fully understands is how you lose the parts that were working.
Hold you to a retainer. A clean handover is a valid ending and we'd rather that than an engagement you don't need.
One thing worth considering before you decide.
What waiting actually costs
There's no emergency here, which is exactly why this gets deferred for months.
But the cost is real and it accumulates in a particular way. Every month the person who built it is further away and less able to help if you do reach them. Every month of unpatched dependencies is more work to bring current. Every feature you didn't ship because nobody could estimate it is a month of the roadmap gone.
And the version of this that does become an emergency — a certificate expiring, a provider deprecating an API, a security question from a customer you can't answer — arrives without notice, and arrives when you have the least time to deal with it.
The cheapest moment to do this is the one where nothing is on fire.
How it runs
01 — Audit. You send whatever you have. An engineer reads the codebase end to end and reports what it does, what's risky and what's missing. Free, 48 hours.
02 — Inventory. Every account, service, key and credential found, listed, and moved into your ownership.
03 — Document. Architecture notes, data model, workflows and a deployment runbook — written for a person, not generated from the code.
04 — Stabilise. The critical risks closed: access control, exposed secrets, unmaintained dependencies, single points of failure.
05 — Establish. Staging separated from production, a repeatable release, and enough test coverage to change things without holding your breath.
06 — Continue or hand over. We keep building, your new hire takes it, or you take it. All three are normal and none is assumed.
What you end up owning
Not a promise — a list you could point at afterwards.
A repository you control, with the history intact
Written documentation of what the application does and how
An architecture note explaining the decisions that matter
A credential and vendor inventory, with nothing registered to someone who's left
A deployment process someone else can run
A prioritised risk list, with the urgent items already closed
A named engineer who knows your system
That last one is the point.
The reason this happened once is that knowledge lived in one head and nowhere else. A takeover that recreates that arrangement hasn't solved anything — which is why the documentation matters more than the code.
Questions
It was built with Lovable, Bolt, Cursor or Replit — can you still take it over? Yes, and that's now the most common version of this. AI-built codebases are readable; they're just undocumented, and usually missing the parts nobody prompted for — error handling, admin screens, the unhappy paths.
I don't have full access to everything. Normal. Working out what exists and what's missing is part of the audit, and we'll tell you what can be recovered and what has to be replaced.
The original developer is still around but unhelpful. We work from the code rather than from them. Slower than cooperation, considerably faster than waiting for it.
Do I have to keep you on afterwards? No. Some people continue, some hire, some take it themselves. A clean handover is a good outcome.
Will you rewrite it? Almost never. Documenting first and then deciding what's worth changing preserves the parts that work, which is usually most of it.
What if it turns out to be worse than I think? You'll hear that in the audit, in writing, before committing to anything — including if the honest answer is that rebuilding is cheaper than continuing.
How long does a takeover take? The audit is 48 hours. Documentation and stabilisation usually run two to six weeks depending on size. Continuing is monthly, if you want it.
Can you work with our existing team? Yes, and it's common. We take the parts nobody has context on and hand them back with the context attached.
Is my code confidential? One senior engineer reads it. Never used for training, access removed after delivery, mutual NDA before you send anything.
Send us what you have
You'll get what the application actually does, what's risky about it, what's missing, and an honest view on whether it's worth continuing, handing to a hire, or replacing.
Read access is enough. Mutual NDA first if you'd prefer.
Also relevant
Migrate off the builder · Codebase audit · Security audit · Refactoring · Production readiness · Stuck at 80%