Many first time founders and startups end up switching their development partners as do many co-founders who need to find new CTO's.

I've experienced this personal with co-founders and many times with clients needing to work with us from old partners.

The change can be smooth but it can most definitely be complicated too.

Here we cover:
 
1. Top Reasons for changing Developers
2. Unsure? Things to look our for
3. Definitely changing? What you need to do
4. New team, What Next?
5. Set Project Priorities
6. Conclusion


Top Reasons for changing developers:


1. Poor Communication

They're not responding, and when they are, they're avoiding questions or giving vague answers. Sometimes it can also just be down to poor English and problems consistently occur due to misunderstandings. The details are important in tech, small miscommunications can lead to big problems.

2. Poor Quality work

Buggy, Janky, Slow not matching the designs to pixel perfection. URGH! In-experienced and cheap developers will produce poor quality work. In the world of tech you get what you pay for! Cheap developers will cost you more in the future fixing things than you'd ever expect.

A quality developer right from the start will actually save you money and make it back for you with a beautiful monetised finished product.

3. Consistently missing deadlines

Tech projects aren't easy and they're not predictable. Experienced Developers know this and will only ever give best estimates for deliveries and if they're not going to hit them explain why far in advance. Bad developers won't say anything then simply not show the work when it comes to the deadline with poor excuses. Transparency and explanation is key to a trusting relationship between client and development partner.

4. Spending time on tasks not agreed

Watch out for this. This can happen due to miscommunication or developers not paying attention to priority tasks. This is time lost even though it may seem like they're trying to be helpful. It results in more testing in areas that can be saved for later and potentially more bug fixing leading to more time lost. A good project manager should ensure this doesn't happen and stick to incremental building.

5. Lack of Enthusiasm

Perhaps your relationship just feels a bit...stale?

Simply too transactional with no passion. You'll be spending an enormous amount of time with your developers on a project you're passionate about solving a real problem for people.

This should a joy to work on and good developers will be your biggest cheerleaders towards the mission while also challenging you and supporting decisions where they can.

They're your TEAM not just your developers. Find ones that CARE.


Things to look out for:


1. They're promising to finish the work by a certain time

I'm sure they are! This often rarely happens, they can't do it. They're struggling, they end up working for free stretching hours with their team who have completely lost interest.

2. Still have bugs? CUT YOUR LOSSES EARLY - It's ok!

In the past I'd held on to developer with false promises. IT DRAGS.

But when you're naive enough to believe them you know no better. CUT YOUR LOSSES.

Move on. Find that new developer to get stuck in and move forward.

Advice I had from a seasoned founder with a big exit was "I've never regretted my decision firing someone". Especially if your guts saying so too.

If they're extraordinarily talented it may be significantly harder, but if they're not showing up and not delivering, there really is no point. You have to let go. The

Bright side of cutting losses early:

When you cut losses early with bugs still in the code it's actually giving a unique opportunity for the new developers to really understand how the code base is working.

The early days of a takeover involve getting familiar with the project, and there's no better way than simply getting stuck into the code to understand it and get things done.

This will also give you a good idea of how well your new developer performs compared to just watching them build new things.If the bugs are unfixable it will be made clear very early.The sooner you cut your losses the sooner you can move forward and get new developers learning and committing to the project.

3. Do some snooping! - Are they working on something else?

I'd discovered a developer of mine was secretly pushing updates to an app of his on my time. It wasn't hard to find their app in the Appstore and see the last time it was updated. Look for signs like this. If they are and saying they're not then you have a liar on your hands. Screenshot any evidence you can.

4. Hostile behaviour! - Refusing to give access to code

This is the worst case scenario and does happen. Your developers are becoming hostile to the news you're looking to change. They get defensive and argue they did everything right etc etc. Losing a client is a big blow!

It should never be hostile and you should always have freedom to move. Good developers will build your project in a way that if they fell off the face of earth someone else could easily pick it back up.

The fact they're hostile is a huge red flag. Let's pray you have access to the code, contracts signed and everything paid for.

They can end up holding your code hostage until you pay a huge amount of money to gain access.

We have experience dealing with this situation, so get in touch as we'd love to advise on the situation.

Remember they're entire reputation is on the line at this point.


