The questions to ask a freelance developer before you hire fall into five groups: the work they have already shipped, how they would approach yours, how they work week to week, money and ownership, and what happens when something goes wrong. You do not need all twenty. Pick eight or ten, and listen for one thing in every answer: whether it is specific.
A good developer answers with names, dates and a story about something that broke. A weak answer sounds like a job advert. You do not need to be technical to hear that difference, which is the whole reason to ask these instead of quizzing someone on a framework you cannot judge.
These are the conversation. The checks you run on your own, like opening their links and matching the name on the invoice, are in freelance developer red flags. Do both.
How to use this list
- Ask a few in writing first. Three or four questions in your first message tells you who reads carefully. Save the rest for a call.
- Ask about their work, not their skills. "Do you know React?" gets a yes from everyone. "What was the hardest part of the app you built last year?" does not.
- Follow up once. The second question is where rehearsed answers run out. "Why that way?" is enough.
- Write the answers down. If you talk to three people, you will not remember who said what by Friday.
About work they have already shipped
1. Can I open something you built in the last year? You want a link that works today: a live site, a store listing, a tool you can sign up for. "It was for a client under NDA" is sometimes true and always worth a follow-up: can they show any of it, even a screen recording?
2. Which parts of it did you build yourself? For anything that looks like a team product, this matters more than the product. "The backend and the payments, not the design" is a good answer. "All of it", about something with a large team behind it, is not.
3. What broke after launch, and what did you do about it? Everyone who has shipped has a story. People who have only built demos have nothing, or a story about someone else's bug.
4. What would you do differently if you built it again? This tells you whether they learn from their own work. A specific regret ("I would not have written my own login system") is a good sign. "Nothing, it went well" is not.
About your project
5. What is unclear in my brief? The best question on this list. A good developer finds two or three gaps immediately, because they are already picturing the build. Someone who says it all looks clear has not read it closely, or does not want to lose the job by asking. If you have not written a brief yet, the brief builder gets you one in ten minutes.
6. What would you cut to ship this in half the time? You are not asking them to cut it. You are finding out whether they can tell the core of the project from the nice-to-haves.
7. What part of this worries you? Experienced people always have an answer: an integration they have seen go badly, a tight date, a vague requirement. "Nothing" means they have not thought about it yet.
8. Have you built something like this before, and can I see it? Not the same app. The hard part of it: payments, realtime chat, a store submission, an import from a messy spreadsheet. Matching on the hard part matters far more than matching on the industry.
About how they work week to week
9. How will I know where things are without asking? You are looking for a habit: a weekly update, a demo link, a shared board. Almost anything is fine, as long as it exists before the project starts.
10. Where will the code live from day one? The answer you want is "in a repository you own, and you will see every commit". Not a zip file at the end.
11. What hours are you reachable, and how fast do you usually reply? Time zones are workable. Unspoken expectations about reply times are not. If they work while you sleep, agree how decisions get made when they are blocked.
12. Will anyone else work on this? Some freelancers subcontract parts of a job. That is not wrong, but you should know who has access to your code and your accounts.
About money, scope and ownership
13. How would you price this, and why that way? Fixed, hourly or something in between: there is no correct answer. You want their reasoning, and you want to know what happens to the price when the scope moves. Fixed price or hourly covers the trade-off from your side.
14. What is not included in your quote? Hosting, store submission, design, content, bug fixes after handover. The gap between what you think you are buying and what they think they are selling is where most disputes start.
15. How should we split the payments? A deposit and a balance, or milestones tied to things you can open and test. If they ask for everything up front on a first job, that is a conversation, not a formality.
16. Who owns the code, the accounts and the designs when we finish? The answer you want is "you do, all of it, once you have paid". Then get it written down, because a friendly answer on a call is not the same thing as an assignment. Who owns the code explains why that matters more than it sounds.
About when things go wrong
17. What happens if you get ill or busy for two weeks? Not a trap. Freelancers get ill. What you want is a plan: early warning, code you can already see, and access you already have.
18. If I find a bug a month after launch, what happens? Some people fix their own bugs free for a set period. Some charge. Either is fine if it is agreed now rather than argued about later.
19. What happens if one of us wants to stop halfway? You want a clean exit: you pay for the work done, you get everything built so far, and nobody is held hostage by a half-finished feature.
20. Can I talk to someone you have worked with? Not every freelancer has a reference ready, especially early on, so a no here is not disqualifying. But if they have one, a ten-minute call with a previous client tells you more than the rest of this list.
What a good answer sounds like
| Topic | Good sign | Worth a follow-up |
|---|---|---|
| Past work | A link that opens, and a story about what broke | "Under NDA" with nothing at all to show |
| Your project | Questions back about your brief | "Looks clear, I can start Monday" |
| Process | A specific weekly habit | "I'll keep you posted" |
| Money | A reason for how they price | A number with no scope attached |
| Ownership | "Yours, in writing" | "We can sort that out later" |
| Problems | A plan for illness, bugs and exits | "That won't happen" |
If you only ask one
Ask number five: what is unclear in my brief. It costs a good developer nothing to answer well, it shows you how they think, and it improves your brief whether or not you hire them.
The people who ask sharp questions before they start are the same people who ask them in week three, when it actually matters.