Taking Over a Codebase From a Freelancer: The First Week

In the first week of taking over a freelancer's codebase, change nothing that users can see. Spend day one on a recorded walkthrough and account access, day two on a clean build, day three on proving what production runs, day four on secrets and dependencies, and day five on shipping one tiny change and rolling it back. End the week with a one-page takeover note.

This is the first week only, for a codebase built by one freelancer who is still reachable. It sits between two other guides. Before it, the 25-item software handover checklist covers what to receive before the final payment. After it, the Code Rescue Playbook covers the full method: the 2-week diagnostic, stabilising critical paths and keep-or-replace decisions. If the freelancer has stopped answering, use the 48-hour recovery plan instead.

Why is a freelancer's codebase different to take over?

Because one person held all of the context, and nobody reviewed their decisions. That is not a criticism of freelancers; it is simply what one-person delivery looks like. It changes where the risk sits.

• The knowledge is in one head. Why a table has two date columns, which cron job matters, which customer has a special case: none of it was ever explained to a colleague.
• Accounts drift personal. Services get signed up with whatever email the freelancer had open.
• The deploy may be manual. A single developer can deploy from a laptop for years without it hurting anyone, until they leave.
• Tests are often thin. One person who knows the system can test by memory. You cannot.

The first week is about moving that context out of one head and into the repository, while the freelancer can still answer questions.

What does the first week look like, day by day?

Five working days, each with a clear finish line. Do not move on until the day's "done when" is true.

Day	Goal	Done when
1	Walkthrough and access	A recorded call exists, and your team has owner access to every account
2	A clean build and a local run	A new developer builds and runs the app from a fresh checkout, with notes
3	Production parity	You know which commit production runs, how it got there, and what runs on a schedule
4	Secrets and dependencies	Secrets are inventoried and rotated; history is scanned; dependency advisories are listed
5	A first safe change	One trivial change has gone to production through the pipeline and been rolled back once
End of week	Takeover note	One page: what you have, what is fragile, and what the diagnostic should look at first

Day 1: what should you ask the freelancer on the handover call?

Book two hours, record it with their permission, and let the new developer drive the questions. A recording is worth more than any document, because people explain things out loud that they would never write down.

1. Walk me through one real request, from the browser to the database and back.
2. How do you deploy, step by step, and how do you roll back?
3. What runs on a schedule, and where is it defined?
4. Which external services does the app call, and what breaks if each one is down?
5. Which part of the code are you least happy with, and why?
6. Which bugs do customers report that you never fixed?
7. Is there any work that is not merged, or not pushed?
8. Are there manual steps you do regularly, such as fixing data by hand?
9. Which customers or accounts have special handling in the code?
10. What would you do first if you were staying?

The same day, move account ownership to the company and add your team as owners. Leave the freelancer's access in place for now: you may need them to show you something on day three. Remove it at the end of the week, once your own access has worked everywhere.

Day 2: how do you prove the code builds without the freelancer?

Clone the repository on a machine the freelancer never touched and follow the README exactly. Every step you have to guess, or ask about, goes into a notes file that becomes the new README.

# Fresh checkout, locked install, the same build the host runs
git clone https://github.com/your-org/your-app.git && cd your-app
npm ci
npm run build
npm test

# Where has the work been concentrated? Frequently changed files are
# usually where the bugs and the business rules live.
git log --since="12 months ago" --name-only --pretty=format: \
  | grep -v '^$' | sort | uniq -c | sort -rn | head -20

Use npm ci rather than npm install: it requires the lockfile to match package.json, exits with an error if they disagree, and never rewrites either file (npm ci documentation). That is the install your CI will get, so it is the one to test. If your stack is not Node, use its locked-install equivalent.

The second command lists the 20 files changed most often in the last year. It is a quick map of where the system is alive. On a freelancer's project it usually points straight at the checkout, billing or permissions code, which is exactly where the diagnostic should look first.

Day 3: how do you find out what production is really running?

Compare three things: the commit your host says is deployed, the main branch, and anything configured by hand on servers or dashboards. On one-person projects, they often differ.

• The deployed commit. Your hosting dashboard shows the SHA. Check it exists in your copy of the repository and note how far it is behind or ahead of the main branch.
• Hand-made changes. Environment variables set in a dashboard, a hotfix edited on the server, a database index added from a console. Ask the freelancer to show you on screen.
• Scheduled work. Cron jobs, queue workers and webhooks from payment providers. List each, with where it is defined and what it does.
• Monitoring. Where errors go today, if anywhere, and who receives the alerts. If the answer is the freelancer's inbox, change it today.

