Max Klein

I’ve been using rentacoder for 8 years, and it’s really useful in keeping your costs low. Here are some principles to successfully using rentacoder as a buyer, in a manner that is fair to both you and the coder.

What to know before you start
Rentacoder does not have skilled developers from western countries. What it has are freelancers from countries like Romania, India, Pakistan and Russia. The price level is also at the level of those countries.

The availability of particular skills is very limited. There are a lot of good PHP programmers, many mediocre designers, just a few python programmers and a very few rubyonrails programmers. It’s generally a bad idea to pick people from western countries to do PHP stuff on rentacoder – the competition from really good programmers based in cheaper countries will make it unsustainable for these people to do long term.

For C++ and more complex projects, you can pick from the U.S and Europe. For content writing, I have had the best luck with expats from U.S and U.K who are living in cheap countries like Thailand or Vietnam.

When writing your bid request
Don’t bother making people sign an NDA before seeing your bid. That’s just silly. Turn on the setting to privatise your bid afterwards, you don’t want coders going through your profile to see what you paid other coders.

Write the programming technology you are going to use in the title, so that the coders can see immediately if they are good for this. Remember, the coders are going to see the projects in a big newsletter sent per email. Always wait at least one day for that email to be sent out before you start selecting.

Put what the project is worth for you as your maximum bid. You will really get more quality if you pay more – the difference in the number of bidders when you go from $450 to $550 can be massive.

Never ever select the option ‘unsure’, or your project will be bundled up with a bunch of $20 projects. This will put your bid right at the bottom of the email, and few coders will see it or be interested in it.

Don’t use list form for your bid. I.e, don’t break down the project into a list of items so that the programmer can process each chunk. Every time I do this, it results in very very few bids. I think that people see the list and it seems like a lot of things. Instead, give a high level overview without going into the details yet.

If you can make screenshots or mockups you will get a lot more qualified programmers. Remember that what the programmer wants is a buyer who knows exactly what they want, are not going to expand the scope of the project, and who have specified the bid in such a way that it is not ambiguous. Ambiguous bids are the worst thing that a coder can get because then he is stuck doing a project that the buyer can add things to.

Give the coder enough details that he can estimate accurately how long the project will take. If he can do this, he can decide then if he wants to start or not. Do not gloss over something that sounds like it could be difficult. For example, a sentence like:

“Then connect to a server whose API I will send you later”

is dangerous for a coder. You may come up with some complex specification that means a lot more work. So any pro coder will skip over such jobs.

When selecting the coder
If it’s a design job, ask for samples. Don’t make the people design something for you as a test, the bidding is very fierce on rentacoder, there is not time to do a custom design for people who will then pay nothing.

Look at the ratings. Never ever go below 9.3 average. Do not EVER go for someone with less than 5 ratings for big projects. Yes, everyone needs a chance to start, but any coder with less than 5 ratings can abandon your project and open a new account. He is not invested in this account. When the going gets tough, it’s over. Coders with no ratings have to do small jobs for a while to up their rating.

If you see that a coder was in arbitration in the past, this is not neccessarily his fault. Some buyers are just jerks and the coders get stuck with a project that would last a month and they would be paid $50. So they need to go into arbitration, which gives them a 3 rating on the project.

If a coder has 50 or more projects and a 9+ rating, it means he is a fulltime rentacoder programmer. This means he will likely do a good job, but he likely goes for quick efficient projects and will likely have multiple projects running.

After narrowing down your selection based only on rating, send a message to each person, discussing some part of the project. Coders have to typically bid on a lot of projects to get one, so they may not have time to really talk in-depth about your project. But when you send them a message, any coder who does not reply within 12 hours (pay attention to his timezone), or replies with just a short message (does not put any time into it), then forget it. The ones who are good, exchange one or two more messages, then pick the one you want. Be sure to look at how many projects he is currently working on, and if too many, ask him about this.

You can leave feedback on the ones you did not pick (if you were already in a conversation with them). I like to start new projects for them, because good people should not be wasted

The progress of the project
Be professional. There is no need for jokes or being overly friendly or pally, or discussing how your day was. Just explain clearly what needs to be done.