So you definitely need to change Developers?


Here's what you need to do: 


1. Identify your new development team

We're here to help at leojbarnett.co of course!

Or any other good team will be here to ensure the process is smooth and ensure you're making the right moves. You've got to know what code your app is built in and whether the new agency can confidently take on the project due to their experience.

We can also assess the amount of work you have ahead and advise on where any red flags might be. We're very happy to hold your hand and guide through the process.

2. Ensure you have Access to the code

Own your code. Own your code. Own your code!

You should have this from DAY ONE. And before starting any project a signed contract or services agreement clearly stating you own the code and should have open access to it at all times.

The nightmare situation is your code gets held hostage by the developer or development company. Create a GitHub repository (Repo) that you own and have all the projects be built from there with your developers invited as collaborators.

If you're unsure about this, get in touch.

2. STAY FRIENDLY - You might still need them

It's essential not to burn a bridge here. The ideal handover of a project requires collaboration between the old and new developers.

Your new developers should be able to message or call your old devs to ask quick questions regarding structure or features that aren't immediately obvious.

It can very often get hostile so matter what, keep your cool!

Project Handover Top Tip:

If you've made the decision to move on but they're not aware of this, tell them you're just expanding the team to move faster with a secondary team. This should defuse any immediate hostility and enable a new team to quickly gain access to the code to assess the quality and everything else that needs to be done.

Continue the project as normal with new developers alongside and phase out the old ones.

Your new development team has the code.

What next?

1. Assess the codes state and quality

Any project should be easy to take over realistically if built correctly with easily readable and modifiable code. You'll receive a report on the state and what can be done. Does it need a small overhaul, complete re-write or no updating at all. We'll let you know and get to work!

2. Establish Project Priorities

Depending on the state of code new developers might be able to get to work immediately fixing bugs and building the features you need.

3. Sign Contracts / Services Agreements

You always need these signed at the start of a project. Include a clause that clearly states you fully own the code and the project will be built through a repository owned by you. We will provide a template agreement for you to sign.

4. Shared project roadmap and estimates

A google sheets space listing bugs to fix, tasks to complete and features to build. New developers can then give fresh estimates completion and costs.

5. Work in sprints!

After new contracts are signed it's time to start working. When you work in sprints of one to two weeks you're always protecting yourself by ensuring bills don't rack up with developers and you ensure they can actually compete work to the quality you need! Pay for completion of milestones.

5. Remove old developers from all project spaces

Github, App store Connect, Google Play Console, Google sheets and anything else they might have permission for.


Project Priorities might be:


1. Get the app live ASAP no matter what the state.

We understand. Getting to market and making money back and getting in users hands asap is the goal!

New developers can do everything they can with bad code to fix bugs and make this happen to save money and time which is fair enough.

Getting the app stable and working can often be done even if it's chaos behind the scenes to keep investors happy and start validating with early users.

2. Overhaul parts of the app and then go live

You may need to have a small overhaul of some areas in order to scale the app and be stable enough to go live. This may mean fixing some bugs and changing some structure to be able to build further planned features.

3. Re-write from the ground up

If the code has been a dogs dinner sometimes it just needs to be totally re-written. In the long term this can be the best option compared to plastering over wounds that can't scale for the future roadmap.

Good developers will salvage what's possible to save costs and time and we always hope to build faster having a very clear idea of what needs to be re-built as the structure is somewhat there.


Conclusion


It can be stressful to change developers but we'll make it as smooth as possible. Working with the right team is the biggest decision you can make as a founder, so take your time doing it.

- Always have access to your code, always get contracts signed and ensure early on that quality work is being produced and on time.

- Cut your losses early when you see the signs to move forward faster and let your new team get stuck into the project even if bugs left to fix.

- Keep it friendly with your old/existing developers. Never lose your temper if they're being difficult. Be overly friendly if anything.

- Make your priorities clear with new developers so they can understand your business objectives and help you move forward the right way.

Good luck out there!

Leo

**********

leojbarnett.co is here to help and we'd love to be your new development partner or consult on the steps you can take to ensure a smooth project handover.

We've seen it all before. Get in touch to see how myself and team can help!

Let's make a world class app together with no stress.