By the end of the day, you should be able to draw the system on one page: the app, the database, every external service and every scheduled job.

Day 4: what should you check in secrets and dependencies?

List every secret, rotate the ones the freelancer knew, scan the history for any that were committed, and list dependency advisories without upgrading anything yet.

# Secrets committed anywhere in the history
gitleaks git -v .

# Known advisories in production dependencies (list only, don't fix yet)
npm audit --omit=dev

# How far behind the dependencies are
npm outdated

Gitleaks scans every commit, so it finds keys that were deleted from the current files but remain in history. For anything it finds, follow OWASP's order: revoke the secret, issue a new one, remove it from history and logs, and record who had access (OWASP Secrets Management Cheat Sheet). Rotate from an inventory, not from memory: rotating a key without knowing everywhere it is used is a quick way to take production down.

Resist the urge to upgrade dependencies this week. A list of advisories ranked by severity goes into the takeover note; the upgrades happen once there are tests around the code they touch.

Day 5: why ship a trivial change in the first week?

Because a deploy you have not done yourself is a deploy you cannot rely on. Change something with no user impact, such as a version string in a health endpoint or a comment in a config file, and send it through the whole path: branch, pull request, CI, deploy, check, roll back, deploy again.

If any step needs the freelancer, you have found the most important gap of the week while they can still fill it. Once it works, turn on branch protection so that the main branch only accepts changes whose required status checks have passed (GitHub: about protected branches). From now on, nobody deploys from a laptop.

Then remove the freelancer's access to every account, and rotate anything left over from day four.

What goes in the end-of-week takeover note?

One page that a founder can read in five minutes. It is the brief for the diagnostic that follows, not the diagnostic itself.

• What you have: accounts owned, repository state, how deploys work now.
• What surprised you: hand-made changes, missing pieces, special cases.
• The five riskiest areas, from the hotspot list, the handover call and the advisories.
• Open questions for the freelancer, with a date to ask them by.
• What the diagnostic should cover first. The Code Rescue Playbook describes that next stage.

What should you not do in the first week?

• Do not refactor. Code you do not yet understand is code you cannot safely change.
• Do not upgrade the framework, however old it is. That is a planned piece of work with tests around it.
• Do not promise features on the old timeline. Estimates on an unfamiliar codebase are guesses until the diagnostic is done.
• Do not burn the bridge. Paying the freelancer for a few hours of questions over the next month is cheap insurance.

Why RAITHub for this, and when you don't need us

RAITHub's Code Rescue engagement runs this first week as its opening step, then moves into a 2-week diagnostic: a codebase audit, an infrastructure audit and a risk register, ending in an audit memo and a plan with a fixed scope. It is stack-agnostic, keeps what works by default, and assigns IP in all work to you under a standard NDA. RAITHub publishes no rates; the quote is fixed and written after a free 15-minute technical audit.

You don't need RAITHub if:

• You already have a developer who can follow this plan. It is written so that one person can.
• The product is a prototype with no users or data. Rebuilding may cost less than understanding it.
• You need one bug fixed, not a takeover. Start from the fix one issue page.
• You want a developer placed in your team by the hour. RAITHub works fixed-scope or as a dedicated team, and does not offer staff augmentation.

To hand the takeover to RAITHub, pick Code Rescue on the contact form and book the free 15-minute audit.

Tool documentation checked on 29 September 2026.

Frequently asked questions

What should I do first when taking over code from a freelancer?

Record a handover walkthrough with the freelancer and move ownership of every account to the company on day one. Do not change any code until a new developer can build it from a fresh checkout.

How long does it take to take over a codebase?

The first week gets you access, a working build, a map of the system and one safe deploy. Understanding it well enough to change critical paths takes a diagnostic of about two more weeks.

Should I remove the freelancer's access straight away?

Not on day one. Keep it until your own owner access works on every account and you have deployed once yourself, then remove it and rotate the secrets they knew.

Should I upgrade old dependencies in the first week?

No. List the advisories and rank them, then upgrade once tests cover the code the upgrade touches. An urgent security advisory is the only exception.

What if the freelancer's code has no tests?

That is common on one-person projects. Record what the system does today with a few end-to-end checks of the money and data paths before changing it; the diagnostic that follows decides where deeper tests go.

Should I pay the freelancer for handover time?

Usually yes. A few paid hours for a recorded walkthrough and follow-up questions are far cheaper than rediscovering the same knowledge from the code.