Hiring your first developer to help you build your company is a critical moment in your startup journey. There's a big downside risk here - the wrong choice can have big ramifications down the line, resulting in lost time, wasted effort, and potentially even taking down your business with it.
It's challenging though - how can you evaluate someone with a skill set completely foreign to you? How do you know if they are a good developer?
The easiest answer here is: have someone you trust who is technical evaluate the candidates for you.
This is a great option, but unfortunately not viable for a lot people. What happens if you don't have a network of trusted developer friends to tap?
It's tempting to dive into hiring ASAP. There's a sense in which building out the team makes this thing you're working on real. Plus, it's exciting! Seeing your vision become a reality, rallying people to your cause - this is why your playing the startup game, right?
I've got some bad news: if you're early on (i.e. pre product-market fit), this attitude is a siren song.
It's a romanticized picture that will lure you into wasting time and energy cycling through ideas and pivots and features while you burn cash.
Instead, you need to focus on how to learn as fast as possible.
90% of startup ideas out there don't need developers to get started.
I've talked with dozens of people trying to get their idea off the ground that were convinced that they needed an entire engineering team to get started, when in reality, a couple spreadsheets and some manual labor would be more than enough.
Let's look at some hypothetical examples, and show how you might get started without a developer:
You can prove out the concept before you ever write a single line of code.
This approach does a couple things:
Early on, the ideal developer candidate is one who thinks outside of just the codebase.
Some developers get into the profession because they love hard, technical problems. They want to write beautiful code that elegantly solves complicated puzzles.
You want to avoid this kind of dev.
You want to find a different kind: someone who likes writing code to solve business problems. Who likes seeing the value they create for customers. Who doesn't mind shipping slightly messy code if it means hitting the business goals.
Your first developer needs to be someone who recognizes that every line code is a liability, not an asset.
How can you assess this? Try asking open ended questions about how they would suggest building out the product.
Do they focus on technology choices ("oh I'd definitely use database X, and frontend framework Y") or on product choices ("we could probably test product hypothesis Z without even writing any code by just doing ...")?
And when it does comes to technology choices, do they rationalize their opinions with reasons why their choices would be good for the business? Or is it more about what's fun / new / exciting? For example: "I'd probably go with this new framework called FizzBuzz, it's super clean code and lightweight", vs. "I'd lean towards using Ruby on Rails - it's pretty easy to hire Rails talent, and should help us get something out the door quickly".
Keep an eye out for someone who talks a lot about scaling concerns early on. It's extremely rare that a startup needs to care about scaling early on, and it's usually a far better tradeoff to make technology choices focused on what lets you ship faster vs. scale faster.
If you really think you need developers on board now, consider contracting. You'll typically pay a premium on an hour-by-hour basis vs. a full time employee (for good devs, anyway). But the flexibility might be worth it. You can start and stop contractors, and there's no overhead of dealing with benefits and other HR concerns.
Contractors also tend to be more experienced at working with you to figure out requirements and what exactly needs to be built. Full time employees might be used to having an engineering leader above them setting priorities, roadmap, and scope; these folks can struggle when dropped into a relatively directionless, unstructured early startup.
You might think you need to hire a CTO as the first engineering hire. It has that we're-a-real-company ring, and feels like an important step.
But here's the truth: you probably don't want a CTO.
It's important to understand some of the nuance in job titles here. Silicon Valley tends to downplay their importance, but there's something here worth paying attention to.
Typically, a "CTO" is someone who specializes in running an engineering organization. They know how to balance competing priorites, how to negotiate with a VP of Sales over the product roadmap, how to hire, how to structure an engineering org, what metrics to track internally, how to watch for technology shifts on the horizon, etc.
That is emphatically not the person you need right now.
You don't need someone adept at managing and scaling organizations - you need a hustler who can ship code tomorrow.
Someone who loves rolling up their sleeves and getting in the coding trenches.
Often times, this kind of hustler is the exactly wrong kind of person to eventually become CTO. Other times, you get lucky and find someone that can grow into the CTO role as the company grows.
But the skill sets are significantly different, and it's important to set the right expectations early on.