You do not need to understand code to hire a developer well. You need to ask questions that reveal how they work, then listen for specifics. Vague answers are information.
I am a developer, and I have been on the answering side of these questions. The list below is what I would ask if I were hiring someone to build my own product. Use it with me, with an agency or with a freelancer you found anywhere.
About the work they have done
1. Can I see something you built that is live right now? You want a real link you can open, not screenshots. Click around. Ask what they built and what someone else did. A good answer names their own part clearly. Be wary if everything is "we" and no one can say who wrote what.
2. Have you built something like this before? It does not have to match your idea. It should involve similar pieces, such as payments, user accounts or an AI feature. A good answer describes what went wrong on the earlier project and what they learned.
3. Can I talk to someone you built something for? References are normal. A developer who has only worked on personal projects can still be a good choice, but they should say so plainly instead of dodging the question.
About how they will work with you
4. How will I know how the project is going? Look for a regular rhythm: written updates, a demo on a set day, a place where you can see progress. "Don't worry, I'll tell you when it's done" is a poor answer. You want to see working software every week or sooner.
5. What do you need from me, and by when? Delays often come from the client: slow feedback, missing content, changing decisions. A developer who has run projects before will tell you what they need and the date they need it.
6. What time zone are you in, and when can we talk? Time zones are fine. Surprise is not. Agree on hours of overlap, how fast they reply, and what happens if something breaks at an awkward time. Written, async updates can work well when the schedule suits both sides.
About scope and price
7. What exactly is included, and what is not? Ask for a written scope: the screens, the flows, the integrations, and a list of things left out. If the quote is one number with no description, ask for the description before you pay anything.
8. How do you handle changes once we start? Your ideas will change. A good answer is a written process: you ask, the developer says what it costs and how it moves the date, and you approve it before work begins. A weak answer is "we'll be flexible", which tends to turn into a dispute later.
9. Is the price fixed or hourly, and what is the worst case? Fixed prices tell you the ceiling. Hourly rates suit ongoing work. If the price is hourly, ask for an estimate and a cap you both agree to.
About what you end up with
10. Who owns the code and the accounts? The answer should be you. The code should live in a repository under your name or organisation. Hosting, domain, database and payment accounts should be yours too, with the developer added as a collaborator. If the developer wants to host everything under their own accounts, ask why and ask what happens if you part ways.
11. What happens after launch? Software needs attention after it ships: bug fixes, updates, outside services changing. Ask what support is included, for how long, and what ongoing help costs. Ask also for a short written handover, such as how to deploy, where the passwords live and how to restore a backup.
12. How do you test your work, and what happens if something breaks in production? You are not looking for jargon. You are looking for a plan: they test before releasing, they get alerted when something fails, and they can roll back a bad update. A developer who has never thought about this will say so by going quiet.
How to weigh the answers
Do not look for perfect answers. Look for these signals:
- Specifics. Names, dates, numbers, examples.
- Willingness to say no. A developer who agrees to everything may not be reading your scope.
- Written follow-up. Good developers confirm what you discussed in writing.
- Comfort with questions. If you feel rushed or talked down to, expect more of that during the project.
A quick way to compare quotes
Send the same short brief to two or three developers. A brief is a page that says what the product does, who uses it, the main flows, and what you want left out. Then compare the replies on how much they asked you, not only on price. A developer who asks good questions before quoting usually builds better.
My MVP scope estimator turns nine questions into a brief you can copy and send. It needs no account.
How I answer these
Since this is my own list, here are short answers for my own work.
- I run a fixed-price Launch Sprint, USD 3,500 to 5,500 for a standard build and USD 6,500 to 9,000 with an AI feature or two integrations, over three to four weeks.
- I write the scope and exclusions before any build starts, and I ask for a USD 500 Scope & Prototype step first, credited toward the sprint if you continue within 30 days.
- Code and accounts are in your name from day one.
- You get a daily written update and a recorded walkthrough at handover, plus 14 days of bug fixes.
- I work from New Delhi, so I suit founders in the UK, Europe, the Gulf and Australia, and US founders who can use early-morning or weekend calls.
Check these against everyone else you talk to. If another developer's answers are better, hire them.
FAQ
Do I need a technical person to help me hire? It helps, but it is not required. If you know a developer, ask them to read the quote and the scope. An hour of their time can save weeks.
Should I do a paid trial first? A small paid first step is a fair way for both sides to test the fit. Unpaid trial work tends to waste both sides' time. A paid scoping step, like my Scope & Prototype, gives you a written plan and a first piece of working software.
What are red flags? No live examples, no written scope, pressure to pay everything up front, refusing to put the code in your name, and answers that stay vague when you ask for specifics.
How much should I expect to pay? It depends on scope. The cost breakdown post lists what drives the price.
Is it a problem if my developer uses AI tools? Most do now. Ask how they check the output. What matters is that someone responsible reads, tests and understands the code.
Next step
Use the MVP scope estimator to create a brief, then take it into these questions with anyone you are considering. If I am on your list, send the brief through the hire page and I will reply within one business day.