Taking over a web project left by a freelancer: where to start

When a freelancer leaves a project, do not start by improving anything: recover the access, understand what exists, and only then decide. The risk is not that the code is bad. It is not knowing what you actually own.

The analogy: taking over a restaurant

You buy a restaurant. Before changing the menu, you want the keys, to know where the electricity meter is, who the suppliers are, and what is in the fridges. The menu comes later. A web project is the same: you start with an inventory.

Step 1: recover the access

This is the priority, because without it you can do nothing, and sometimes you can no longer prove anything. List everything the project uses:

• The code: the repository (the place where it is stored, for example GitHub) should be under your name or your company's, not on the freelancer's personal account.
• The hosting: the service that runs the site.
• The domain name: the site's address, with its registrar (the organization where it is registered).
• The database: where your users' data lives.
• Third-party services: payments, sending emails, authentication, analytics.
• The admin accounts of the application itself.

For each one, the question is the same: who owns it? If it is the freelancer, ask for a transfer of ownership, not just a password.

Step 2: get a picture of what exists

Without reading the code in detail, you try to answer a few simple questions:

1. How is the application put online, and can you do it again?
2. Is there a backup copy of the data, and do you know how to restore it?
3. Is there any documentation, even a brief one?
4. Are there tests to make sure a change does not break anything?
5. Are the secrets (keys, passwords for services) stored properly? See exposed API key.

None of this is a judgment on the freelancer's work. It is a starting snapshot.

Step 3: have someone outside review it

An independent review says what is solid, what is fragile and what is urgent. It avoids two frequent mistakes: throwing everything away by reflex, or keeping everything out of fear. To decide between the two, see rewrite or repair.

Step 4: secure before adding

Before developing new features:

• change the passwords and keys the freelancer knew;
• remove their access once the handover is finished;
• check that a backup exists;
• check who can access which data.

This is not distrust: it is the same hygiene as when an employee changes roles.

What to avoid

• Rewriting everything right away, without understanding what exists.
• Waiting for an outage to discover you do not have the access.
• Leaving access open to a former contractor by simple oversight.
• Taking over without a handover. If the freelancer is still reachable, an hour with them is often worth a lot of code reading.

Remember

Taking over a project starts with an inventory: the access, the owners, the real state of the code. Decisions come after. What matters first is knowing what you own and being able to run it without the person who built it.

And for your product?

If you inherit a project and do not know where to begin, our project takeover support starts with exactly this inventory, then establishes what should be stabilized first. A 30-minute call lets us see where you stand and what is feasible.