# Taking over a codebase you didn't write

*What to preserve before an outgoing product team's access and context disappear.*

**TLDR:** A folder of source files can look like a complete handover while leaving the new team without the history needed to understand or run the product. A workable transition starts before access expires, with an independent copy and written answers from the outgoing team while they still have the context to provide them.

**Authors:** [Vadim Zolotokrylin](/people/vadim-zolotokrylin)

---

We once received a folder that was supposed to contain a complete product,
but part of the code was missing even though it was running in the live system.
Nobody had hidden it; the missing package had simply fallen out of a manual
copy.
We found the gap only because we had already built our own working version
and could compare the two.

That incident changed what we look for when taking over a codebase.
A handover is complete only when the incoming team can run the product,
trace how it reached its current state, identify what is missing,
and take responsibility for what happens next.
Once their access and context disappear,
reconstructing those pieces becomes part of the new team's work.

## What a folder leaves behind

A source folder is a snapshot.
It shows what someone copied at one moment,
but it does not explain who changed the code, when they changed it,
or why the current version looks the way it does.
If another folder arrives later,
the incoming team has two snapshots
and no reliable account of what changed between them.

For that reason, we ask for access to the live repository
while the outgoing team still controls it.
The repository keeps the code and its change history together,
and later updates arrive through the same channel instead of
as another manual copy.
It is not the whole handover, because credentials, infrastructure,
licensed components, and third-party accounts may sit elsewhere,
but it gives the new team a dependable starting point.

## Secure your own copy before their deadline

Repository access often ends with the outgoing team's engagement,
and a copy that remains linked to their repository can disappear with it.
GitHub, for example, deletes a private fork
when the parent repository is deleted or
when the fork owner's access is revoked.
What looked like a backup can therefore remain under someone else's control.

We preserve an independent mirror before the access deadline
and refresh it near the end of the handover.
The first copy removes the risk of losing access without warning;
the final refresh captures the state the outgoing team actually handed over.

## Get your own version running first

Before accepting later changes,
we get the current product running in an environment the company controls
and describe its existing behaviour in plain language.
This is not a replacement for technical documentation.
It is a shared account of what the product does today that the founder,
operations team, and incoming builders can check together.

That baseline turns claims into things the team can test.
A reported bug either reproduces or it does not,
and a feature either exists in the working product or needs further explanation.
When another version arrives,
the incoming team can compare it with something they already understand instead
of reading both versions cold.

It is the same discipline we apply
[before any build starts](/insights/discovery-business-language): establish what
is true now, in language the business can check, before anyone commits to what
happens next.

## Ask what was removed, in writing

Some parts of a working product may be absent from the handover
for legitimate reasons.
Credentials should not arrive inside a source archive,
and a paid component may be licensed to the outgoing team rather than the
company.
The incoming team still needs to know what is absent, why it is absent,
and what must replace it before the product can run independently.

While the outgoing team still has the context to reply,
we ask in writing what remains outstanding on their side
and what they removed from the handover.
The answers turn an undefined concern into a list the incoming team can verify,
replace, or escalate.

## Match responsibility with authority

A codebase handover is also a transfer of responsibility.
The team accountable for the build needs enough authority over normal changes to
stand behind the result.
If someone else can bypass that process and alter the product,
it becomes harder to establish what happened when something breaks.

That operating authority is different from ultimate ownership.
The company should retain administrative ownership and recovery access,
while the permissions to merge, deploy,
and approve routine changes reflect who is responsible for running the product.
[The way the work is structured](/insights/github-strategy) is what makes
that possible.
The founder can follow decisions
and preserve an independent copy without becoming the person who approves every
change.

We settle those roles during the handover,
before an access question becomes an operational dispute.
That is the standard we use to decide whether the transfer actually worked.
A folder may be part of that transfer,
but it cannot establish any of those things on its own.