A Technical Co-founder Left Mid-build: Securing and Continuing the Code

When a technical co-founder leaves mid-build, spend the first week on control, not code. Secure the accounts the product depends on, take a full backup, and confirm in writing that the co-founder's work is assigned to the company. Settle the IP and equity questions with a lawyer. Only then assess the code and decide how to continue. This is general information, not legal advice; confirm with your adviser.

If you would rather have the access secured and the build continued for you, see how RAITHub would help below. This guide is for a founder whose technical co-founder has walked away while the product is half-built, often with the accounts in their name and the only knowledge of the code in their head. It covers the first week, the legal questions, judging what you have, and continuing the product.

What should you do in the first week?

Secure access before anything else, calmly and in writing. A co-founder leaving is usually a relationship ending, not theft, but the product still runs on accounts and knowledge that may walk out with them. Do not revoke their access on day one: if deploys run on their token or the database password lives only on their machine, cutting them off first can take production down with nobody left to bring it back.

• Agree a handover in writing, with a date: admin access to the repository, hosting, database and domain, and a list of every third-party service the product uses.
• Keep a dated record: the founders' agreement, any IP paperwork, and the message history. These are your proof of ownership with every provider.
• Take a full database backup and store it outside the hosting account. A backup you have never restored is a hope, not a backup; restore it once to prove it works.
• Get a complete copy of the code with its history, ideally transferred into an organisation the company owns.

Only once the company holds a role-address login, two admins and two-factor authentication on every account should the co-founder be removed.

Which accounts and knowledge are at risk?

The same accounts any product depends on, plus the undocumented knowledge a co-founder carries that a contractor usually does not. The domain registrar matters most, because whoever controls it can reset the password on almost every other account.

What is at risk	Why it matters	What to secure or capture
Domain registrar and DNS	Controls the website, email and every password-reset link	Make the company the registrant; enable two-factor and the transfer lock
Code repository	The source and its full history	Transfer into a company organisation; confirm it matches production
Hosting and deploy platform	Runs the app and holds production environment variables	Add a company owner; record the commit running in production
Database	Your customers' data, the hardest thing to recreate	Back it up, store it outside the host, and restore it once
Payment and email accounts	Where revenue lands and where resets and receipts are sent	Confirm company ownership and admin; check the payout bank account
API keys and secrets	Features break or keep costing money without them	List every key, where it is set, then rotate the ones the co-founder knew
Undocumented knowledge	How the build works, what is half-finished, what the shortcuts were	A recorded handover walkthrough and written notes while they are still cooperative

The access and recovery steps in detail, including how to recover an account registered in someone else's name, are in developer disappeared with my code; the mechanics are the same whether the person was a co-founder or a contractor.

What legal and equity questions should you take to a lawyer?

Three: who owns the code, what happens to the co-founder's equity, and what the founders' agreement says about leaving. All of this is general information, not legal advice, and it is jurisdiction-specific; take your documents to a lawyer in your own jurisdiction before you act.

• IP ownership. Do not assume the company owns code just because a co-founder wrote it for the company. Whether it does depends on your agreements and your jurisdiction, and the wording matters: a present assignment ("hereby assigns") is generally treated differently from a promise to assign in future ("will assign"). A company that cannot prove it owns all its code will fail technical due diligence later, as covered in the IP assignment checklist.
• Equity and vesting. If the co-founder held equity, what happens to it on departure usually depends on a vesting schedule and leaver terms in your agreements. This is a core question for a lawyer, not something to settle informally.
• The founders' agreement. Does it define handover obligations, confidentiality and what each party keeps? If one was never signed, that is itself something to raise with your adviser now.

How do you assess the code you are left with?

By checking whether it builds, whether it matches what is deployed, and whether anything dangerous is hiding in it. None of this requires reading the code line by line, which matters when the one person who understood it has gone.

Check	How to do it	A bad result looks like
It builds from a clean checkout	Run the host's exact install and build commands on a fresh machine or in CI	It only builds on the co-founder's laptop, or needs undocumented steps
It matches production	Compare the deployed commit with the latest commit you received	Production runs code that is not in the repository
No secrets in the history	Run a secret scanner over the full git history	Live keys committed at any point, which must then be rotated
The database can be rebuilt	Look for migration files and replay them on an empty database	Tables edited by hand that exist nowhere in code
Tests exist and pass	Run the test command and count the results	No tests, so no safe way to continue the build

