You don't need to be technical to vet a developer. You need to ask questions where a vague answer is obvious even if you can't judge the code. These twelve do that. I've included what a good answer sounds like, because the wording matters less than whether the person has clearly thought about it before.
About the work itself
1. Have you done something like this before? Can I see it?
The single most useful question. Good answer: a specific comparable project, what their role was, and what was tricky about it. Weak answer: "yes, lots" with no detail, or examples that aren't really like your job.
2. How would you approach this?
You're not grading the architecture — you're checking they can explain a plan in language you understand. Good answer: a sequence of steps, plus what they'd need to look at before committing. Weak answer: jargon that doesn't resolve into a plan, or a price with no method behind it.
3. What could make this take longer than expected?
Experienced people answer immediately, because they've been burned. Good answer: named risks — an unknown API, messy existing code, waiting on your content. Weak answer: "nothing, it's simple." Everything has risks; not seeing them is the risk.
4. Is there a cheaper or simpler way to get the same outcome?
This tests whether they're solving your problem or selling their preferred solution. Good answer: honest trade-offs, sometimes talking you out of the bigger build. Weak answer: the most expensive option is always the only option.
About scope and money
5. What exactly is included — and what isn't?
Ask for the exclusions specifically. Undefined scope is the main cause of budget overruns, because every ambiguity gets settled mid-build under pressure.
6. Fixed price or hourly, and what happens if it runs over?
Good answer: a clear model, and for hourly work a cap or a checkpoint where you both reassess. Weak answer: "we'll see how it goes." See how rates and models compare.
7. How do change requests work?
You will change your mind about something — that's normal. What matters is that there's a process: how changes get priced and approved before work happens, rather than an invoice surprise at the end.
8. What's the payment schedule?
Milestones tied to delivery are healthy. A deposit is completely normal. Demanding the full amount up front, before you've seen anything, is not.
About how they work
9. Will you work on a staging site or on my live store?
One of the few genuinely technical questions worth insisting on. The answer should be a development theme or staging environment. Anyone who edits a live store directly for substantial work is telling you they'll break something in front of your customers.
10. How and how often will you update me?
Good answer: a specific rhythm — a weekly summary, a shared list, whatever. Weak answer: "I'll be in touch." Silence for two weeks is the most common complaint merchants have about developers, and it's entirely preventable.
11. Who owns the code, and how do I get it?
You should own what you paid for. Good answer: it's yours, in your repository, handed over with notes. Weak answer: code that lives only on their machine, or a licence arrangement that keeps you dependent. This is also what makes changing developers later a non-event.
12. What happens after launch if something's wrong?
Good answer: a defined period where anything not working as scoped gets fixed at no charge, then a clear arrangement for ongoing work — see retainers. Weak answer: a shrug, or every fix billed as a fresh job.
You're not testing knowledge with these questions. You're testing whether the person has done this often enough to have opinions — and whether they'll tell you an inconvenient truth before you've paid them.
One question to ask their references
If you get a reference call, skip "were you happy?" — nobody offered as a reference says no. Ask instead: "What went wrong, and how did they handle it?" Something always goes wrong. How a developer behaves in that moment is the most reliable predictor of what your experience will be.
Bottom line
Ask about comparable work, risks, exclusions, staging, updates, code ownership and post-launch support. The pattern you're looking for is specificity — precise answers, volunteered caveats, and a willingness to disagree with you. That's what competence sounds like from the outside, even when you can't read a line of the code.