14 October 2026 · 4 min read

Taking over a half built crypto exchange

Around one in seven exchange briefs is a rescue, not a build. How to tell whether the code is worth keeping, what the audit looks like, and when starting again is cheaper.

Roughly one in seven real exchange briefs is not a new build. It is somebody who paid a developer, got most of a platform, and needs someone else to finish it. Almost nobody writes about this, which is odd, given how often it happens.

Why it happens

Usually one of four reasons, and knowing which one you are in matters more than the code itself.

• The developer disappeared or stopped answering.
• The money ran out before the hard parts were finished.
• The build turned out to be a front end with a demo backend, discovered when the first real deposit was attempted.
• The developer was fine and the requirement changed underneath them.

The fourth is the easiest to finish. The third is usually a restart wearing a rescue's clothing.

What actually gets audited

Before quoting anything, the questions are the same every time:

• Is there a repository with history? A zip file of final code is a bad sign. History shows how decisions were made and whether anyone reviewed anything.
• Does it run? Not "does it demo". Can it be deployed from scratch onto a clean server using what exists.
• Is the custody layer real? Address derivation, chain watchers, confirmations, reorg handling, a hot and cold split. This is where unfinished builds are most often hollow.
• Where does the money move? Every path that touches a balance, read end to end. This is the slow part and it is not optional.
• What is the database like? Schema, migrations, and whether balances are derived from a ledger or stored as a single number somebody updates.

That last one decides a lot. A ledger can be reconciled. A balance column cannot.

The screens being finished tells you almost nothing. Two builds can look identical and be a week apart or a rewrite apart, and only the money paths reveal which.

Keep it or restart

Keep it when the data model is sound, the custody layer exists and the gap is features. That is a real saving and it is the normal outcome when the money ran out rather than the skills.

Restart when balances are not a ledger, when there is no deposit path that handles reorgs, or when the code has no history and no tests and touches customer funds. In those cases "finishing" means rewriting the dangerous parts while carrying someone else's assumptions, which costs more than starting clean and is less safe.

Being honest about this is uncomfortable and it is the whole value of the audit.

How it gets priced

The audit is small and bounded: read the repository, deploy it, trace the money paths, write down what exists and what does not. The result is a list of what works, what has to be replaced, and what it costs to finish either way, so the decision is yours with the facts in hand rather than ours.

After that it is the same pricing as anything else: fixed, quoted before the work starts, with the source staying in your repository throughout.

What to gather before asking

• Repository access, with history if it exists
• Any deployment notes, environment files with the secrets removed
• A list of what you were told was finished
• What actually happened when you tested it
• Server access, or details of where it is hosted

Removing secrets is not a formality. If a previous developer's keys are still in the repository, they need rotating before anything else happens, and that is true whoever finishes the work. What to ask any developer applies with even more force to a rescue.

Questions

Can you finish an exchange another developer started

Usually yes, after an audit of what exists. The deciding factors are whether balances are a proper ledger, whether the custody layer is real, and whether the code can be deployed from scratch.

How do I know if the existing code is worth keeping

Three tests: does it deploy onto a clean server, are balances derived from a ledger rather than a stored number, and does the deposit path handle a chain reorganisation. Failing the first is inconvenient; failing the other two usually means restarting.

What does an audit of an unfinished exchange involve

Reading the repository, deploying it, tracing every path that touches a balance, and checking the data model and migrations. The output is a written list of what exists, what must be replaced and the cost of each route.

Is it cheaper to finish or to start again

It depends on the data model and the custody layer, not on how finished the screens look. When those two are sound, finishing is much cheaper. When they are not, finishing means rewriting the dangerous parts while inheriting someone else's assumptions.

My developer disappeared with the code, what now

Recover whatever you have access to: hosting, domain registrar, provider accounts, any repository. Rotate every credential you can reach. Then audit what remains before paying anybody to continue.

Will you work with code written by someone else

Yes. Most rescue work is readable enough once it has been deployed and traced, and the parts that are not get named in the audit rather than quietly rewritten.