Pros and cons of hiring freelance ruby developers

Welcome to the most one-sided article on the internet, as a company that hires out our Ruby development skills you will forgive me for saying there are no downsides and unlimited, near infinite, upsides to working with a Ruby freelancer.

I’m joking of course, there are most definitely downsides, and deciding between a permanent hire, versus a freelancer, versus an agency is incredibly tricky and full of nuance. There is no equation you can answer that will pop out the best suggestion for your company and project at this very moment in time.

One way I help companies is to step in as a kind of interim CTO or technical lead, normally on teams that are just about to start growing, so I end up wrestling with this question a lot. This article is what I’ve learned about the pros and cons of hiring a freelance Ruby developer.

Why Ruby Developers? I’ve helped hire or commission all sorts of different types of developers, but the majority have been Ruby developers. I’m fairly confident this advice spans all forms of development and hiring in general, but I can whole-heartidly stand over it holding for Ruby developers.

Before we get into the article properly, I want to define some terms, just so we’re all on the same page.

• Full-time, part-time, or permanent hire - This is someone that you pay an ongoing wage to, they are your employee, you will need to provide equipment, insurance, and all the other stuff that comes with a full-time employee.
• Agency - An external team of people working on a specific project. Whilst an agency can certainly specialise in one small aspect of development, in this article we will assume an agency will include several types of specialist.
• Freelancer - This is someone who you pay per project or as a day-rate who is not a full-time employee. They will often specialise in one area of development and will work independently.

Instead of having a Pro heading and a Con heading and listing things under each, I will state the type of thing you should consider and then compare picking a freelancer to picking a full-time hire or an agency.

Developer Cost

Normally the first question a company wants an answer to is how much is someone going to cost. Naive calculations would pick market rate in the area you are hiring and use that as a basis for comparison.

For anything 12 months or less, I’m going to say that a freelancer will almost always be cheaper than a permanent hire, even if their day rate is a lot more.

This is because there are a tonne of costs associated with hiring a developer into your company. Here is a non-exhaustive list;

• Their salary
• Any health insurance your company provides
• Any pension your company provides
• A laptop or workstation and related peripherals
• The software required to do the job
• Buying more seats on products all employees need, like email, intranets, etc

Most of these costs are recurring and will quickly surpass all but the spiciest of day rates quoted by a freelancer.

With a freelancer you generally need to pay the day rate or project cost and perhaps if the project calls for it some seats on some of the company infrastructure. Most of the companies we work with end up giving us guest or limited-access accounts which are free or cheaper for the company.

If you are only looking to get one more person on then the main difference between a freelancer and an agency is that the agency will cost more. They have more overhead, including lots of non-billable staff which need to get covered in a day rate.

It is not uncommon for agencies to bill us out at their normal day rate, pay us our normal day rate and still make a healthy profit. (Are you an agency that wants to make a healthy profit hiring out Rails developers, get in touch!)

If you’re hiring a team of people, the costs start to favour agencies because if you’re hiring multiple freelancers, you will also need to factor in the costs associated with managing the entire team versus one person.

For projects lasting more than a year, the costs start to skew towards a full-time person working out cheaper. You rarely need to buy a new laptop each year, and the value you get from someone after a year really starts to mount upwards, see “Longevity”.

Onboarding Effort

You’ve made your decision and it is their first day, how much effort is going to be spent onboarding someone?

For this discussion, let’s assume that onboarding means all of the tasks that are required before someone can do the specific work they were hired to do.

Over a long enough timescale, the amount of effort could be negligible. If you’re hiring someone for a nine-month project then the chances are it doesn’t matter if the first week is spent with a closed laptop lid.

If the project is planned to take two weeks, that is a different story.

There is generally more work with a full-time employee because of all the additional things they need added to. Learning how to access various systems, how to contact IT. There is also normally some sort of employee handbook to read and some online training to do.

Even if your company is like so many other companies that do a really poor job of onboarding, it will take some time for your new hire to set up their new computer if they are going to be in any way productive.

Most but not all of these things can be bypassed by agencies and freelancers, which generally means they will be more productive sooner.

I want to caveat that last sentence somewhat. I fully appreciate that the productivity of one person can’t be measured by how quickly they get to work or even the amount of work they do. I’m also incredibly pro good onboarding for everyone. We did some work with Barnardo’s who had a fantastic onboarding programme, which I feel made our team of freelancers much more cohesive.

If you have a small project that needs to get on the door as soon as possible, an agency or a freelancer will be able to tick more HR boxes more quickly and be able to start project work sooner than an employee would.

Longevity

The longer someone works with you the more value they add. This is because whilst technical skills are important for a developer, the value comes from applying those skills to business problems. Learning how your business works takes time and the more someone knows about it the better solutions they can make.

This is the first area where full-time employees will always win hands down.

If all goes well your employee will work with you for a solid three years before moving on. During their tenure, most employees will develop deep domain knowledge.

