Having a technical co-founder from the beginning is probably ideal, but sometimes you just haven’t found the right person yet. You could learn coding yourself, but that’ll take time, and trying to juggle the technical side together with marketing/sales is quite difficult. Your time may be better spent focusing on customer development, marketing and distribution.
I believe that hiring freelancers to build your product or MVP can work, but there are a couple of caveats. Over the past couple of years I’ve done a lot of freelancing work to cover my expenses while traveling. Most of the work I did was for startups, both because I like working with startups and due to the fact that my technical skillset (Rails, etc) seems to fit the startup world pretty well. I’ve joined existing teams working under someone else, worked individually, or worked as a project lead managing other freelancers. Here’s what I’ve have learned about hiring freelancers to build a startup.
Note: These are just my personal experiences and are not meant to be representative.
1. Do code reviews
The biggest drawback of not having a technical background is not that you cannot do the work, it’s that you can’t tell how well other people are doing their work. I’ve seen several projects where the code was a mess and the founder had no idea. Code quality matters, because very similar to how complexity incurs extra costs, messy code does as well.
Unorganized code means that every new feature of fix will take incrementally longer to implement. Messy code prevents you from moving fast, which is pretty essential for most startups. Something that I could usually implement in five minutes may take several hours if code isn’t well structured. And it only gets worse over time. Similarly, it will take a lot longer for new developers to become productive if your code isn’t organized well. Working with ugly code isn’t fun either.
Hire an expert to regularly review your code. Contrary to what you may think this doesn’t cost much. A good developer can tell “good” from “obviously bad” code in a matter of minutes. Hire a consultant for one hour and he can tell you exactly what state your code is in. That money is well spent. If you find that your developer has created a mess then you’ll have to weigh the cost of a rewrite. A rewrite isn’t always worth it and you probably should talk to someone you trust about your specific situation.
2. Hire freelancers through sample projects
Don’t trust reviews or portfolios. Developers have gotten really clever about creating fake portfolios, or signing up with multiple accounts and reviewing themselves. The best way to figure out if someone can write good code is to have him do a small sample project. That has the added benefit of making sure that communication is working well between the two of you.
Come up with a small project that can be completed in less than two hours by someone you know is a good developer. Use that as a screener for hiring a freelancer. Ideally you will have someone review the quality of the final code as described above and make your hiring decision based on that.
3. Understand that your goals are not aligned
You want to build a great business. Freelancers want to make money. They have nothing to lose if your business fails. There are exceptions and some people will genuinely care about you being successful, but generally don’t assume that to be the case.
In fact, the motivation of most freelancers directly competes with writing concise code as described in #1. To make more money, some freelancers will intentionally create code that is bloated and complex. This leads to more work (= more money), and a barrier of entry for other developers, so that you end up becoming “dependent” on that person. I’m trying to not be prejudiced, but in my experience this is most likely to happen with developers from poorer countries like India.
Again, this is something that can be solved by code reviews, but you should be aware of the possible conflict in interests at all times.
4. Make sure your developers are writing tests
A lot has been written about the benefits on test-driven development (TDD) and behavior-driven development (BDD), and you can find out more than you would ever want to know using Google. On a high-level though it means writing tests before implementing new features. This results in more upfront work, but yields a lot of benefits (cleaner code, easier review, easy refactoring, small ramp-up time for new developers, and more) down the road.
Unless you are building an MVP that you’ll throw away soon make sure your developers are writing automated tests. If you know that you will start from scratch soon you can most likely skip the tests and focus on testing your hypotheses as quickly as possible.
5. Have a good system for project management and communication in place
Communication is key for a small team, and most freelancing sites are not doing a good enough job at it. Personally I like to use a combination of Blossom and HipChat, but there are many good alternatives if you prefer something that is free. Ask freelancers to communicate daily and describe their progress in whatever project management service you are asking.
6. Hourly vs. fixed-price jobs
Most freelancing sites allow either fixed-price or hourly jobs. Which one is better?
The problem with hourly jobs is that some developers will intentionally waste time to make more money. Freelancing sites like Elance and Odesk provide time-tracking tools, but these are not really useful for monitoring how hard a developer is working. I’ve seen developers spend hours on something that shoudn’t have taken more than 30 minutes (based on the task and github commit data), and it wasn’t due to a lack of skill. There are two ways to go about this: 1. Have someone else review a freelancer’s hours and check if they are reasonable 2. Restrict hourly jobs to people you trust.
Fixed-price jobs on the other encourage developers to finish as quickly as possible. This often results in unorganized and messy code, which in turn results in a lot of maintenance costs down the road. Many developers are not willing to accept fixed-price jobs due to bad experiences. For example, I once had a client who kept requesting additional features but wasn’t willing to pay more. Worried about getting a bad review I had no choice but do either the work, or go through a lengthy dispute. I only do fixed-price jobs if I know the client well or if the project is well defined and I know exactly how long it will take me to complete.
There isn’t a clear winner between fixed-price and hourly jobs, and you should be aware of the tradeoffs.
What are your experiences with outsourcing development in a startup?