I was just asked this question by a budding entrepreneur and thought it might make sense to more cohesively collect my thoughts. Unfortunately it’s a vague question, almost a poorly stated one, because I could be super cynical and respond “it depends on what you’re building” (I wasn’t told) and “any dev you can get your hands on if you’re in the Bay Area!”

Jerk responses aside, here is how I framed the problem: 1) you need to figure out what type of product you’re building and 2) you and the dev need to understand how he/she progresses through the org when it hopefully starts to scale. The below are not hard and fast rules – it’s a general guide to try to frame the selection process.

What kind of product are you looking to build?

I’d roughly break this one down into whether the product centers around a mobile app, whether it’s more of website (with mobile interface or not) or whether it’s more of a backend service, typically intended as a B2B enterprise sale. Anyone calling themselves a developer should be able to build each of these, but you’re going to get greatly varying quality levels and the turnaround time will vary a lot.

So if you’re building just a mobile app, a developer can pretty much completely punt on doing any backend work by using packaged backend services like Parse (Facebook) or at least a framework like Google Mobile Backend Starter or the open-source Helios project. You just need frontend skills in iOS (Objective C) or Android (Java) and some small appreciation for minimizing communication overhead due to sluggish cell networks. That’s what a bad to mediocre frontend dev should do to get you a v1 product. A great dev may cook up the backend themselves, but they’re probably smart enough to also use one of these packaged services. Doing so greatly reduces the amount of ops work a developer will need to do (work to just keep the servers running).

For a website, which generally will have some sort of mobile web interface as well (responsive design if you can), you need someone that can code PHP, Ruby, Python or something similar. Again, I would encourage the use of packaged services and managed infrastructure, in this case particularly Heroku. I’ve been pretty happy with the ability to scale and implement services a la carte via Heroku. It’s a whole lot easier than individually spinning up things like MySQL, Memcaches, Redis, queuing systems, SendGrid, etc. Again, a great dev might spin things up themselves, but they’re going to need to do the ops on it 24/7 when stuff goes wrong. By using a platform like this, the ops that remain are almost exclusively due to coding errors, no infrastructure outages.

Lastly, for something that is not very frontend-centric and requires a lot of backend systems, you’re really going to need a specialist. Technologies will vary. Everyone will go onto Amazon EC2 or lately Google or even Microsoft’s cloud services to host the product. Technologies to know are Java, Python, PHP and potentially even a compiled language like C/C++. But most importantly, the system’s architecture decisions will likely be crucial in the success off the product and company. In most cases, it will be much more important than for an MVP / v1 of an app or website. That in turn means you’ll likely need to host and manage your own infrastructure. And you need to find that unicorn dev who can build this. Chances are, they’re in pretty high demand and have their choice of who to work with. You’ll need to pay out (with equity).

One wrinkle in all this is if you know you’re going to need to plug into certain third-party APIs. Some like the Facebook API are very well documented and most questions a dev has are already answered somewhere. Others might be a bit more obscure and so you’ll need to see whether a dev has prior experience with this API. It might be easy to learn, but be warned that some are quite a bit harder than others if you’re not familiar or if the language of choice isn’t one of the main supported ones. This goes for a lot of the development platforms mentioned above as well.

How senior does the dev need to be and how does he/she expect to scale with the org?

Seniority in terms of experience and technical skill can bring big-time knowledge, but it can also bring lots of baggage. The baggage is the desire to work with systems and technologies that are familiar vs. using the “right” tech and learning new things. That’s the double-edged sword though: the younger dev could be more reckless, use some cool new language and suddenly you can’t hire anyone who can code in that language. The more senior dev might use the wrong pieces to build your product and it will be highly inefficient.
Therefore, I suggest you make it clear that standard languages and tech need to be used to get the product out the door, regardless of how junior or senior the dev is. This will mean quicker go-to-market, an easier to maintain product and future hires will be easy to make. Also, nobody will ever fault you for it and it will not be the reason for the failure of your company. Remove that risk – use standard stuff to start out.

That means that you should also never get caught in the “it won’t scale if we have 100k users”. Get to 75k and then start worrying about it. Get to a “high class problem” and you’ll find devs interested and vested in fixing it. This also is very much in line with “fail fast”, meaning figure out whether there’s something there before making everything totally perfect and wasting your time in doing so. You may miss the market.

The other part of seniority to consider is how the person wants to scale in the company they’re building. Will they be the CTO and stay CTO as you grow to 5, 10, 25, 50 or over a hundred people? A CTO does very different things in companies of these sizes. They rapidly go from writing code 99% of the time to being in architectural and product planning discussions 99% of the time. The person needs to want to do this and more importantly, they need to be capable of doing this.

More often than not, the first CTO end up getting pushed down the org as the company grows. That’s a humbling experience, so be ready for that conversation. You can also help yourself early on by not giving C-level titles out like warm clammy handshakes at cocktail hours. You’ll quickly be sitting in a company that has only senior directors, VPs and CXX employees and everyone thinks they’re managers, not doers. Bring people in at-level as much as you can and if they complain about their title, they’re probably not the right person for the job.

Bottom line: get the right technical skill, set expectations for the role and don’t hire entitled people, pun intended.