What to look for in your first developer (beyond technical skills)
Lee Conlin
Head of Engineering
Here's a scene we see all the time. A founder has a genuinely good idea - validated, thought-through, ready to build. So they go looking for a developer. And because they're not technical themselves, they do what feels logical: they look for the most technically impressive person they can find (or afford). Someone with a CV full of languages and frameworks they don't fully understand. Someone who sounds like they know what they're doing.
Six months later, they've got something that technically works but doesn't solve the actual problem. Or worse, they've got nothing at all - just a Slack channel full of updates they couldn't really parse and a bill that makes their eyes water.
So what went wrong? Usually, it's not the code. It's the conversation.
When you're a non-technical founder, there's a temptation to treat your first developer like a translator. You describe the thing, they build the thing, everyone's happy. But that's not how good products get built - especially early-stage ones where the idea is still taking shape.
What you actually need is someone who'll push back on you. Someone who asks why before they ask how. Because at this stage, the biggest risk isn't that the code is messy. It's that you build the wrong thing entirely.
Technical skills are table stakes. What you really need is someone who communicates clearly and gives a damn about your problem.
A developer who's brilliant but can't (or won't) explain what they're doing in plain English is going to leave you flying blind. And flying blind when it's your money and your idea? That's a recipe for anxiety, scope creep, and decisions made by default rather than by design.
Most hiring advice for developers focuses on technical assessments, GitHub profiles, and years of experience. That stuff matters, but it's not where non-technical founders tend to come unstuck. Here's what to watch for instead:
1. They only ask about the spec, never about the problem. If your developer's first instinct is to ask for a detailed brief rather than to understand your users, your market, and what you're actually trying to achieve - be cautious. Good developers are naturally curious. They want to know who this is for and why it matters, because that context shapes every technical decision they make. A developer who just wants to be told what to build is a pair of hands, not a partner.
2. They can't explain their thinking without jargon. "We'll use a microservices architecture with a GraphQL layer and deploy on Kubernetes." Great. But what does that mean for your timeline, your budget, and your ability to change direction in three months? If they can't answer that in plain language, it's not a knowledge gap on your end - it's a communication gap on theirs.
3. They say yes to everything. This one's counterintuitive, because a developer who agrees with all your ideas feels reassuring. But it shouldn't. Early-stage products need someone who'll say "you don't need that yet" or "there's a simpler way to test that assumption." A good developer protects your time and budget, even when you haven't asked them to.
4. They go quiet between deliveries. You shouldn't need to chase your developer for updates. Regular, clear communication - even when the news is "I'm stuck on something and here's what I'm doing about it" - is a sign of someone who respects the relationship, not just the work.
The best first developer you can work with probably won't have the flashiest portfolio. But they'll do a few things that matter far more at your stage:
They'll ask questions you hadn't thought of - not to show off, but because they're genuinely trying to understand the problem. They'll suggest starting smaller than you'd planned, and they'll explain why that's not a compromise but a strategy. They'll tell you when something is going to take longer than expected before it becomes a crisis. And they'll talk to you like a human being, not like someone reading from a technical manual.
Put another way: they'll feel less like a supplier and more like someone who's invested in what you're building.
We'd be doing you a disservice if we didn't mention this. When you're pre-funding and watching every penny - which you should be - the temptation to find the lowest-cost developer is completely understandable. But the maths rarely works out.
A cheap developer who builds the wrong thing costs you the original fee plus the cost of rebuilding, plus the weeks or months of lost momentum. A slightly more expensive developer who asks the right questions, pushes back where needed, and builds something you can actually learn from? That's the one who saves you money.
The most expensive developer is the one who builds exactly what you asked for, when what you asked for was the wrong thing.
This isn't about hiring the priciest person on the market. It's about understanding that cost and value aren't the same thing - especially when you're at the stage where every build decision shapes what comes next.
If you've read this far, you might be thinking "this is all well and good, but I still don't know how to evaluate someone's technical ability." And honestly? At this stage, you probably don't need to. What you need is to trust your judgement on the human stuff - because that's where most first hires go right or wrong.
Can they explain things clearly? Do they ask good questions? Are they honest about trade-offs? Do you feel like they're actually listening?
If the answer is yes, you're probably looking at someone worth working with. And if you want a second opinion - or you'd rather skip the hiring headache altogether and work with a team that's done this hundreds of times - come talk to us. Thirty minutes, no obligation, and you'll walk away with a clearer picture of what your next step actually looks like.
30 minutes. One conversation. No obligation.
