When a client hires a software developer for a large, custom software project, it’s a lot like a marriage.

These two parties are going to be spending a lot of time together. They’re probably going to see each other at their best and their worst. Without a doubt, incredible things can come from a happy relationship.

But, like any marriage, when things go bad, they can go very bad.

And, like any marriage, the divorce can be a difficult period for everyone involved.

So, let’s discuss what makes changing software developers so tough, what are the best ways to make it just a little easier on yourself as the client, and what you can do to protect yourself before getting burned again.

What makes changing custom software development vendors difficult?

By the time a custom software developer has begun work on your project, you and they have already invested a significant amount of time and other resources in each other.

Depending on the complexity of the project, the developer may have spent anywhere from 1-4 weeks on analysis and planning, with much of that time involving conversations and meetings with your representatives. They’ve likely had to climb a steep learning curve getting up to speed on your business processes and rules, and you’ve taken the time to teach them.

Then, depending on how far into the project they are, there could be weeks or months invested on both sides in the actual development process.
If things have turned sour at this point, a lot of financial and emotional baggage is tied up in the mix. I’ve heard of angry developers holding code hostage, and I’ve heard of clients refusing to pay portions of the developer’s invoices that they rightly earned.

No one wins in a nasty divorce.

Even if the divorce is amicable, though, you’re left with another challenge: you still have a software project that’s left unfinished, and you’re tasked with finding a new developer willing and able to take over where the last one left off and finish the project satisfactorily.

This should theoretically be easy since all reputable developers adhere to set standards for coding.

But the reality is that coding is as much art as science in many cases. Having a new developer come in and take over a project in the middle can be likened to asking Stephen King to finish one of Ernest Hemingway’s unfinished manuscripts. They’re both fantastic writers, but even if he managed to finish the book, it could never sound like a Hemingway classic.

They’re different writers with different voices and wholly different reference points. Custom software developers are just as different in their approaches to a given project.

So, more often than not, clients are faced with well-meaning developers reviewing the existing code and saying, “It would be better if you let me start fresh.”

And it is better for the developer, no doubt about it. But it means essentially throwing away whatever money you’ve already spent on the existing code, and that’s rarely a viable option.

What can you do to make the transition easier on everyone?

In the United States, about 50% of marriages end in divorce. Likewise, around 50% of software projects end up not being satisfactorily completed, or suffering a limited release due to issues during development, and a lot of those issues involve the relationship between client and developer.

So, if you hire custom software developers, you’re likely to face this issue at some point.

When it happens, here are a few best practices that will help ensure everyone leaves the relationship as amicably as possible and you’re in the best position to hit the ground running with your new developer:

1. Be fair to your current developer: even if you feel the project is not going well, pay the developer the agreed-upon fees for what deliverables were completed and whatever verifiable work was accomplished. It’s not worth adding a long, drawn-out legal battle to the mix, or seeing the work they’ve completed held hostage or destroyed due to payment disputes.
2. Be fair to yourself too: that being said, don’t issue final payment until you have everything that is yours in hand – the code itself, any databases, user IDs, passwords, and documentation the developer has created. And don’t complete the transaction until you verify you can access everything, and then changing the passwords to maintain security as you transition to a new developer.
3. Document everything: it’s going to make your life (and your new developer’s life) much easier if you take the time to clearly document exactly what is and is not working with the code at the time your original developer leaves. Likewise, document what remains to be done in order to consider the project successfully completed. That way, there are no misunderstandings or miscommunications adding to the complexity of the transition, and there’s less reason to scrap what has already been made.
4. Don’t just hand over the whole thing to a new developer: in many ways, taking over a project that’s partially completed is more difficult than starting that same project fresh. That means choosing the right developer will be more challenging as well. For that reason, your best bet is to identify a small portion of the remaining project that needs to be accomplished and use that as your “first date” with the new developer. This allows them to get their hands dirty with the existing code, familiarizes them with the project parameters, and provides you with an opportunity to see if this new relationship is likely to work out.

Perhaps the most important thing you can learn, as a client seeking quality software development help, is that there are plenty of fish in the sea. The fact that one “marriage” didn’t work out doesn’t mean your soulmate isn’t still out there.

Speaking from my own experience, some of the best client relationships I’ve ever had started with CSPreston as the client’s rebound developer.

Call us. Let’s talk about how we can do that for you too.