What I will tell you in this article:
- How software outsourcing can be painful
- Certain rules you must follow, to avoid the pain
IF YOU’RE A CLIENT
So you want to get a website designed, or an app built, or some other software made. And you want to outsource the work.
You post a project on an online marketplace. A dozen folks want to build your project for anything from $10/hr to $100/hr.
You probably hire a development firm in India or Ukraine or Poland which had a nice looking website. Their sales chaps promise that their developers are made of stardust, and very hearty testimonials from their previous clients.
And yet you may get BURNED.
Different colours of cow feces you might step on:
- Making a down payment (several thousand dollars) to some chaps from a distant land you’ve never met and never will.
- Realizing that the engineers at the development firm don’t speak English well enough to understand your Southern accent.
- Receiving code later than the expected date, and then arguments with the firm about the code being crap.
- Being asked for a price increase because of unforeseen issues.
- The final outcome looking different from what you expected.
- All communication with the team coming to a sudden halt (bye-bye, $10,000 + 3 months of your time).
- Suddenly having to find someone else to build your project for you and going through the above process again.
- Having to ship a bad product, behind schedule.
CLIENTS CAN ALSO BE JERKS
Don’t get me wrong — developers also get their share of shitty customers.
- Client makes a promise to pay but delays payment.
- You do your job well, but the client accuses you of doing shitty work and says that “anyone could do this for cheaper.”
- The client makes sudden change requests which impact the scope of the work, but he doesn’t understand what’s so difficult about it
- Client suddenly disappears (bye-bye, 90 hours of coding + 20 of scrounging on StackOverflow + the promised $5,000)
What can you do as a client?
People have suggested doing all sorts of things to get around this. I know this one guy who stayed up late for months communicating with a firm in India. I know of one lady who actually went and lived near the agency she hired for a few months.
Now, I have talked to both sides of the table, in private. In my experience, it comes down to three rules to live by:
- Know what you want. A developer is not there to solve your problems. She is there to implement the solutions that you already have in mind.
- You don’t have to be “smart” while finding freelancers, you just have to be aware of common pitfalls and follow a framework. There’s no need to go with your gut feeling.
- Be reasonable and human. The best firms and freelancers are those who have the luxury of choosing their clients. They won’t work with a-holes.
Now let’s go into details.
(If you’re very non-technical, it might be difficult to judge the complexity of a project. In that case, get a disinterested party (like an engineer friend you might have) to help you understand all the aspects of your idea and some important things you should keep an eye for.)
- Finding good development agencies and freelancers
There are plenty of good development firms out there which don’t easily find work because of all the crappy ones that saturate the market. Here’s how you filter out the noise and find the right one for you.
- Don’t follow stereotypes against a particular geography. For example, Asian firms often get a bad rep, but I can assure you that there are a few genuinely good and sincere developers there.
- Set your budget for yourself, but don’t be too miserly. Setting the price too low will attract firms which are willing to work for anything — precisely the ones you don’t want to give work to. They will cost you much more money than you think you are saving.
- For sourcing them, try to go through a third-party vetted network of freelancers or development firms. For finding freelancers, I highly recommend joining the big digital nomad groups on Facebook and posting your requirements. I have heard good things about Toptal and VenturePact as well.
Whenever you receive a bid from a developer, follow this checklist:
- Their personal website should look good.
- They should have a nice portfolio of projects; at least a few of them should be similar to your project. If your project is very unusual and they haven’t done something too similar, look for good variety.
- Look out for information which seems very inconsistent
- I wouldn’t always trust customer references, but sometimes I do if they are on their Facebook page and seem genuine.
- When you talk to them, they should be interested in listening to you and asking you good questions about the big picture of the project and business objectives. They should also educate you on things you are not clear about. If after your first call with them you feel that they haven’t taught you anything or asked any good questions, ditch them.
- They give you a price quote which is neither dirt cheap (unless they are based in a third world country) nor too exorbitant.
- Do a few Google searches about them, and go beyond the first page of search results.
- Ask them about what all they want from you before closing the deal. If they mention things that I will mention in the rest of this post, they are probably a decent firm.
- As I was reminded in the comment below by Josefine (thanks!), you might also want to check if they will sign a legally binding NDA. And if you are very short on time, try to opt for a firm which follows a close timezone to yours. It will make communication easier.
2. Make sure the requirements are crystal clear.
This goes for both the developer and the client. As a client, it’s your responsibility to ensure that you don’t leave any details while describing what you want.
- Provide as many mockups and wireframes as you can.
- Create a set of checklists you will follow to evaluate the project upon its completion.
- Communicate preferences (if you have any) in program design, code architecture, code styling etc.
- Make sure your final product will be easy to integrate with the rest of your tech stack/ecosystem and infrastructure, and also other third party services as and when required.
(If you are a developer, it’s also your responsibility to ask for all this information. In your desperation of closing the deal, don’t let the client be lazy and leave you to figure out all of this by yourself. A year later when someone asks him for a recommendation on good development firms, you want to be on top of his mind)
3. Decide on a strict communication and payment schedule
The key here is milestone management.
- Break down the project into a series of milestones which you can use to time the progress and quality of the project.
- Tell them that you expect them to communicate exactly what they have done, what problems they faced and what they plan to do next, at the end of every week.
- Do as many video calls as possible – always prefer video calls to any other mode of communication (especially phone messages). It will make a huuuge difference. Invest in hardware and software that gives you better sound and video quality if needed, and expect the other side to do the same.
- If you feel the slightest concern that something is not going 100% smooth, take it seriously and ask them about it. Be straightforward in your communication (without being rude) and if they give you vague or unconvincing answers, call them out on it.
4. Review their work in progress at each step
In this industry, you don’t just get what you pay for — you get what you ASK for. It’s up to you to enforce good practices so that you get what you want.
- Ask them to ‘submit’ their work at each milestone. Whenever they submit a piece of code, look at it!
- Use standard libraries like codeclimate to do a static code analysis. It will give you some information about its complexity, duplication, styling, bug risk etc.
5. Don’t be a jerk.
- Be respectful. If you find that it’s hard to be respectful anymore, congratulations, shit had hit the fan a long time back already.
- Don’t throw tantrums over tiny issues. Now, you might not be knowledgeable enough to know if an issue is tiny or major. That’s a complicated situation and I don’t have an “easy” answer. You should consider finding (or hiring) someone technical to look at the project at various stages and counsel you. This way, the developers you hired to build your project won’t be able to easily deceive you when they make a mistake.
- Don’t make threats about not paying every time you find a small flaw or bug in their work. It’s software my friend, there are always small bugs. Even Google and Facebook have bugs in their software.
- Don’t push unrealistic timelines on them. Good things take time. (And you, software firm owners and salespeople, shouldn’t push unrealistic deadlines on your own developers just because a client is being too demanding or a jerk! Your employees are human beings, and if you ask them to do something in too little time it could have very bad quality. Talk back to the client instead if you can.)