We’ve all heard the story:

You’ve got a great idea for the next billion dollar company and maybe even some respectable domain expertise to back it up, but you need a prototype built in order to gain traction and attract investors and you have no idea how to code it yourself.

Your options are:
1)      Find a CTO
2)      Learn to code yourself
3)      Hire developers to build your prototype

Here are the well-known challenges with each:

1) Find a CTO
Welcome to the club. Everyone is looking to find a CTO. The supply is scarce and the demand is high, so you’d need to be quite impressive or quite connected to make this happen. Good luck.

2) Learn to code yourself
There’s been a trend of non-technical founders learning to sling code, which is totally awesome. The only catch is that if you’re building anything remotely complex, this will take a very long time and lead to hours of frustration. If you have a day job, say goodbye to your nights and weekends.

3) Hire freelance developers
This costs money that you’re probably averse to spending, otherwise you would have already hired someone to get your prototype built during the months you’ve spent either searching for a CTO or trying to become your own technical co-founder.  Also, your idea will probably change substantively in your early days, so why get something built if you might just throw it away?

So when does it make sense to outsource your development?

We can agree that finding a CTO is ideal and that learning to code never hurt anyone, but these are not always viable options for you. When should you just break down and hire a consultant already?

1) When you can afford it, because money is fungible but time is not

If you’re lucky enough to have a flexible budget, I recommend you start searching for outsourced development options alongside your search for a CTO. The time it takes to find a good CTO is totally unpredictable, but you can find a reputable development firm fairly quickly by asking your friends for recommendations or googling for firms and evaluating their portfolios and references. This way, you’re getting technical advice and feedback early on, which can help you shape your requirements for a future CTO. Developers also like to hang out with other developers, so you’re opening up your search network by building relationships with freelancers. Finally, if you’re operating in a competitive space, any delay in your launch may hurt your chances of being the first-mover in a market.

2) When you’ve done enough customer research to know that your idea is worth building

A simple example is if you’ve created a basic landing page to pitch your core value proposition and managed to collect a large number of interested users. You’re reasonably sure at this point that your idea has potential, but most investors won’t fund you unless you have a prototype out there with REAL users, not just prospective ones. Another example is if you’ve consistently received a feature request from clients and thus have a customer base that is willing to pay for a solution.

3) When you have a very strong vision for the product experience

You don’t need to be a UX expert to spec out your ideas (although it definitely helps). A quick search on Google will point you to a number of tools you can use for rapid prototyping or charting of user flow. You’ll work most efficiently with freelancers if you can be clear and concise about your features and functionality. If you can, aim to spec out all your use cases along with all the screens and transitions you want in your prototype.

Common mistakes to avoid

Since starting Xanadu, a mobile design and development consultancy, my co-founder and I regularly get project inquiries from startups and have heard all their horror stories from previous outsourcing experiences. We see plenty of common mistakes that startups make that savvier clients don’t. Here’s what you should avoid:

1) Poor understanding of the development lifecycle (and thus development costs)

Building a great product typically consists of three major phases: requirements gathering, development, and testing/polishing. Requirements usually take up 10-15% of total project time, but testing and polishing can take 20 – 70% of your developer’s time. Unexpected issues almost always come up with development, especially if you’re trying something new, so be sure you set your expectations and your budget accordingly.

2) Fixating on low hourly rates rather than total costs

Top-notch developers in NYC go for anywhere between $100 – $300 / hour, possibly more if you’re creating a high-profile branded product. Decent offshore developers and local ones with less experience go for $20 – $100. You can definitely find good developers at cheaper rates, but the challenge is you usually need to do a lot of research or just happen to know the right people to get a good deal. Chances are, you’ll spend many hours vetting developers in order to filter out the ones that suck. Worst case, you’ll hire one and spend a lot of money before you realize they’re not a good fit. Experienced and proven developers work faster, produce more maintainable code, and design more scalable architectures than inexperienced ones do, leading to lower total costs in the long run. They’re also going to be better at offloading technical knowledge to your future CTO.

3) Expecting to get a reasonable quote with vague information

We get requests for ballpark estimates all the time. The requester will say something like “We’re looking to build a consumer-facing iPhone app that uses location-based search. How much will that cost us?” Well, without any information, it could cost anything from a few thousand to a few hundred thousand. While it’s reasonable to want to do broad-based cost research or to protect your idea from theft, realize that any quotes you receive without fully sharing your technical spec need to be taken with a huge chunk of salt. Remember, development costs are hard to estimate even when you have all the information!

4) Not differentiating between a Minimum Viable Product vs. a Minimum Desirable Product

The purpose of a minimum viable product is to allow you to test basic assumptions you have about your customers and your business models. It can be tough to figure out the exact features you need to include, but a common pattern we’ve seen is that people tend to focus on the “minimum” and not on the “viable”. Sure, some ideas are simple enough to build an MVP for in a weekend hackathon. Others, such as games or productivity tools, require a more fleshed out user experience and thus more time for prototyping. Be very clear to yourself on what features are required to adequately test your assumptions. Otherwise, you’ll find that you keep adding features to the project, which can quickly drive up development costs.

5) Picking generalists over specialists

While a great developer can code in anything, most only have the time to develop expertise with a few specific languages, frameworks, or tools. With a CTO, you might want someone who’s technically flexible so he can handle all the pivots your startup is likely to go through.  With a freelancer, you should be looking for someone who’s built something similar to what you want. There’s a good chance for code overlap with one of their previous projects and they should hopefully be well versed in common pitfalls unique to your situation.

Related posts:

1. Making the Transition From a Business Founder to a Technical Founder
2. A Weekend Experiment with The Lean Startup – Part 2: “We did more of a jumpstep than a pivot”
3. The Lean Adwords Way
4. How to Find a Cofounder
5. Producing PeerAround: Lessons from Startup Weekend