It is rarely practical to engage with either a contractor or an agency for that length of time.

Even if it were practical, contractors and agencies are treated differently by internal staff. There is an expectation that employees will hang around for longer than other types of folk. This influences how people interact with each other.

The longer that someone works with you, the more relationships are formed and unspoken ways of working developed.

Longevity, in my experience, is a very personal thing. A team exists only as long as the individual members of that team, as soon as one person enters or leaves the team, you are dealing with a new team.

This is one of the most common issues I’ve seen with companies hiring agencies. They assume they will get a consistent team, but the practicalities of agency work mean people will come in and out of the team. This isn’t necessarily a bad thing, especially if the people are changing to allow different expertise to shine. The best documentation in the world doesn’t bring someone up to speed as well as sheer experience.

Developer Experience

Companies are generally pretty bad at knowing what level of developer they need. They often undershoot or overshoot by a lot, both are problematic.

Keeping a very senior employee interested if most of the stuff they are doing they’ve done 100 times before is going to be a struggle. Which will mean staff turnover will be high, and hiring a new member of staff is an incredibly costly endeavour.

What is also costly is paying a day rate to someone with 20 years experience to do a job that could be done by someone with 2 years experience. The difference between an employee and a contractor is the contractor will be less likely to quit.

Agencies remove this headache, you are entrusting them to pick the most appropriate team members for the project, which at various times could be relatively inexperienced folk or incredibly experienced ones.

Hiring Effort

Hiring anyone is costly. Deciding the type of person you need takes time, finding candidates takes time, interviewing them over several rounds, and at the end of it you might not even have a good match.

There is effort involved regardless of employee vs agency vs freelancer. The main difference is in where the effort sits.

You tend to not interview agencies. They pitch for the work and if successful they get it.

You tend to interview freelancers a lot more casually than you would an employee, this saves on people’s team needed for interviews and following up. I think this is more a product of freelancers not being interested in being interviewed. Personally, if you required me to do the same level of interview as a potential employee, I would opt out.

The interview process is just the tip of the iceberg.

If you decide to use recruitment companies to help, you will almost never be recommended an agency to fulfil multiple roles, they will find individual employees or contractors. There isn’t a common model for recruiters to make money by putting you in touch with an agency.

Really good recruiters will help shape your job ad to be accessible and welcoming to all, they will reach out beyond their immediate networks to find diverse hiring pools and do the due diligence to only field folk who really do seem like a good match, and importantly, that match needs to go both ways.

In my experience there aren’t too many really good recruiters. Plan to have to put in a lot of time and money in getting your job seen by the most relevant people.

If you’re trying to engage with an agency, you tend to let them come to you. By sharing tenders of work in relevant places you will get responses from agencies looking to pitch to you. This too is an involved process.

There isn’t really a clear “winner” for hiring effort, it is pain all the way down. If you iterate on your process and learn from past mistakes, you will hopefully minimise this effort with time.

Your Way vs Their Way

When you have an internal team, it is easy to dictate how things should work, hopefully your team has a well communicated way of working and new hires will get onboarded within that.

With contractors you can often ask the same, however depending on the length of the contract you might not want to give them a full onboarding in leiu of letting them crack on, it very much depends on the context of the project.

With agencies you normally end up adopting their ways of working, which can be jarring, especially if working with several agencies at once on different projects.

Something worth discussing at this point is internal training.

Employees can be trained all day every day; if you want to send them on a three week training session; fill your boots!

Freelancers really can’t; in the UK at least they can get into some weird positions if a company they are billing as a freelancer is training them. HMRC may see that as being treated like an employee.

I’m unsure of the legal position of training a group of folk from an agency; I’d imagine it would be less weird, but would get very expensive very quickly.

Flexibility

Teams are more than a collection of job titles; sometimes you need people to be flexible beyond their job title.

Now I’m not advocating for one second that people should take on additional responsibilities without adequate compensation, but what I mean is sometimes you don’t need a developer; you need a human to bounce ideas off.

Employees will always be the most flexible; because at the end of the day they are getting paid the same regardless of task.

Freelancers will be a lot more cautious; even on a day rate there can be questions raised when time is spent doing things not strictly agreed by contract.

With the best will in the world, agencies will be terrible at this. Whilst they have access to a lot more people, having to balance time sheets at the end of a project makes flexibility hard.

The Ruby way (or development consistency)

In some other languages and communities I’d have a lot more to say about the benefits of consistent approaches to development.

I don’t want to say it is a solved problem in the Ruby world, but I can say it is way less of an issue.

The vast majority of Ruby projects I’ve been involved in have had similar shape and feel to each other.

If anything, agencies might be your best bet if you value consistency through a new project; their internal team will have already had to work out ways of collaborating together on projects. As I say though, less of an issue with Ruby than other languages.

Conclusion

Hopefully this article has helped shape some thinking you might need to do when considering taking on a new developer.

It isn’t easy, you will make mistakes. Hopefully with this article they will be educated mistakes!