Answer-first summary
Before hiring a freelance developer, ask questions in five categories: technical fit, work process, communication, legal and ownership, and pricing. At minimum, confirm five things. Their direct experience with your specific tech stack. How they handle scope changes and delays. Who owns the code and intellectual property after payment. What their communication cadence and availability actually look like. And how pricing, revisions, and post-launch support are structured. In our experience at BLP vetting developers for client projects, skipping any one of these five areas is the single most common cause of freelance disputes — and it's rarely incompetence. It's mismatched expectations that never got surfaced before the contract was signed.
The rest of this piece breaks each category into specific questions you can ask in a screening call or written proposal request, plus what a strong answer sounds like and what should give you pause.
Technical fit questions
A résumé or portfolio site tells you what a freelancer has built before, not whether they can build what you need now. This category exists to confirm hands-on, recent experience with your actual stack (not some adjacent technology they picked up years ago), and to understand how they test and validate their own work before handing it over.
- Can you show me a live project using this specific stack or framework?
- Which parts of a similar past project did you build yourself versus adapt from a template or library?
- How do you test code before delivery — unit tests, manual QA, staging environment?
- How do you approach security basics like input validation, authentication, and dependency updates?
- What would you do differently if you rebuilt your most recent project?
Vague, generic answers here — "I've worked with a lot of different technologies" — are a cue to dig deeper. Don't assume competence by default just because the conversation felt confident.
Process and reliability questions
Technical skill doesn't guarantee a smooth engagement. A developer who codes well but vanishes for two weeks during a deadline crunch can wreck a project faster than one with a thinner portfolio ever could. This category is really about how they operate day to day, especially once things stop going according to plan.
Ask how they arrive at timeline estimates, and whether those estimates build in time for testing and revisions or just cover the build itself. Ask directly what happens if they get sick, take a vacation, or overcommit mid-project. A professional freelancer will have a real answer here, whether that's a backup collaborator, a scheduling cushion, or clear norms around communicating delays. Ask how they handle scope creep, too: do they flag it and re-quote, or quietly absorb the extra work until resentment builds and quality slips? And ask whether they work solo or subcontract parts of the project. Subcontracting on its own isn't a problem. Undisclosed subcontracting is. You're entitled to know exactly who has access to your code and data, and how openly they answer this question is a decent proxy for how they'll handle accountability later.
Communication and project management questions
More freelance engagements go sideways from communication gaps than from bad code. Before committing, find out what tools they use day to day (Slack, email, Trello, Jira, something else) and whether they'll adapt to your team's existing setup rather than asking you to adopt theirs. Ask about expected response times during business hours, and how much real-time overlap you'll get across time zones versus purely async updates.
Also ask how they report progress — daily standups, weekly written summaries, or radio silence until something breaks. This one question is often the clearest predictor of whether the engagement feels controlled or chaotic. A freelancer who proposes a reporting rhythm before you even ask has usually managed enough projects to know that silence erodes client trust faster than almost anything else, even when the underlying work is fine.
Legal, ownership, and contract questions
This category protects you long after the project wraps. Ask directly who holds intellectual property rights to the code once it's complete and paid for; the answer should leave room for no ambiguity. Ask whether a written contract or NDA is standard for them — a freelancer who treats these as optional paperwork is telling you something about how disagreements will get handled down the line. Ask what happens to unfinished work and partial payments if the engagement ends early, and how they'd want to resolve a dispute if one came up.
A written agreement covering these points is baseline for any professional engagement, not a reason to hesitate. Treat a developer's willingness to sign one as table stakes, not a bonus feature. The mechanics of what a solid freelance developer contract should include — IP clauses, kill fees, confidentiality terms — deserve their own treatment, and we cover that in a dedicated piece on freelance developer contracts elsewhere in this cluster.
Pricing, payment structure, and post-launch support questions
Money questions are where vague answers cost you the most, later. Ask whether the developer prefers hourly or fixed-price billing, and why. Both are legitimate, but the answer should fit the shape of your project: fixed-price tends to suit well-defined scopes, hourly suits open-ended or evolving work. Ask how milestone payments are structured and what triggers each one. Ask them to define, specifically, what counts as a "revision" under their quote — this is where scope disputes usually start.
Just as important: ask whether bug fixes and support after launch are baked into the original price, billed hourly, or covered under a separate maintenance agreement. Unclear post-launch terms are one of the most common sources of surprise costs in custom development work, a topic we go into further in a companion piece on budgeting for custom development, also part of this cluster.
Red flags and next steps
A handful of warning signs show up again and again across problem engagements. Worth watching for during the screening conversation itself, rather than discovering after the ink is dry on the contract.
- Vague or evasive answers about who owns the code and IP after final payment.
- No portfolio examples that actually match your tech stack or project type.
- Reluctance to put pricing, scope, or ownership terms in writing.
- Pressure to skip a formal contract or start work before terms are agreed.
If a candidate clears these questions comfortably, you're in good shape to move forward. The natural next steps: write a clear project brief that spells out scope, deliverables, and success criteria, then evaluate competing proposals against a consistent set of criteria. We'll cover both as standalone pieces in this hiring cluster, since a strong screening conversation only pays off when it's paired with an equally well-defined brief on your end.