Should You Hire a Freelance Developer?

Your developer talent is directly related to the quality of your application and getting functionality out the door. A common path to quickly on-boarding new dev talent is to consider freelance developers. In this post I cover what I’ve learned about vetting and recruiting freelance developers, and when it does and does not make sense.

I address the need to hire someone outside your company, most likely part-time, to build your applications. For the purpose of this post, however, I don’t talk about the difference between on-shore and off-shore freelancers – two distinctly separate models for freelance services.

Been There Done That

Over the last 10 years, I’ve hired six freelance developers and eight full-time devs. My experience is that there are clear benefits to both formats of the role. To realize those benefits, however, it is critical to first assess your company’s work environment to determine if it is conducive to the success of freelance dev talent, or if it is more favorable to onboarding full-time employees in this role. With that knowledge, you are then ready for the secondary challenge of finding a good developer to meet your specific needs.

Most organizations neglect that first introspective step. Consequently, all too often, good talent is destined to fail simply because of a poor fit with the company’s environment. It can be challenging for even the best freelance developer to succeed if the company doesn’t provide a dev environment where they can hit the ground running.

Understand Your Developer Environment

On a fundamental level, assess the dev environment by defining primary objectives and then differentiating each as either strategic or tactical. The strategy needs to be owned by the organization, and nine times out of ten should be the responsibility of full-time members of the team. On the tactical side, a freelancer could be expected to learn the delivery chain, get briefed on the backlog, and start coding. I.e., freelance developers should be hired to execute, not build strategy.

At a more granular level, recognize the differences between development strategy, application architecture, DevOps and coding.

• Strategy: Building applications has a conceptual element. This includes how you build, and what is included in your application. Strategy is everything from feature definitions to design patterns. It requires creativity and intimate knowledge of the value your application is bringing to the user. Strategy should be conceived by those who own the application and its concepts.
• Architecture: Applications, like buildings and cars, are designed based on plans for how things should be put together. More advanced applications include complex algorithms. Architecting involves making decisions about where your application should run and if, for example, you should use microservices or not.
• DevOps: This is where your organization defines tactics for how it will deliver its application, including how its release is automated and how it’s tested. Larger organizations may also include application security. DevOps should also comprise your monitoring tools, APM tools, log analysis tools, incident response tools, etc.
• Coding: Coding is tactical, and is where a strong developer takes the requirements of functionality and turns them into code in the language specified, with the stack specified, in the process specified. This is the most tactical element of building any application, and usually does not contain much subjectivity, nor requires much creativity.

Strategy and architecture determine what your application is; it will become your core IP. DevOps is an execution component of building an application, as well as part of the delivery chain; it is inherently expected to evolve. Responsibilities in these three areas – strategy, architecture, and DevOps – are most appropriately owned and managed by staff in the company.

Involving freelancers at these levels should be avoided as it has the potential of introducing an unnecessary knowledge management challenge. A common mistake, especially by organizations with little to no application development experience, is to expect the freelance developer to take over from a strategic perspective.

Ideally, freelancers should be hired only for coding. In some cases, you might ask them to help guide the delivery chain (DevOps). They should not, however, be hired for strategy or architecture.

Setup for Success

Any developer new to the company will need to understand how to collaborate with the broader dev team; or, if there is no broader dev team, the product owners and visionaries.

An environment that is set up for success for either a new full-time developer or a freelancer will have:

• Vetted and approved dev environment and stack: You should know in advance where your application runs (e.g., AWS or Azure), what programming language you will use (e.g., Node or Go), and what your backend is (e.g., MongoDB vs Postgresql).
• Established software delivery chain and process: You should already know your desired release cadence and how you deploy and test your application. For example, do you use Jenkins for release automation? How are you testing the front-end, and running unit tests? How are you monitoring and measuring application success? The freelancer should be told how you expect them to deploy their application, not be left to decide on their own.
• Clear feature backlog: Verbally communicating the features you want the developer to create is ineffective. You should have a backlog tool that clearly defines features, with user stories that describe the features in as much detail as possible so that any dev can pick it up and know what to build.
• Clearly defined architecture and design patterns: If you have specific ways you want code written such as naming conventions, class structures, etc., you need to have those documented and clearly communicated to any new developer. A developer – even a good freelancer – can help define these, and the organization should try to establish conventions moving forward.
• Policies and security practices: Depending on the size of your organization, you may have security as well as compliance considerations that require you to have policies and security practices in place, and in a format that is easy to communicate to a new dev.

What to Look For 

A good freelance developer will:

• Be familiar with your stack: You can and should be very specific with your freelance developers. Seek people who have experience with your stack. If your application is NodeJS with a MongoDB backend, expect your freelancer to have healthy experience in both.
• Be full-stack: To be a full-stack developer means being experienced in front-end development, backend development, and (in my opinion) application testing and release automation. I.e., someone who can look at the development environment they work in, holistically.
• Be mindful of application security and quality: This goes hand-in-hand with full-stack and is very important. There are documented case studies of organizations leveraging freelance developers that take shortcuts. The most common one is storing passwords in a database clear-text (unencrypted). These types of shortcuts put the organization at risk. Your freelancers – and everyone in the organization – should be accountable for the security of what you deploy, and mindful of quality. Bad application quality and exploits will put you out of business. This is as much a technical understanding as it is a cultural alignment that you should look for even with outside contractors.

Every Company is a Tech Company

In order to compete in the modern world, every company must become a tech company. As such, they quickly identify the need to build an application, and they know its value to their users. What they often neglect to realize is that the way the application is built is as important to its success as is its core functionality.

Hiring freelancers is a great way to fast-track functionality in existing applications, build your dev resources, or get new applications into production quickly. But there are a lot of critical considerations that go into hiring a freelance dev, above and beyond just their ability to code. 

About the Author

Chris Riley is a technologist who has spent 15 years helping organizations transition from traditional development practices to a modern set of culture, processes, and tooling. In addition to being an industry analyst, he is a regular author, speaker, and evangelist in the areas of DevOps, BigData, and IT.