Typically, a rentacoder coder has more than one project running. The other one may just be in the slow bug-fixing phase or testing phase. Or perhaps he got accepted for multiple projects. Coders have to guage which buyer is lenient, and when crunch time comes, they will focus on the stricter buyer.

So don’t be hands-off, else your project will certainly be delayed should there be a conflict with his other project. The best thing is to micro-manage – every 2 to 3 days review what has been made. The rentacoder system makes the programmer give you the code as he is making it (not at the end of the project), so constantly look it over. Test and point out bugs as he is working.

If you can get the coder on skype voice talking to you, this is really good. But don’t insist on it, because a lot of coders are not comfortable with this, particularly if english is their second language. But do have him on IM so you can kind of guage when he is available or not. If you notice erratic behaviour and not logging on for a while, then start micro-managing even harder, because it means he’s busy with something else.

If your coder is having problems, cut features. Even though you specified a project scope, it’s better to have a good thing with a smaller scope than have to restart the project with another coder. If your coder asks too many questions and it turns out he is not that smart, get a bit angry, this will make him sit up a bit.

Remember that the rating is your biggest power over a coder (it’s not the money, since you don’t control this anymore) – don’t threaten with this, except when things are going wrong.

Answer quickly and accurately to the questions your coder poses to you. Don’t wait.

The end of the project

The end is the most difficult part of the project because the coder wants to get paid. Remember, the coder cut-off date is the 15th and the 30th of the month. This means that every coder wants his project accepted before those dates. Make an effort to do so. If the job is 95% done and it’s the 14th of the month, then accept 95% so that the guy gets his money.

Don’t expect a long-term relationship with any coder on RaC. It does not work that way. RAC is where people go when they are between jobs or need extra cash, it’s not a livelihood. It’s just a stepping stone for most people. So don’t give any concessions thinking you will have a long-term relationship. You likely won’t.

Sometimes the coder feels the job is done, but on testing, you notice a lot of small things missing. Be careful when telling him new things to do that you do not expand the scope of the project. If you have a site and you discover that actually the site is useless without search, but you never put this in your project description, then don’t add it right at the end and beg the coder to add it. This is frustrating for him. Instead, offer a bonus and give him the choice of adding it if he wants. He most likely will.

When testing, don’t post each bug as a message, instead, test properly through, make a list of real bugs (not new features), tell him how to reproduce and paste as a single message. Then he can sit down in one sitting, and get it all done. The mode of testing where you post a bug, then 4 hours later another bug means that a lot of time is wasted just sitting and waiting, which is frustrating.

If at the end of the project, something small but annoying comes up that cannot be fixed, then don’t torture your coder. If he spends a few days and cannot fix it, then consider getting someone else to fix it.

Test quickly, and accept the project quickly. Many buyers are afraid of bugs creeping in at the end, so they string the coders along while they test the site intensively. This is the worst part of the project for the coder, because then he is interrupted to fix bugs when he likely has started working on some other project.

Remember, after every project the coder is worn out. Don’t immediately ask him to start something new. Let him rest for a few days. Say that you have a new project in a few days and if he is available, he should message you in a couple of days. If he does message you, then he is coming of his own free will, and is likely to do a good job. Remember this: Follow-up projects are usually worse quality than the original project!

Only use arbitration as a last resort. It wastes a lot of time and is fatal for the coder. Try to work something out before this. If a coder is being wrong, there are two tricks you can use to kick him off the project: If he misses a status report, you can instantly kick him out. If the deadline expires and the job is not done, you can kick him out immediately.

And finally, when done, rate the coder a 10. Even though you can rate from 1 to 10, in practise there are basically only two ratings given: 10 or 9. 10 means everything went fine, and 9 means he did something terribly wrong. If he was great or good, use the comments to say so. If he was not good but did the job, rate him a 10 but leave no comment.

That’s it. Remember, RaC developers are people trying to use their skills to get by. Be nice but not a pushover, professional but not too cold, pay well, but take advantage of the fact that it is cheap.

If you're interested in technology & startups, then follow me on my low volume twitter account

---