Switching development teams without losing your product.

A handover can lose context that lived in the old team's heads. The product still needs an operating owner while the incoming team gets oriented. Done well, a takeover makes that knowledge visible and keeps the current product operable. A release and access check will reveal transition risks before the old team is no longer available.

Before the switch: what you must own

Confirm the authorized business owner, recovery route and handover requirements for each account. Record 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 the relationship is ending badly, 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 any paid transition scope. Define the deliverables and how the incoming team will verify 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 personally. Your business does need a durable 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. Keep account control and the written ownership terms in your agreement as separate questions.

Start an ownership register with the service, its purpose, the business owner, billing owner, recovery owner and the last time access was verified. Record where secrets are managed, using names or references rather than copying secret values into the register. Check the backup account owner as well as the production account owner.

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, obtain approved configuration, run the app, apply the documented data setup and deploy to a test environment. Record each missing instruction instead of treating an undocumented intervention as a successful handover.

Then test a real product journey with synthetic data. Creating an account, performing the main task and checking the operator’s records connects the code handover to business continuity. Include background jobs, billing events and email delivery when the product depends on them. A passing build alone does not establish that those services work.

Plan credential changes around continuity

Inventory active users, deploy keys, service tokens and integrations before changing access. Confirm replacement access and recovery first, then coordinate changes and verify dependent services. An unplanned credential rotation can break a job that nobody remembered to include in the handover. Keep a rollback or recovery plan for the affected configuration.

The first phase with the new team

Agree the phases around the product’s current users, incidents and remaining uncertainty. A practical starting sequence is:

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

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

Then, review working releases. Agree the cadence, acceptance checks and responsible people. Review the deployed result in your accounts, including the operator’s view and expected failure paths. 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 come out of an honest assessment, not a reflex. Our Project Rescue process starts with a fixed price Diagnostic for exactly 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 call. We will walk through what you hold, what to collect before the handover, and a practical next step and the uncertainty it needs to resolve. Everything we build lives in your repository and your accounts from the first day.