Dude, where’s my source code? – What to do if you’ve hired a bad offshore software developer
Let’s face it – sometimes things don’t go as planned. Your rock star developer, who was supposed to ‘kill it’ on your new product build, suddenly needs another month to show you something. Or even worse, has disappeared completely. What do you do? After all, you’ve already invested time and money with them, maybe it’s worth waiting a bit more?
Before anxiety takes over, let’s have a sober look at steps you can take to get your project back on track – or at the very least, cut your losses quickly.
First Off – Structure Your Projects to Minimize risk
When dealing with a situation like this it helps when your project is structured right from the outset. Anticipating that unexpected problems can happen, you would have included necessary safeguards to minimize your risk, such as:
- The project scope and deadlines are clear and documented and agreed to by the developer – preferably in writing.
- The project is broken into smaller modules/milestones with no more than 1 month between each milestone and corresponding delivery or deployment to the staging server, TestFlight, Google Play alpha testing, etc.
- You used an Escrow service, such as UpWork escrow, for the downpayment.
- You have access to the git repository with the code and you regularly do ‘git pull’ to have the latest version. Ideally, you should own the git repository.
Secondly – Learn How to Recognize a Bad Developer Quickly (and cheaply!)
The initial stages of the project are inherently risky, as you and your developer don’t have much of a track record working together. Because of this, the earlier you learn about a major issue the better. Here are 5 early behaviors to watch out in your developer in the first few weeks:
- Unable to show work-in-progress on a weekly basis
- Repeatedly missed deadlines
- Pattern of misunderstood requirements, not following the design
- Bad code quality (ask your technical mentor to review)
- Attitude and communication issues.
Don’t panic if there are bugs in the work-in-progress version, but make sure to report them in detail. Also, if you ask for changes or features, not in the original specification – the delivery time and the budget must go up. This is often misunderstood by clients, some of whom think that a fixed-price project should include unlimited revisions. Think about it like this – if you hire a guy to paint your house blue, he does it and later you realize that pink is a better color. Do you expect them to repaint everything for free? That’s why it is so important to have a clear scope.
If you’re wondering what issues other entrepreneurs are having with their developers read their horror stories in this article.
How to End the Relationship Without Putting Your Business at Risk
Hopefully, it’ll never get to this, but what if you realize enough is enough? As traders like to say – cut your losses short. From my experience, if working with a developer starts off on the wrong foot it rarely gets better. Before you make your decision known, however, it is important to protect your business from possible risks. Make sure of the following BEFORE you open the conversation
- You have the latest source code
- You’ve disabled the developer’s access to important accounts: hosting, FTP, Amazon Web Services, Google Docs, Dropbox, etc.
- If you use UpWork or other escrow service, you’ve consulted them about the dispute resolution procedure.
- You’ve thought of other potential ways an unethical individual can gain leverage over you – and make arrangements to minimize the risk.
How to have the conversation and structure the handover
If your developer has disappeared then there is not much you can do. Firstly, initiate a dispute resolution process at your escrow service to get your downpayment back. Then start looking for a new provider.
If, on the other hand, the developer is responsive, clearly state the reason why you can’t continue working on the project together. Politely let them know that they are not a good fit for this project, but you’ll consider them in the future. Your goal is to wrap this up as fast and amicably as possible and get back to your startup. Therefore, try to avoid an open confrontation.
It can be frustrating to start the process over, but this is minor compared to other challenges you’ll have to face as an Entrepreneur. Also, consider the impact of getting further down the line with a bad developer. In fact, from interviewing startup founders we’ve noticed a clear pattern: people who are able to cut the losses short and keep moving release their product faster and pay less.
For example, that’s the situation Nathaniel Smithies of PlusGuidance.com found himself in: slow progress, misunderstood requirements and low-quality code (after review by his technical mentor). Replacing the development team was not easy, but it turned out to be a great decision – the one that allowed Nathaniel to get the project back on track and lead the company to a successful acquisition.
If nothing the developer produced is usable (e.g. nothing works as it is described in the specification), you have the right to not pay them, in my view. If a part of what they did will be used, it’s fair to pay for that work only. Consult with the escrow service to find out your options. If you use a modular approach, you should not have too much money at risk at any given time anyway.
It helps to know that your review gives you leverage. Positive reviews (or lack of negative ones) are essential to finding work on sites like UpWork.com or Freelancer.com. Most freelancers care about their reviews and are willing to compromise to avoid ones that damage their profile.
To help you out, here’s a message I sent to a developer that didn’t work out:
“Hi [NAME], due to your lack of responsiveness, we decided to terminate your involvement in the project. You are clearly a smart guy and know Ruby-on-Rails very well, but apparently there is no motivation in this case. If you have a feedback for us, let me know. Regarding the money: send your calculations and I’ll make the payment.”
The guy apparently felt relieved. Turned out he really enjoys working on open-source projects and that’s where he got most of his expertise from. However, following instructions and deadlines on commercial projects is not something he does well. I wish he told me earlier, but that’s just a cost of doing business – this does not happen often.
To wrap it up, let’s consider a situation when you’re not completely sure if you want to change your developer. Maybe things are moving, but not as well as you’d hoped. In this case, try hiring a new developer to work on a small independent task or module or fix an existing issue. That way you can compare their performance and have a clearer understanding of what you want to do. It’s almost like A/B testing.
Also, keep in mind that stopping a freelance project is not the same as firing a full-time employee. As long as you keep your communication professional, over time you will have a pool of providers you’ve worked with. You’ll know their strengths and weaknesses and will be able to use them as needed.
Ever worked with horrible developers? Have a tip on how to deal with situations like this? Share your story in comments below.