Hiring a developer when you can't code feels like hiring a mechanic when you can't hear the engine. You're paying a lot of money to someone whose core work you can't directly evaluate. It's uncomfortable — but it's completely doable if you know what to look for and what to ignore.
First: you're not really hiring "code," you're hiring judgment
You cannot evaluate someone's code, and you don't need to. What you *can* evaluate is how they think, how they communicate, whether they ask good questions, and whether the things they've built actually work. That's most of what separates a good hire from a bad one anyway. Great developers who make terrible product decisions have sunk plenty of startups.
Vet the work, not the résumé
A list of technologies means nothing to you, and honestly it means less than you'd think even to technical people. Instead:
- Ask to see live, working products. Not screenshots, not a portfolio PDF — real things you can open and use right now. "Show me something you built that people use today."
- Ask what their exact role was. "I built this" and "I was one of twelve people on this" are very different. Dig in.
- Ask about a project that went wrong. How they talk about failure tells you more than any success story. You want honesty and lessons learned, not blame.
Ask questions you *can* judge the answers to
You can't grade a technical answer, so ask questions where the *quality of thinking* is the point:
- "If we had to launch in half the time, what would you cut?" Good developers think in trade-offs. Anyone who says "nothing, we can do it all" is either naive or selling.
- "Explain how you'd build this to me like I'm not technical." If they can't explain it simply, either they don't understand it deeply or they'll be painful to work with for months.
- "What questions do you have about my idea?" A strong candidate interrogates the problem. Silence or instant agreement is a red flag.
- "What do you think is the riskiest part of this?" You want someone who spots landmines before they step on them.
Protect yourself with structure
Because you can't verify the work line by line, protect yourself with process instead:
- Start small. A small first paid project (or a short paid trial) tells you more than any interview. See how they communicate, hit deadlines, and handle feedback before committing to the whole build.
- Insist on working software regularly. You should see something you can click every couple of weeks — not a big reveal at the end. Frequent, visible progress is your best early-warning system.
- Get code and account ownership in writing. You must own the repository, the domain, and the cloud accounts. This is non-negotiable and it's where non-technical founders get burned most often.
- Have someone technical spot-check. Even a few hours of an independent developer's time to review the setup and code quality is cheap insurance.
The red flags that should end the conversation
- They can't show you anything live and working.
- They agree to every feature and every deadline without a single pushback or question.
- They're evasive about who owns the code.
- They can't explain their plan in plain English.
- They pressure you to sign immediately.
Any one of these is a warning. Two or more, and you keep looking.
Freelancer, agency, or studio?
Who you hire matters as much as how. A solo freelancer is cheapest but a single point of failure. A big agency has depth but overhead and layers. A small studio sits in between with senior people who both build and advise. We wrote a full guide to choosing between a developer, an agency, and a dev shop if you're weighing that decision.
The bottom line
You don't need to become technical to hire well. You need to evaluate thinking over jargon, insist on seeing real working software, start small, and protect your ownership in writing. Do those four things and you've eliminated most of the ways this goes wrong.
Want a second opinion before you hire someone — or a straight answer on what your project actually needs? Book a free call. Even if we're not the right fit, you'll leave better equipped.