Buyer's guide to development outsourcing

Outsourcing parts of your IT developments can be highly cost effective. While running Lokad.com, I have outsourced most of the work for 3rd party connectors (23 of them at the time) and I am considering the outcome as more than satisfying since I would never have achieved the same amount of work without outsourcing, considering comparable delays and financial investments.

This document is a small guide for mISV or ISV that might be willing to go freelance too. May this document help you to avoid my early mistakes.

Getting freelance proposals

Finding freelancers is easy, but being a good freelance manager is hard. Indeed, you have plenty of open freelance websites. I have been using Guru.com and GetACoder.com (among others), but I think that the freelance website has a very limited impact on the outcome of your outsourced projects. Just stick to freelance websites with significant traffic and it should be OK. Do not ever accept to pay anything upfront to post your job, you would be wasting your money.

Multi-posting is cheap, I suggest not to hesitate to cross-post your job descriptions. It requires a bit more work to keep track of all your postings but it increases the amount of proposals that you get. Since you are going to navigate within tons of websites, proposals, coder profiles, I suggest to create some bookmark repository to manage the whole process: a non-public wiki page is perfect for that especially, if you work in a team. Having 100 proposals is not an issue, you just need the right sorting algorithm (see next section).

Disclose your name and your company. Usually the freelancer gets paid at the end of the job. Thus, the freelancer is taking the risk of not getting paid. By disclosing your name and your company, you are reducing risk, in the opinion of the freelancer, of not getting paid. Anonymous job posting are just more suspicious; and the freelancers are going to charge you more based on that suspicion.

The job must be factual and non-ambiguous. Writing a good job description is hard, especially if you want it done quickly. The first paragraph should be a Job overview. In 5 lines or less the freelancer must know whether this job match his technical skills. It’s really important to list all the technologies, languages and tools in this section. If that list can’t fit into 5 lines, then you should consider splitting this job into smaller ones. The comes the Delivery section. This section is the exhaustive list of all the documents that you expect to be delivered by the freelancer and the end of the job. Do not forget to specify the formats and possibly the encoding. At the end, the extensive description and your requirements should be found. Notice that this order is respecting the inverted pyramid principle.

Make the job as much stand-alone as possible. Taking over a job can be a significant investment for a freelancer if he has to get familiar with your tools, your own software libraries (worse, your home-made programming language). The freelancer is going to charge you for this take-over investment. Thus, if you want to save money, make the job as much stand-alone as possible. Often it means that you ill handle yourself the integration of the delivered code into your systems.

Go for small jobs (no more than $1000 at once). The larger the job, the more uncertainties; thus it’s better to stick to small jobs. First, freelancers are only paid at delivery, thus they will not accept to commit themselves to bigger jobs without being paid upfront. Then, if it’s safer on your end to be able to make adjustments along the way like changing of freelancer (if the one you picked does not match your requirements) and/or adjusting your requirements.

Suggest reasonable price and delay. Although, it might be a bit counter intuitive, suggesting a reasonable price is actually a good way to lower the final price. First, it sends a signal to the freelancer about the scope of your job. The worse situation for a freelancer are the ill-defined requirements that leave a large latitude in the workload estimation. By helping the freelancer to make his workload estimation, you are decreasing the job uncertainty and thus, the price associated to this uncertainty.

A question at the end of your job description. This question should be factual and related to the job itself. The purpose of this question is to facilitate your choice when you will be sorting out the dozens of proposals that you did get for the job. Basically, you can discard all the proposals that do not start by addressing your final question. Indeed, if those freelancers did not even bother to read your job description until the end, trusting the job in their hand is a bad idea anyway.

Choosing the right freelancer

Do not trust ratings for IT projects. Many freelance jobs are actually home works submitted by US students. Since 1st year college home works do require much skill (think of Hello World style exercises), many poorly skilled freelancers ends up with tons of positive ratings. Also, non-technical people submit loads of trivial IT jobs like converting CSV data into Excel data. I mean “trivial” for IT professionals, not for your Uncle, the divorce lawyer, who is also buying IT services occasionally. At the end, I have found that positive ratings aren’t reliable for coders.

Discard cut and paste proposals. A lot of Indian companies (well, not only India in fact, they just tend to be more visible) are just cut-and-pasting generic proposals. Those companies do do not even bother to read your job description, and automatically propose a random amount for your job (typically $2000). They also tend to send you a private message (cut-and-pasted as well). Spotting those proposals is easy. Do not even bother to read their long stories about the 1000 satisfied customers. Choosing such a company is only asking for trouble. To be discarded at first sight.

