Can you take over code written by someone else?

Usually yes. Bad code is still readable code. The genuinely hard cases are missing access credentials and undocumented production data — not messy code.

How do I know if it should be rebuilt?

The data model is the deciding factor, not the code quality. Messy code on a sound data model is a cleanup. Clean code on a broken data model is a rebuild. That's what the audit determines.

What if my developer still has access to everything?

Then we lock it down first. Repo access, deployment keys, database credentials, DNS, App Store. This is standard, it's not an accusation, and it should happen the moment a working relationship ends.

Do you do the audit without taking over the project?

Yes. Plenty of people just want to know where they stand.

./my-build-is-broken

You paid for something. It doesn't work.

Maybe the freelancer stopped answering. Maybe the agency delivered on the invoice but not on the product. Maybe it technically runs but crashes on real users, or nobody can add a feature without breaking three others.

This is more common than anyone admits publicly, and it is not a reflection on you. It's what happens when the person paying can't evaluate the work being done.

The first thing you need isn't a developer. It's an honest answer to one question: is this worth saving?

This is you if

Your developer stopped responding and you don't know what you actually own
The app works in demos and falls over with real users
Every new feature breaks something that used to work
You've been told "we need to rebuild from scratch" and you don't know if that's true or convenient
Nobody can tell you where the code is, who has access, or what's in the database

How it works

1. The audit. I go through the codebase, the infrastructure, the database and the deployment. Three to five days. At the end you get a written verdict: what's solid, what's broken, what's dangerous, and what it would cost to fix versus rebuild.
2. The honest recommendation. Sometimes the answer is that 70% is fine and the problem is three specific things. Sometimes the answer is that the data model is unsalvageable and rebuilding is genuinely cheaper. I've said both. I'll say whichever is true, including when it means less work for me.
3. Stabilise first. If we go forward: security holes, data integrity, deployment. Nothing new gets built on a foundation that's still moving.
4. Then forward. Once it's stable, we get back to the roadmap.

What you get

The audit is a standalone deliverable. Even if you never work with me again, you'll know exactly what you own, what it's worth, and what it needs. Founders have used it to renegotiate with the original developer and to justify pulling the plug.

First: get control of your own assets

Before anything else you need control of the repo, the hosting, the domain, the database and the App Store account. If a former developer holds any of these, that's the first thing we fix. I'll walk you through recovering each one.

FAQ

Can you take over code written by someone else?: Usually yes. Bad code is still readable code. The genuinely hard cases are missing access credentials and undocumented production data — not messy code.
How do I know if it should be rebuilt?: The data model is the deciding factor, not the code quality. Messy code on a sound data model is a cleanup. Clean code on a broken data model is a rebuild. That's what the audit determines.
What if my developer still has access to everything?: Then we lock it down first. Repo access, deployment keys, database credentials, DNS, App Store. This is standard, it's not an accusation, and it should happen the moment a working relationship ends.
Do you do the audit without taking over the project?: Yes. Plenty of people just want to know where they stand.