Outsourcing is an Option
While I generally discourage outsourcing anything but the most non-core, non-strategic projects, an MVP is actually a good candidate. As my previous post (The Minimum Viable Product Dissected) mentions, you have to assume that the first few versions of your MVP will be discarded, and so you overcome a lot of the downsides of outsourcing. You don't have to worry about the quality of the code or being dependent on a third party to maintain it, and what you want is a cheap way to create something that validates your hypothesis. Depending on the scope of your MVP - and it should be small - you should be able to get an outsourced version of the product done for $2000 - $5000 which is certainly cheaper than hiring employees to develop it in house. The advantage you gain is that you're not spending precious time looking for talent when you should be validating your idea. The challenge of hiring at this early stage is that it's difficult to find people that will believe in your idea (unless you're a web 2.0 celebrity), especially since you don't even know it's good, and that will be happy working on something which will be partially or entirely discarded. David Binetti took the outsourcing route in the early stages of Votizen and was able to make several pivots with a relatively low sunk cost (see his presentation for a good case study). If you do decide to take this route, make sure that your outsourcing company has a local project manager and that they will be available for at least a few months following the MVP release to make adjustments. As long as you're given the source code you can make many of the changes yourself, and you'll no doubt have to. Expect to make adjustments to the copy and some of the graphics and layouts as you iterate and measure your AARRR metrics. This MVP will either prove that you have a strong concept or that you must Pivot. If it turns out to be the former then you can proceed to the hiring stage and begin developing a proper version of the application.
Given that you are operating as a lean startup, your workforce should be pretty lean as well. You're not working from a 500 page spec (nor should you ever), and you're not employing a waterfall methodology (nor should you ever) so it would be silly to hire 10 people and send them off to work. Although you've gotten some good validation of your idea with your early MVP, you still have to build, measure, and learn. Although you can do this with lots of people it becomes more challenging as you have to deal with the overhead of coordinating so many people as well as other reasons I'll discuss later. Generally an optimal size for a starting team is 2-3 people, one to design and two to code. An ideal situation is when the founder can fill one of these roles as well.
Hire Inquisitive Minds
As I've mentioned, at this early stage you still have a lot of learning to do so it's simply not enough to hire good designers and good programmers. You have to hire people that ask good questions. Validated learning is not something that happens at the management level - which shouldn't exist at this stage. From setting up experiments to collecting, synthesizing, and interpreting the metrics, everyone on the team has to be involved. Since the build, measure, learn feedback loop has only one "build" stage, you want to ensure that your new hires are being utilized in full. For these reasons you need to find people that ask lots of good questions during the interview process, if they're not curious about your idea and simply nod their heads in agreement, they're not for you. There are lots of great tools out there for assisting you in collecting metrics, most of which don't require a strong statistics background, but if you find someone with these skills then all the better. It is also paramount that your design hire have a good background in usability as it's more important that your application be easy to use than beautiful. Finally, returning back to lean hiring, it should now be clear that you can't keep a team of ten engaged at every stage of the feedback loop and that your agility will drop. There's also an old saying that "too many cooks in the kitchen spoils the broth", and the same applies to metrics and validated learning.
Although the above suggestions are meant to be generic, it's important that you outline your hiring criteria after each pivot as they will continually change. These changes can be anything from design style, industry knowledge, programming language, scalability experience, years of experience, to many others. This effect is further heightened once you stop pivoting and move from customer validation to company creation to company building so the hire of today won't be the same as the hire of tomorrow.
If you liked this post please follow me on Twitter for more.