Switching development teams without losing your product.

A handover can lose knowledge that only existed in the old team's heads. The product still needs someone operating it while the incoming team finds its way around. A good takeover gets that knowledge written down and keeps the current product running. Check the release and the access early, and you will find the transition risks while the old team is still available.

Before the switch: what you must own

For each account, confirm the authorized business owner, the recovery route and what the handover requires. Write down provider restrictions and any dependencies before the outgoing team leaves:

• Code repository, with full history and every branch
• Hosting, cloud, database and storage accounts
• Domain registrar and DNS
• App Store Connect and Google Play Console
• Payment, email, analytics and any third party API accounts
• Required configuration names and secret-management references, with approved access to the values

If you are ending the engagement, we cover how to leave safely in should you fire your development agency.

What a good handover package contains

Ask the outgoing team for a written handover, and agree the scope of any paid transition work. Define the deliverables and how the incoming team will check them. The package should cover:

1. How to run the app locally and how it is deployed
2. What is finished, what is half finished, and what was never started
3. Known bugs and the workarounds currently in place
4. Anything scheduled or automated: background jobs, emails, billing runs
5. Which outside services the app depends on and who pays for them

What a non-technical founder should own: code, accounts and keys

You do not need to hold every developer permission yourself. Your business does need a lasting account owner, a recovery route and a record of who can make sensitive changes. A contractor’s personal login should not be the only way to recover the production system. Who controls the accounts and what your agreement says about ownership are separate questions. Check both.

Start an ownership register that lists each service, its purpose, the business owner, the billing owner, the recovery owner and the last time access was verified. Record where secrets are managed by name or reference, and never copy the secret values into the register. Check who owns the backup account as well as the production account.

The handover is complete when a new person can use it

Ask the incoming engineer to start from the written instructions in a clean environment. They should identify the current release, get the approved configuration, run the app, apply the documented data setup and deploy to a test environment. Write down every missing instruction. If someone had to step in with a fix that is not documented, the handover is not complete yet.

Then test a real product journey with synthetic data. Create an account, do the main task and check the operator’s records. That shows whether the business can keep running on the code that was handed over. Include background jobs, billing events and email delivery when the product depends on them. A passing build alone does not tell you those services work.

Plan credential changes around continuity

List the active users, deploy keys, service tokens and integrations before you change any access. Confirm the replacement access and recovery first, then coordinate the changes and check the services that depend on them. An unplanned credential rotation can break a job that nobody remembered to include in the handover. Keep a rollback or recovery plan for the configuration you change.

The first phase with the new team

Plan the phases around the product’s current users, its incidents and what is still uncertain. A practical order to start with is:

First, read and stabilize. The new team gets the app running in its own environment and confirms the important journeys and dependencies. Keep urgent stabilization separate from new feature work, and agree how a change will be reviewed and released.

Then, plan from evidence. You get a written account of what you have and a scoped plan for what comes next, ranked by business value, continuity risk and uncertainty. At this point you decide between finishing, rebuilding weak parts, or changing course.

Then, review working releases. Agree how often you review, the acceptance checks and who is responsible. Look at the deployed result in your own accounts, including the operator’s view and the failure paths you expect. Compare it with the plan and the work still open.

Red flags in the team taking over

• They want to rewrite everything before they have read what exists
• They ask to move the code or hosting into their own accounts
• The work has no review points, spending limits or agreed priorities
• You cannot see progress yourself, only hear about it

A rewrite is sometimes the right call, but it should follow an honest assessment of the code you have. Our Get It Launched process starts with a fixed price Diagnostic for that reason: you see the evidence before you commit to a direction.

Planning a switch?

If you are about to change teams, or the old team has already gone, book a free consultation. We will go through what you hold, what to collect before the handover, a practical next step and the open question it needs to answer. Everything we build lives in your repository and your accounts from the first day.