Go for specialists. A lot of freelancers go for the “Jack of all trade” strategy and submit proposals at random no matter the technology (PHP, Java, C#, C++, …). In my experience, the best freelancers are those who are heavily specialized in a few areas; even better but it’s rare, the freelancer who’s an expert with a list of applications (like Oracle 5 to 10). The cost of outsourcing is highly dependent of the final productivity of the selected freelancer. More specialization means shorter delays and increased code quality.

The country has no importance. The “right” person can be anywhere, including the “expensive” countries. As stated previously, the price depends heavily on the final productivity of the selected freelancer. In my experience, productivity easily varies of one order of magnitude between specialized and non-specialized developers. Skills matter, countries do not as long as people are fluent in English.

Go for independent freelancers. Outsourcing companies just complicate the process without adding value. The company is just another communication layer: you get a “manager” between you and the “coder”. If the requirements need to be adjusted along the way (it happens often for the fine-grained detail of the job), you have to negotiate with a manager who do not really understand the problem, because he is not in charge of the job and then re-forward the decisions to the coder. Worse, all the good freelancers realize quickly that an outsourcing company on top of their head is not adding value but eating a significant part of their lunch. As a result, the best freelancers are always those who work for themselves. Do not get fooled by pretty websites of outsourcing companies. At the end, the only thing that matters is the skill of the person working for you.

Probe freelancer responsiveness. Once you’ve cornered a small set of interesting offers, I suggest to probe the “responsiveness” of those freelancers. Most freelance websites provide some sort of private message system. Just a send a private message (raising a question about the freelancer proposal for example) to see if you get an answer within a short delay. In my experience, discard any freelancer who can’t respond to your message within 24h. Responsiveness is a key of effective freelance works, if you can’t even get an simple answer like “I am too busy right now, give me 48h”, then the chance to get the job done are low.

Managing the freelancers

Outsourcing must be part of your strategy. Managing freelancers take time and skills. Taking the “right” strategic decision can significantly simplify your outsourcing processes. For example, at Lokad, we have put released all our 3rd party integration components as open source. Disclosing this source code is not an issue since it does not impact the Lokad core business. Yet, in terms of outsourcing, it significantly simplifies the process. We do not need to transmit any access codes to freelancers, everything being readily available. Furthermore, it facilitates price and delay estimation on the freelancer side. Open source is only one option among others; but keep the idea in mind: a lot can be done to facilitate 3rd party developments without damaging your core business.

Anticipate a high failure rate. A lot of things can go wrong. You might realize that the freelancer do not have the required skills. The freelancer is bidding on many jobs at once and takes other commitments after bidding on your job. Your job description was ambiguous. etc… Anticipating a 30% failure rate while hiring a “new” freelancer is not unrealistic. Yet, a 99% reliability would cost you x10 more; thus it’s a trade-off between acceptable risks and costs. Part of the reasons that make outsourcing cheap is because nobody takes strong commitments.

The infrastructure has to be ready. There are tons of tools that facilitate remote freelance works: source code manager, bug and feature tracker, open forums, etc… This infrastructure has to be ready before you actually start to look for freelancers. Otherwise, you and your freelancers will end-up wasting a lot of time on mundane communication details.

Strong IT skills are required. You must be able to do what you are asking from the freelancer; at least potentially, if the time was given to you. First, if you’re not an expert yourself, you will not be able to write an “efficient” job description that include the necessary technical details. Second, the freelancer is going to raise very technical questions on the job (like “What encoding do you want?”), if you are not able to answer, then the whole process is in trouble because even the smartest freelancer does not know the exact technical requirements of
your business.

Be super responsive. Remember that most of the time, when the freelancer is raising a question, it’s because he is stuck. In order to move forward, he needs your answer NOW. Making yourself available through your favorite Instant Messenger can greatly increase the speed of your freelancer. Worse, if you’re slow to answer, the freelancer might be tempted to start another job because, you’re not keeping him busy (wasted time = wasted money) and this is not going to improve anything for your deadlines.

Nights and week-ends do not count. Most of people in the world do not live in the same timezone as you do. Thus, your “business hours” are completely irrelevant when it comes to freelancing. Also, many freelancers do have a part-time or full-time jobs already and wants to make some extra money during the week-end. In my experience, those people tends to be among the most skilled and efficient freelancers. Yet, those people are working the weed-ends. The “super responsive” condition applies 16h / day and during week-ends too.

Source code must be proof-read. Never trust delivered code without proofreading it. Proofreading takes time, but not doing it is asking for trouble because the freelancer will not be there to answer your questions once the job is closed. First, you must make sure you understand the delivered code entirely (see point below); but you want also to make sure that your coding guidelines are respected and that all the job requirements are met.

Ask for code comments, re-ask for code comments. Once the job is closed, the freelancer is gone; leaving you alone with the delivered source code. As a result, the source code must be heavily commented in order to be sure that the code can be maintained at a reasonable cost. Yet, the code comments somehow conflict with the freelancer goal get it done as fast as possible and move on. Thus, you have often to put some (limited) pressure to get source code comments from freelancers.

A formal testing process has to be devised. If unit testing is possible in the context of your job, then go for unit testing. Otherwise, make sure you that you have a formal way of to validate the delivered source code. If the validation/testing process is manual and tedious, you can include it as a part of the job description. For example, I have often asked the freelancers to provide all the necessary screenshots as a part of deliverable elements.

Once the job is done, pay immediately. Depending on your business, several weeks of delay for a payment might be acceptable. Yet, for online jobs, several weeks is a HUGE delay. As a rule of thumb, freelancers expect to be paid in less than a week. In this respect, instant payment systems (like Paypal) are usually quite appreciated by freelancers (at least for those who have access to Paypal in their country). Being a fast payer is important for the freelancer, delaying the payment for weeks will significantly reduce your chance to get this freelancer working for you again; especially if the freelancer is talented.


Reader Comments (9)

Very nice run down, well done. One question; could you elaborate on what you said about asking a question at the end of the job description. Could you give an example? Thanks for the resource. May 31, 2007 | Andrew


Often it’s easy to ask a question about the tools or the validation process to be used for the job. Please indicate which browser will used to test the delivered javascript? –> Good answer is “Both FF and IE” Please indicate which data you will be using to validate this algorithm? –> Good answer is “Well chosen data that cover all the corners cases”. The only purpose of the final question is to distinguish freelancers who actually read your job description from the ones who did not. Then smart people will try to come up with a smart answer, no matter the question. May 31, 2007 | joannes


Most of the freelancers are zombies cuting and pasting template bids.. even a “Please, include the answer to 2 + 2 in your bid” will do it. May 31, 2007 | Anon Anon


Yes, 2+2 should filter out 80% of the proposals. Yet, raising a question where the freelancer has a chance to make a “smart” answer can significantly help you picking THE freelancer out of the 5 reasonable offers that you did get. May 31, 2007 | joannes


Great post! The idea of putting a question at the end to see if they read the whole proposal is brilliant! I’ve only outsourced one job and this one tiny tip would have helped. November 23, 2007 | Doug


[…] have been a long time consumer of freelance marketplaces. Yet, all the freelance websites that I have experienced so far left me a feeling of half-backed […] April 2, 2009 | Joannes Vermorel’s blog


I’m new to the web design business and had a very unsuccessful first attempt at outsourcing some PHP programming. My chosen freelancer seemed to know his stuff but would take days to return messages. Love the idea of testing the freelancers though questions and for responsiveness. Plus - asking for code comments is so obvious and yet not something I’d thought of. Thanks very much!!! June 4, 2010 | Blue Llama


I completely agree with the fact that RATINGS should not be trusted in freelancing and would like to add to the point that there are many companies which create multiple buyer/seller a/c with sites like scriptlance etc as it doesnt cost a buck and give their primary company provider a/c many positive ratings. I would also like to add a new fact that you should check how many projects has a freelancer already bid on or won in the past 1 month, if they have taken say 5 or more projects worth 30each(oranysuchlowpriceprojects)andtheykeptthetimetocompletion oftheprojectlessthan3daysforeachandtheyarealsobiddingonyourproject withsaytimeofcompletionon1dayor0dayjusttorankhigher,thenyousimplyrejectthemastheywillby9930 from multiple buyers telling them that their project can be completed in a day or so. I would also advice buyers to not outsource projects worth 30tolessthan150 as in most of these projects, buyers are fooling not the so called cheaplancer (abbr.for cheap-freelancer) by underpaying them but they are actually fooling their future as many such freelancers who can make an amazon.com clone for 30in1dayisnobodyotherthanascammerwhowilltakeyour30 and run away, so try to keep a justifiable amount for your project and don’t be happy in choosing anybody who is begging to do your 100projectfor30 in 1 to 3 days, they will make you a beggar one day. Plus one more reality fact, sites like getafreelancer are just depriving new and good freelancers from scammers by a few bucks, yes im true, there are memberships like GOLD membership and free membership for freelancers, in GOLD membership the freelancers who may be big companies or even scammers can easily purchase GOLD membership and get hold of projects worth $3000 each while the free member freelancer who may be a SCJP or MCTS passout on their parents pocket but doesn’t have the money to buy a GOLD membership will not be able to bid on your project, so i would like buyers to ‘NEVER LIMIT YOUR PROJECTS TO GOLD MEMBERS/PREMIUM MEMBERSHIP Freelancers’ and give everybody an equal opportunity then only you’ll be able to find some interesting and hard working INDIVIDUAL freelancers(not managerial IT companies) as per your needs. June 26, 2010 | Abhishek Jha


To remove price uncertainty I’d recommend “per job” rather than “per hour” pricing model. That also makes the developer focus on job completion rather than hour inflation. Thanks September 4, 2010 | Evgeni