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.
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.