Before hiring a freelance developer, ask who will write the code, to see live work and talk to a past client, whose accounts the code and hosting will live in, what the price leaves out, and what happens after launch. Those five answers tell you more than any question about programming languages.
Most lists of interview questions are written for hiring employees, and they focus on skills you can't easily judge if you're not technical. The questions below focus on what you can judge: past results, ownership, cost, and how the work will run. Below are ten questions, what good and bad answers sound like, what a good developer should ask you in return, how to check past work, what goes in the contract, and a message you can copy and send today. If you're still deciding between one person and a team, read freelance developer or agency first. If you're hiring someone to fix an app built with Lovable or another AI tool, there are extra questions and access steps in how to hire a developer to fix a Lovable app.
10 questions to ask a freelance developer
Send these in writing, to every developer you're considering. Written answers are easier to compare, and how someone writes tells you how they'll communicate during the project. You don't need all ten on day one. The first five decide whether it's worth a call; the rest can wait for the call itself.
- Who will write the code? You, or someone you pass the work to?
- Can I see two live projects like mine? Real sites or apps, not screenshots.
- Can I talk to one of those clients? A short call or email is enough.
- Whose accounts will everything live in? Code, hosting, domain, and services.
- What does the price include, and what doesn't it? Design, content, hosting, support.
- How is the price set? Fixed, hourly, or by milestone, and what happens if the scope changes.
- What's the timeline, and what could delay it? Including what you need from me.
- How will we communicate?Channels, reply times, and how I'll see progress.
- What happens after launch? Bug fixes, support, and what it costs per month.
- What will you hand over at the end? Access, documentation, and anything I need to run it without you.
Good and bad answers to each question
You don't need to be technical to judge these. Good answers are specific. Bad answers are vague, defensive, or missing.
| Question | Good answer | Warning sign |
|---|---|---|
| Who writes the code | "I do, all of it." Or names the other person | "Our team" with no names |
| Live projects | Links you can open, with what they did on each | Only screenshots or design mockups |
| Past client | Offers a name, or a case study with real results | Every client is "under NDA" |
| Accounts | "Yours, from day one" | "I'll host it for you" with no handover plan |
| What's included | A written list of what's in and out | "Everything you need" |
| Pricing | Explains how changes are priced before they start | A price before asking you any questions |
| Timeline | Weeks, milestones, and what they need from you | "ASAP", or a date with no plan |
| Communication | Specific channels and a reply time | "I'm always available" |
| After launch | A support option with a monthly price | "We'll figure it out" |
| Handover | Access, notes on how it works, and how to deploy | A zip file at the end |
What a good freelance developer should ask you
Interviews go both ways. The questions a developer asks you are one of the best signs of how well they'll do the job. Someone who sends a price after one message hasn't understood the project yet, and that price will change. Before I quote, I write a short brief, and to write it I need to know:
- What the business does, and what this project should change
- Who will use it, and what they need to do on it
- What already exists: a site, designs, content, a brand
- What must work on launch day, and what can wait
- The deadline, and what happens if it moves
- The budget range
- Who on your side makes decisions
- Who will update and look after it after launch
If a developer asks most of these without prompting, that's a good sign. If they skip them all, the quote is a guess. And "what can wait" matters most: a developer who helps you cut the first version down, rather than quoting everything you asked for, is saving you money. More on that in what to put in a first version.
How to check a freelance developer's past work
A portfolio shows what the work looks like. You also want to know whether it worked. Three checks take less than an hour:
- Open the live sites on your phone. Do they load quickly? Do the forms and menus work? Most of your customers will see your site on a phone, too.
- Look for results, not just pictures. Good case studies say what changed: more enquiries, faster pages, more users. On Easy Pawsy, for example, bookings went from about 20 to 120 a week. Numbers like that are easy to check with the client.
- Ask a past client three questions. Was it on time and on budget? How did they handle problems? Would you hire them again? The third answer matters most.
If you can, look at a project similar to yours. A developer who has built three booking sites will build your booking site faster than one who hasn't. You can see how I lay out mine in selected work: the starting point, the price, the timeline, and the result for each.
What to put in a freelance developer contract
The contract turns the good answers into promises. It doesn't need to be long, but it should cover these points:
- Scope: what will be built, ideally the written brief attached
- Price and payments: the total, and what each payment is tied to
- Changes: how new requests are priced and approved
- Ownership:you own the code once it's paid for, and all accounts are in your name
- Timeline: milestones, and what happens if either side is late
- After launch: any free bug-fix period, and the monthly support terms
- Ending early: what you pay and what you get if the project stops halfway
If the developer sends their own contract, read the ownership and ending-early parts first. Those are the two that cost the most when they're missing, and a fair developer won't mind you adding them. Whether a fixed price or hourly billing suits your project is its own decision, covered in fixed price or hourly.
Should you ask for a paid test project?
Sometimes. A small paid task can show you how someone works before you commit to the full project. It works best when the task is a real piece of the project, like one page or one feature, paid at the normal rate, and a few days long at most. Judge it on how they communicated and whether they asked good questions, not only on the result.
Don't ask for unpaid work. Good developers with steady clients will usually decline, so an unpaid test filters out the people you most want. And for an existing product, the most useful test isn't building something new. It's a short paid review of the current code, which gives you a written report you keep whoever you hire. For a website with clear designs and good case studies to check, a test is usually unnecessary. The past work already answers the question the test would ask.
Red flags that should stop the hire
Any one of these is a reason to slow down. Two or more is a reason to keep looking:
The last one is easy to miss, because it feels good. But a developer who never pushes back will build everything you ask for, including the parts you don't need, and you'll pay for all of it. It's also how projects end up half-finished: too much promised, too little time. The opposite, full payment up front, is a risk in the other direction: once it's paid, you have nothing left to hold the timeline to. A deposit, then payments tied to milestones, protects both sides.
A message you can send to any freelancer
Copy this, fill in the brackets, and send the same message to each developer. It gives them enough to answer properly, and makes their replies easy to compare side by side.
You can send it to me as well. Get in touchand I'll answer every question in writing, with a brief and a price range you can hold against the other replies.
