# Taking Over a Codebase From Another Team: The First 30 Days

> Inheriting code from an agency or a departed team? The access, audits and fixes to do in the first 30 days, in order, before anyone talks about a rewrite.

- Author: Filipe Eduardo, Senior Software Engineer (https://filipeeduardo.dev/)
- Published: October 2, 2026
- Topic: Rescue & modernization · Tags: Code audit, Codebase takeover, Outsourcing, Technical debt
- Canonical URL: https://filipeeduardo.dev/blog/take-over-codebase-first-30-days

## Key takeaways

- In the first week, secure access and make the build reproducible; ship nothing new until you can deploy safely.
- Map the paths that earn money and watch them in production before you judge the code.
- Decide on a rewrite only after 30 days of evidence; most inherited systems need targeted fixes, not a new stack.

Inheriting a codebase usually happens at a bad moment. The agency contract ended, the only engineer left, or the product outgrew the people who built it. The pressure is to show progress quickly, and the reflex is to start either shipping features or planning a rewrite.

Both are mistakes in the first month. Inherited systems are expensive to work in (developers in Stripe’s research reported spending 17.3 hours of a 41.1-hour week on maintenance and bad code, [Developer Coefficient, 2018](https://stripe.com/files/reports/the-developer-coefficient.pdf)), but you cannot tell which problems matter until you understand what the system does and where it breaks.

This is the order I recommend for any takeover: access first, then the build, then the money paths, then the risks. It works whether the previous team is still reachable or long gone.

## Days 1–3: what do you need access to?

Before reading a line of code, find out who controls the system. In takeovers, the most dangerous problems are rarely in the code; they are in accounts that belong to someone who no longer works for you.

List every one of these, who owns it today, and move it into the company’s name:

Asset

What to check

Code repositories

Owner is a company organization, not a person; at least two admins

Cloud accounts (AWS, GCP, Vercel, etc.)

Billing and root access in the company’s name; old users removed

Domains and DNS

Registrar account owned by the company; renewal not tied to a personal card

App store accounts

Apple and Google developer accounts owned by the company

Third-party services

Payment, email, maps, analytics: company accounts, keys rotated

CI/CD and secrets

Where secrets live, who can read them, which ones were shared by chat

Error tracking and logs

Access for the new team; alerts going to someone who still works there

Then rotate every secret the previous team could read. It is not an accusation, just hygiene: you cannot know where copies of the keys ended up.

## Week 1: can you build and deploy it?

Your first technical goal is boring and essential: build the project from a clean machine and deploy a trivial change through the normal process.

Write down every step as you go. Missing environment variables, undocumented services, a script that only works on the previous developer’s laptop: each one you find now would have been an incident later. By the end of the week you should have:

-   A README that takes a new engineer from clone to running app.
-   A deploy that runs through a pipeline, not by hand.
-   A tiny change (a copy fix, a log line) deployed to production and verified.

Do not ship features this week, even if someone is waiting for one. Until you can deploy safely and roll back, every feature is a bet with production.

## Week 2: what does the system actually do?

Now read the system, starting from what matters to the business rather than from the folder structure. Identify the money paths: the flows that, if broken, cost revenue or trust. For most products that means sign-up, login, payment and the core action customers pay for.

For each money path:

1.  Follow it through the code from the screen to the database and back.
2.  List the external services it depends on.
3.  Add monitoring if there is none: error tracking and a simple success-rate metric.

By the end of the week you should be able to draw the system on one page: the main components, the data stores, the integrations and the money paths through them. That page is the most valuable document in the handover, and it often does not exist.

## Weeks 3–4: where is the risk?

With access secured and the money paths visible, look for risk in a fixed order, from most to least urgent:

1.  **Security.** Outdated dependencies with known vulnerabilities, secrets in the repository, missing authorization checks on sensitive endpoints, public storage buckets.
2.  **Data.** Backups that exist and can actually be restored (test one), migrations that are tracked, personal data stored where it should not be.
3.  **Production errors.** The top ten errors by frequency. Inherited systems often have a steady background of failures nobody looks at.
4.  **Tests on the money paths.** If there are none, write a few end-to-end tests for the flows from week 2 before changing them.
5.  **Performance.** Slow queries and pages on the money paths, not everywhere.

Keep a written list, ranked by impact and effort. It becomes the plan for the next quarter, and the evidence for any bigger decision.

## Should you rewrite the code you inherited?

Probably not, and certainly not in the first month. A rewrite throws away every bug fix and edge case the old system learned in production, and it leaves the business without improvements for months.

After 30 days you have the evidence to decide. Rewrite a part of the system when:

-   Changes to it are consistently slow and risky, and you can show it with examples.
-   Its technology blocks something the business needs next.
-   You can replace it gradually, one flow at a time, behind a switch.

If you do go that way, move it journey by journey while the old system keeps running. I wrote about [migrating a live platform to a new stack without downtime](/blog/migrating-a-live-platform-to-a-new-stack), which is exactly that approach.

## What should you ask the previous team?

If the outgoing team is still reachable, one or two hours with them are worth more than a week of reading code. Ask:

-   What breaks most often, and how do you fix it?
-   Which parts of the code are you afraid to touch, and why?
-   What is half-finished: features, migrations, refactors?
-   Which scheduled jobs, scripts or manual tasks keep the system running?
-   What would you do next if you were staying?

Record the answers. The last question is the one people answer most honestly on their way out.

> Inheriting a codebase? Email me at [me@filipeeduardo.dev](mailto:me@filipeeduardo.dev) with what you know about the system and who built it. I can run these 30 days for you, or review your team’s findings.
> 
> Work with me

## Frequently asked questions

### How do I get my code back from a development agency?

Check the contract for intellectual property and delivery clauses, then ask in writing for the repositories to be transferred to your company’s account, along with cloud access, credentials and documentation. Most agencies comply quickly. Hold the final payment until the transfer is done, and rotate every secret afterward.

### Should I rewrite an app I inherited?

Not before you understand it. Spend the first month securing access, making the build reproducible and monitoring the critical flows. Rewrite only the parts that are consistently slow or risky to change, and do it gradually behind a switch, so the business keeps getting improvements while you replace the old code.

### How long does it take to take over a software project?

Expect about 30 days before a new engineer can change the system safely: a week for access and a reproducible deploy, a week to map the critical flows, and two weeks to audit security, data and errors. Small, low-risk fixes can start in the second week.

### What does a code audit cost?

A focused audit of a small or medium product by one senior engineer typically takes one to two weeks of work. Price it as that engineer’s time. The output should be a ranked list of risks with effort estimates, not just a report of everything that could be better.

## Sources

- [Stripe — The Developer Coefficient (2018)](https://stripe.com/files/reports/the-developer-coefficient.pdf)