What to ask a freelance developer before hiring them
Hiring a freelance developer for the first time is hard. You don't know what you don't know. Most founders ask about price, availability, and which frameworks the developer knows. Those questions are useful but they're not the ones that separate a good hire from a disaster.
Here are the questions I'd ask if I were on the other side of the table.
"Can you show me something that broke and how you fixed it?"
Any developer can show you a polished portfolio. What you want to see is how they handle problems.
Bad answer: "Everything went fine on that project." Good answer: A specific bug, a specific moment of confusion, a specific decision that didn't work, and what they did about it.
The best developers I know are obsessive post-mortem writers. They document what went wrong and why. If someone can't give you a clear example of a failure and what they learned from it, they're either inexperienced or not being honest with you.
"What happens if the scope changes mid-project?"
This question has no wrong answer — but the answer tells you a lot about how professional the developer is.
You want to hear: a clear process. Change requests go through a defined step. New scope gets a new quote and explicit approval before it gets built. Nothing ambiguous.
If the answer is "we'll figure it out", that's a red flag. That's how you end up with an invoice 60% over budget and no clear explanation.
"Who owns the code when the project is done?"
The correct answer is: you do.
Some freelancers, especially those using templated setups or licensed components, retain partial rights or create dependencies that lock you in. You want full ownership of everything — every line of code, every database schema, every deployment configuration — handed over cleanly at the end.
Ask for this in writing before you start.
"How do you handle communication during the build?"
Silence is the most dangerous thing in a freelance engagement.
You want to hear: weekly updates, async by default, a staging environment you can access at any time, and a clear escalation path if something is blocked.
What you don't want: "I'll send you the finished product when it's ready." That's how you end up with six weeks of silence followed by something that doesn't match what you imagined.
"Can I speak to a previous client?"
A confident developer will say yes immediately.
This doesn't mean you have to make the call. But asking reveals something: if the developer hesitates, deflects, or says their previous clients "prefer to stay private", that's worth noting.
References don't have to be formal. A LinkedIn message to someone who worked with them is enough. You're not looking for a glowing review — you're looking for a real human who confirms the person exists and delivered what they said they would.
"What would you do differently if you were me?"
This is the most underrated question on the list.
You're hiring someone who has built similar things before. They have opinions about what works and what doesn't. If they're good, they'll push back on parts of your brief — not to be difficult, but because they've seen that approach fail before.
A developer who just says "sounds great, let's start" is either overextended, underqualified, or not paying attention.
The best working relationships I've had with clients started with a version of this question. It turns the dynamic from "I tell you what to build" to "we figure out the right thing to build together." That's where good products come from.
The right developer for your project is not necessarily the cheapest or the fastest. It's the one who asks you hard questions back.
If the person you're evaluating only talks about their skills and their rate, keep looking.