Technical Co-Founder Left: Who Owns the Code in 2026
The ownership question answered first, then a dated fourteen day recovery sequence and the three routes forward with costs and timelines.
Sep 27, 2026
Technical Co-Founder Left: Who Owns the Code in 2026
Short answer: the code belongs to the company only if there is a signed agreement assigning it, usually an IP assignment inside the founders' agreement or the incorporation paperwork. Without one, the person who wrote it generally keeps the copyright in what they wrote, and you are using it by permission you never got in writing. That is the first thing to check, before passwords, before the repository, before deciding whether to rebuild. Everything else in the first two weeks is recoverable. An ownership gap is the only part that gets harder with time.
This page covers the legal question first, then the operational sequence for the first fourteen days, then what it costs to put the product back under someone's ownership and how long that takes.
Facts on this page were verified on 25 September 2026.
This is not legal advice and it is not a substitute for a lawyer in your own jurisdiction. It is the starting point most founders skip.
Why an assignment matters more than you expect
Founders often assume that paying someone means owning what they produced. In the United States that is not how it works by default. The U.S. Copyright Office's Circular 30 sets out that a commissioned work counts as a "work made for hire" only if it satisfies all four of its requirements, one of which is that the work falls within one of nine enumerated categories: a contribution to a collective work, part of a motion picture or other audiovisual work, a translation, a supplementary work, a compilation, an instructional text, a test, answer material for a test, or an atlas. The circular states plainly that "if a work fails to satisfy any of these requirements, it is not a work made for hire" (copyright.gov, Circular 30, revised 08/2024, checked 25 September 2026).
Software is not on that list of nine. So for anyone who was not an employee writing within the scope of their employment, the work-made-for-hire route is generally unavailable for code, and ownership has to come from a written assignment instead. A co-founder who took shares rather than a salary, or who was paid as a contractor, is exactly the person this applies to. Other countries handle it differently, which is why the jurisdiction matters, but the practical instruction is the same everywhere: find the signed assignment, or get one.
First: find out whether you own it
Three documents decide this, and you can check all three in an hour.
The founders' agreement or shareholders' agreement. Look for an intellectual property assignment clause. It will say that work produced for the company belongs to the company. If it is there and signed, the code is company property and the rest of this page is an operations problem rather than a legal one.
The incorporation paperwork. In many standard incorporation packages the founders sign an IP assignment at the same time as the share issue. Check the bundle you signed at formation, not just the documents you remember signing.
Any contractor or consultancy agreement. If your co-founder was paid as a contractor at any point, that contract may contain the assignment even when the founders' agreement does not. Conversely, if third-party contractors wrote parts of the product and were never assigned, those parts are a separate gap.
If you find nothing, you have a negotiation rather than a dispute, and it is much cheaper to settle it now, while the relationship is merely over rather than hostile. What you want is a short written assignment of everything already written, signed in exchange for whatever was already agreed: vested shares, a final payment, a reference. A UK-law explanation of how this plays out when founders resign is set out well by The Jonathan Lea Network, and the equivalent question in your own jurisdiction is worth an hour of a lawyer's time before you spend anything on engineering.
One related point, because it decides who still holds equity while you negotiate: if there was a vesting schedule with a one year cliff and they left before it, unvested shares return to the company. If there was no vesting, you are negotiating a buyout as well as an assignment. The technical co-founder equity guide covers how those schedules are normally structured.
The first fourteen days, in order
| Days | Do this | Why it is in this position | What failure looks like |
|---|---|---|---|
| 1 | Inventory every account: code hosting, cloud provider, domain registrar, DNS, payment processor, app store accounts, error tracking, analytics, email sending | Access is the only thing that can be revoked by someone else while you are thinking | Discovering the domain renews on a personal card three weeks later |
| 1 to 2 | Transfer ownership of each account to a company email address you control, and add a second company admin | A single admin is the same problem you just had | Ownership transfer requests that need the departed person's approval after they stop replying |
| 2 to 3 | Check the IP assignment documents above | Every later decision depends on the answer | Paying to extend a codebase you do not own |
| 3 to 5 | Take a full backup outside the original accounts: repository with history, database dump, environment variables, any file storage | History matters. A repository without its commit history is much harder to hand to anyone | A snapshot of the current files with no history and no database |
| 5 to 8 | Get a written technical assessment from someone senior who is not bidding to rebuild it | You cannot make the rebuild decision without knowing what you have | Accepting a rebuild quote from the first person who reads the code |
| 8 to 10 | Establish what is running in production right now and what it costs monthly | Products keep serving customers and keep charging you while this happens | A cloud bill nobody can explain and nobody can reduce |
| 10 to 14 | Choose the route below and start it | Two weeks of drift is recoverable, two months is not | Customers noticing before you have decided anything |
Do not announce anything to customers until days one to three are done. You are not hiding a problem, you are avoiding announcing one you cannot yet answer questions about.
What you actually have, and what it is worth keeping
The honest assessment is usually somewhere between the two stories you will be told. The person who left will say it is fine. Anyone quoting for a rebuild has an interest in saying it is not. A senior assessment should answer five specific questions, and you should ask for them in writing:
- Can it be deployed from scratch by someone new, using only what is in the repository and the documented environment? If not, you have a product that exists only on one machine's memory of how to run it.
- Are there tests, and do they pass? Not how many. Whether the important paths are covered.
- Where is customer data, who can read it, and is anything stored that should not be?
- What is the dependency situation, and is anything on a version that no longer receives security updates?
- What would the first month of work be for a new team, and is that work removing risk or adding features?
Question one is the one that decides the route. A codebase that a new engineer can stand up on a fresh machine on day one is usually worth continuing, whatever its other flaws. One that cannot be deployed without the person who left is closer to a prototype than a product, whatever it looks like from the outside. That distinction is the same one we cover in the production readiness review for vibe-coded and AI-built apps, and it applies equally to code written entirely by hand.
The three routes, with what they cost and how long they take
| Route | When it fits | Time to a working team | Cash cost | What you get at the end |
|---|---|---|---|---|
| Continue with the existing codebase, new team takes it over | The product deploys from scratch, has paying users, and the assessment found no data or licensing problem | Two to four weeks of takeover before normal delivery resumes | Ongoing engineering, $5K to $10K per month | The same product, now maintainable by more than one person |
| Rebuild the core, keep the product and the data | The product works for users but cannot be deployed or safely extended by anyone new | Two to three months to launch | $15K to $50K for a Starter Build scope, $50K to $100K for a larger one | A production version you own outright, with the users and data carried across |
| Hire a replacement technical co-founder | The code is the invention, and you want an owner rather than a supplier for the next several years | Typically months, and the search itself is the risk | Equity, plus the months in which nothing ships | A partner, if the search works |
The third route is legitimate and it is the one most founders reach for first. It is worth being clear-eyed that you are adding a months-long search to a product that is currently unowned, which is why many founders run it in parallel with one of the first two rather than instead of them. The full comparison is in the technical co-founder alternative.
For a range against your own scope rather than these bands in the abstract, the AI development cost calculator takes about a minute.
Preventing the second occurrence
Whatever route you take, four things should be true by the end of it, and none of them are expensive when you do them deliberately rather than in a crisis.
- Every account is owned by a company email address, with at least two admins.
- An IP assignment is signed by everyone who has written code for the company, including contractors.
- The product deploys from a clean machine using documented steps, and someone other than the author has done it at least once.
- Vesting schedules exist for every founder, with a cliff.
The handover discipline behind those four is the same one in the agency to in-house engineering handover checklist, which is worth reading before you engage anyone new, not after.
Getting the product back under control
KUMO's founders built the first production version of Volopay as its founding engineers, and Volopay went on through Y Combinator and raised institutional funding. Taking ownership of a product that already has users, and being accountable for it afterwards, is the same job. KUMO also runs CampaignHQ, its own product, in production since 2022, and holds a 4.9 rating on Clutch. The Volopay case study has the detail.
If the codebase is staying and needs a team that can own it, that is taking a vibe-coded or inherited product to production. If it was built on no-code tooling and has outgrown it, that is no-code to custom. Either way the engagement is a fixed scope against the published bands, senior engineers, milestone delivery, and you own the code from day one.
To get the assessment and a scope with a band against it, book a free consultation call. Bring the repository access and whatever paperwork you found.
FAQ
My technical co-founder left. Do I own the code? Only if there is a signed assignment, normally an IP assignment clause in the founders' agreement, the incorporation bundle or a contractor agreement. Without one the author generally retains copyright in what they wrote, and you need a written assignment from them.
What if they will not hand over access? Deal with the accounts you can still control first, then make a single written request listing exactly what you need, then take legal advice. Most of these end in a negotiated assignment rather than a dispute, and the settlement is usually cheaper than one month of rebuild.
What happens to their shares when they leave? If there was a vesting schedule with a cliff and they left before it, unvested shares return to the company. Without vesting you are negotiating a buyout. This is separate from the code question and both need settling.
Should I rebuild or keep going with what they wrote? Ask one question first: can a new engineer deploy it from scratch on a fresh machine using only what is in the repository? If yes, keep going and take it over. If no, price both routes properly before deciding, because a product that only runs on one person's setup is closer to a prototype than to a product.
How much does it cost to take over a codebase after a co-founder leaves? Ongoing engineering on an existing codebase runs $5K to $10K per month. A rebuild of the core against a fixed scope is $15K to $50K for a Starter Build and $50K to $100K for a larger one. The assessment that tells you which one you need should come before either number.
How long before we can ship features again? Two to four weeks if the existing codebase is being taken over and the assessment was clean. Two to three months to launch if the core is being rebuilt. The clock starts at the assessment, not at the departure.
