Questions to Ask Before You Hire a Freelance Dev

Most of the hiring advice out there is written for the freelancer, not the client. This is the other side of it — the questions I'd want a client to ask me, and the ones I think actually separate a good hire from a project that quietly goes sideways three weeks in.

Ask to See Real, Shipped Work — Not Just a Portfolio Page

A polished portfolio site is easy to build. What's harder to fake is a live product doing real work for real users. Ask for links to things that are actually deployed and running, and ask what specifically the developer built versus what they inherited or lightly modified. A confident answer to "what part of this was you" tells you more than the portfolio itself does.

Ask How They Handle a Bug After Launch

Every project ships with bugs — that's not a red flag, it's software. What matters is what happens next. Does the developer have a support window built into the quote, or is post-launch support a separate, undiscussed cost that shows up as a surprise? I say this upfront on every project specifically so there's no ambiguity later: what's included, for how long, and what counts as a bug versus a new feature request.

Ask What Happens If the Scope Changes Mid-Project

Scope almost always changes a little — new requirement surfaces, a feature turns out to be more involved than expected. The question isn't whether that will happen, it's whether there's already a clear process for it: is it a conversation and a revised estimate, or does it turn into scope creep nobody agreed to? I'd want to hear the developer describe this process unprompted, because it tells you they've been through it before and have an actual answer, not an improvised one.

Ask About Communication Cadence, Not Just Availability

"I'm available" isn't the same as "you'll know what's happening." Ask how often you'll hear from them, in what form — async updates, a call, a shared board — and how they'd flag a delay before it becomes a missed deadline. The specific cadence matters less than whether they have one at all.

Ask a Technical Question You Actually Understand

You don't need to be technical to evaluate a developer, but you can still ask something grounded in your own context: "why would you choose X for this over Y," referencing something specific to your project. You're not grading the technical correctness — you're listening for whether the answer connects back to your actual business problem, or whether it's a generic answer that would apply to any project.

A Green Flag Worth Watching For

• They push back, gently, on part of your idea if they think it adds cost without adding value
• They ask about your users or business goal before jumping to a technical solution
• They're specific about what they don't know yet, instead of promising certainty on everything upfront

Takeaway

The strongest signal isn't a portfolio or a rate — it's how clearly someone can talk about the parts of a project that go wrong, because those are the parts that actually determine how the engagement feels six weeks in. Ask about bugs, scope changes, and communication before you ask about price, and you'll learn more about who you're hiring.