When a build stalls, replacing the team can feel like the only move left. Sometimes it is. But I have seen founders switch teams and end up repeating the same problems with new people, because nobody stopped to work out what had actually gone wrong.
Before you move, it is worth a few days of checking. Here is what I look at when a founder asks us to take over a product.
1. Find out what you actually own
Start with access, not code. Make a list of everything your product depends on and check who controls it:
- The code repository, and whether you are an owner or only a guest.
- The servers or cloud accounts it runs on.
- The domain, email sending, payment provider and app store accounts.
- Any third-party services with API keys in someone else's name.
If the current team controls any of these, sort it out while the relationship is still civil. Getting access back after things turn sour is far harder, and a new team cannot do much without it.
2. Work out what went wrong, honestly
Missed deadlines and poor updates are symptoms. Ask what was underneath them:
- Was the scope clear, or did it keep moving?
- Did anyone own the whole project, or did questions pass from person to person?
- Were problems raised early, or did they surface as surprises?
- Were decisions written down, or did they live in calls and chats?
Some of the answers may point back at the way the project was run, not only at the team. That is worth knowing, because a new team will run into the same walls if nothing else changes.
3. Get an independent look at the code
Before you decide anything, have someone outside the current team review what exists. You are not after a list of everything that could be better. You want plain answers to three questions:
- Is this worth keeping, partly keeping or replacing?
- What are the biggest risks in it right now?
- How much is undocumented, and how hard will it be for someone new to pick up?
On one connected health product we joined, the firmware had come from an earlier team, and the launch date could not move. Treating that inherited code as the biggest risk, and dealing with it first, is what let the launch hold.
4. Decide what has to keep working during the switch
If the product is live, the handover itself is a risk. List what cannot break while teams change: payments, logins, anything customers rely on daily. A good incoming team will plan around those first, before writing anything new.
5. Be careful with "we'll rebuild it properly"
A full rewrite is sometimes right. More often, it is the most expensive way to learn the same lessons again. Ask any new team what they would keep, what they would fix and what they would replace, and why. If the answer to everything is "replace it", ask harder questions.
6. Check the new team for the thing that failed last time
If the last team failed on ownership and communication, do not only check the new team's technical skills. Ask who will be accountable for your project, how often you will hear from them and what happens when something goes wrong. Ask to meet that person before you sign.
If you are switching mid-project
Most switches happen mid-project, and that is when they carry the most risk. These are the ones I see most often:
- Knowledge leaves with the old team. Why something was built a certain way often lives only in their heads. Ask for a written handover, and a call where the new team can ask questions.
- You pay for the same ground twice. A new team needs time to understand the code before it can move quickly. Expect the first few weeks to feel slow, and plan for it.
- Live features go unattended during the gap. If nobody is clearly responsible during the handover, small problems go unanswered. Agree who handles issues until the new team takes over.
- The scope quietly resets. A new team may want to revisit decisions that were already made. Some of that is healthy, and all of it costs time. Agree what is settled before work restarts.
- The contract gets in the way. Check who owns the code, what notice you owe and what the old team has to hand over. These are far easier to settle before you announce the switch.
If you can, keep a short overlap where both teams are involved. A week or two of overlap costs much less than a month of rediscovering what the old team already knew.
The short version
Do not switch teams to escape a feeling. Switch when you know what you own, what went wrong, what the code is really worth, and that the new team will not fail in the same way.
If your build has stalled and you want a second opinion before deciding, this is how I work with founders. Sometimes the honest answer is that you do not need a new team at all.