Security here is application-level: a scan for committed secrets and known-vulnerable dependencies, at the level of the OWASP guidance most reviewers use. It is not a certified penetration test and produces no compliance attestation; if an investor later requires one, use a certified provider.

How do you continue the product?

By capturing what is in the departing co-founder's head first, then stabilising before building new features. A half-built product with no one who understands it is the hardest kind to continue, because you cannot tell finished from half-finished. The order that works:

1. Record a handover walkthrough while the co-founder will still give one: what works, what is half-done, and where the bodies are buried.
2. Add characterisation tests that record what the product currently does, so a new team can change it without breaking it.
3. Stabilise the money paths, then resume the roadmap. Do not pile new features onto code nobody understands.
4. Decide rescue or rewrite from evidence, not from the temptation to start clean. The trade-offs are in rewrite vs refactor legacy code.

Do-it-yourself estimate: securing access and taking a verified backup is 1 to 2 days; a full code assessment and characterisation tests is 1 to 2 weeks for a senior engineer who is new to the code. The main risk of doing it alone is rushing to new features before anyone understands what is already there.

Buy, build or hire?

Option	Choose this when	Watch out for
A new in-house technical hire	The product is central and you can hire and onboard well, with time	Slow to hire; the new hire inherits code with no author to ask
A new freelancer to continue it	The code is in good shape and the scope ahead is small	Single point of failure again; vet and keep ownership in your name
An outside team to secure, assess and continue	No one left understands the code and you need it stable now	Make sure access is secured first and tests are left in your repository

When don't you need outside help?

• The co-founder hands everything over cleanly and the code has tests. A trusted new developer may be all you need.
• It is a legal dispute first. If ownership or equity is contested, see a lawyer before paying anyone to work on the code.
• The product is a prototype with no users. Rebuilding cleanly may cost less than recovering it.
• You want engineers placed in your team by the hour. RAITHub works fixed-scope or as a dedicated monthly team and does not offer staff augmentation.

How RAITHub would help

Scope, agreed in writing before work starts:

• The access inventory above, so the company owns every account before anyone else is removed.
• A 2-week diagnostic: a code assessment against the table above, an infrastructure review, and a risk register.
• Characterisation tests over the current behaviour, and stabilisation of the money paths, before new features.
• Application-level security checks against OWASP guidance; no certified attestation is claimed.

Timeline: access and backup in the first days, then a stabilise-and-continue scope of 2 to 4 weeks in the code rescue range, fixed in writing after the diagnostic.

You receive: automated tests and CI, handover docs and runbooks, and full IP under NDA, so you are never dependent on one person again.

If you are also weighing who should take the technical lead next, read your first technical hire. The code rescue service starts where this plan ends; book the free 15-minute technical audit and bring the access list, the founders' agreement and the three problems costing you most.

Frequently asked questions

My technical co-founder left mid-build. What do I secure first?

The domain registrar first, because whoever controls it can reset passwords on almost every other account, then email, payments, the database and the code. Take a full backup and restore it once to prove it works. Do not remove the co-founder's access until the company holds admin on every account.

Do I own the code my co-founder wrote?

Not automatically. It depends on your founders' agreement, any IP assignment and your jurisdiction. A written present assignment to the company is what removes the doubt. This is general information, not legal advice; confirm with your adviser, because a company that cannot prove it owns its code will struggle in later due diligence.

What happens to the co-founder's equity if they leave?

It usually depends on a vesting schedule and leaver terms in your agreements. This is a core legal and financial question, not one to settle informally; take your founders' agreement to a lawyer before acting.

How do I continue a half-built product no one understands?

Record a handover walkthrough from the departing co-founder while you can, add characterisation tests that capture what the product currently does, stabilise the money paths, then resume the roadmap. Do not build new features on code nobody understands.

Should I rewrite the product with a new team?

Usually not as a first step. Working code encodes rules nobody wrote down, and the data model is the most expensive thing to replace. Run a diagnostic, keep what works, and rewrite only an area whose data model or platform cannot be saved.

How do I stop this happening again?

Keep every account in company hands with two admins, keep the code in a company repository from the first commit, sign a founders' agreement with a present-assignment IP clause and clear leaver terms, and write knowledge down as you go so no single person holds it all.