What to Ask Before Hiring a Web Developer

Why the Right Questions Matter

Every developer has a portfolio of their best work. Every developer will tell you they're great to work with. The standard interview process doesn't differentiate the excellent from the adequate from the problematic.

I've been on both sides of this conversation—as a developer being evaluated and as someone helping businesses evaluate developers. The questions most people ask ("What's your experience with WordPress?" "Can you show me your portfolio?") yield predictable, unhelpful answers.

We interviewed five developers. They all had great portfolios. We picked based on price. Six months later, we were rebuilding with someone else.

Marketing Director, Healthcare Company

The right questions reveal how a developer thinks, communicates, handles problems, and manages projects. These are the factors that determine whether your project succeeds—not their listed skills or years of experience.

Questions About Their Process

How a developer works matters as much as what they can build. Process questions reveal professionalism and fit.

"Walk me through how a typical project works with you, from first contact to launch."

Listen for a defined process with clear stages. Red flags: vague answers, jumping straight to building, no mention of discovery or planning.

Good answers include:

• Discovery phase to understand requirements
• Planning and documentation before building
• Regular check-ins and review points
• Testing before launch
• Training and handoff procedures

"How do you handle it when a client requests changes mid-project?"

Changes are inevitable. You want someone with a sensible process—not someone who says yes to everything (scope creep) or rigidly refuses all changes.

Good answers: "We evaluate the impact on timeline and budget, discuss options, and document any changes to the scope."

Red flags: "We just handle it" (no process) or "That's not allowed" (inflexible).

"What's your communication style during a project?"

Mismatched communication expectations cause friction. Clarify upfront.

Ask specifically:

• How often will we hear from you?
• What tools do you use (email, Slack, project management)?
• What's your typical response time?
• How do you prefer to receive feedback?

Questions About Experience

Experience questions should go beyond "how many years" to understand what they've actually learned.

"Tell me about a project that went wrong. What happened and what did you learn?"

This is the most revealing question you can ask. Everyone has projects that didn't go perfectly. How they talk about failures shows self-awareness, honesty, and learning ability.

Good answers: Specific situations, acknowledgment of their role in the problem, concrete lessons learned, changes they made afterward.

Red flags: "All my projects go great" (delusional or dishonest), blaming clients for everything (no self-awareness), can't think of anything (hasn't done enough work to have problems).

"What's a project you're particularly proud of? Why?"

Beyond showing good work, this reveals what they value. Do they mention technical elegance? Business results? Client satisfaction? Solving a hard problem?

Ideally, their pride aligns with what matters to you. If you care about business results and they only talk about code quality, that's a mismatch.

"Have you worked on projects similar to mine? What was different?"

Relevant experience reduces risk. But more important than identical projects is the ability to recognize what's similar, what's different, and how to adapt.

Someone who's built 50 identical sites may be less valuable than someone who's built 20 varied sites and can articulate why yours is unique.

Questions About Technical Approach

You don't need deep technical knowledge to evaluate technical competence. Focus on how they explain and decide.

"Why do you recommend [technology/platform] for this project?"

Good developers make technology choices based on project needs, not personal preference. Listen for reasoning tied to your specific requirements.

Good answer: "WordPress makes sense here because you need to update content frequently, your team already knows it, and the plugin ecosystem covers your needs without custom development."

Red flag: "It's what I use for everything" or inability to explain the choice.

"How do you approach security?"

Security isn't glamorous but it's essential. You want evidence of security awareness, not just "we're secure."

Listen for:

• Specific practices (input validation, authentication handling, HTTPS)
• Awareness of common vulnerabilities
• Update and maintenance procedures
• Backup and recovery processes

"How will you ensure the site is fast and performs well?"

Performance affects user experience, SEO, and conversions. It shouldn't be an afterthought.

Good answers mention: Image optimization, caching strategies, hosting considerations, performance testing, Core Web Vitals awareness.

Questions About Business Terms

Clear business terms prevent disputes later. Don't be embarrassed to ask direct questions.

"How do you structure pricing and payment?"

Understand the model: fixed price, hourly, retainer, or hybrid. Each has implications.

"Who owns the code and design when the project is complete?"

Standard practice: you should own everything you paid for. But clarify this explicitly. Some developers retain ownership and license it to you, which can cause problems later.

Clarify ownership of:

• Custom code written for your project
• Design files (Figma, Sketch, etc.)
• Content created during the project
• Any frameworks or libraries (usually remain with their original licenses)

"What happens if we need to part ways mid-project?"

Nobody wants to think about this, but you should. What's the exit clause? What do you get if the project ends early? How is payment handled?

"What's included in your quote, and what would be additional?"

The cheapest quote often excludes things others include. Common items that may or may not be included:

• Content entry and migration
• Stock photography
• SEO setup
• Training
• Post-launch support
• Hosting setup and first year

Questions About Support and Maintenance

The website launch is the beginning, not the end. Understand what happens after.

"What's your process for post-launch support and maintenance?"

Websites need ongoing care: security updates, content changes, bug fixes, improvements. Know what's offered and at what cost.

Clarify:

• Is there a warranty period? How long? What's covered?
• What maintenance packages do you offer?
• What's your response time for urgent issues?
• What happens if you're unavailable—do you have backup?

"How do you handle the handoff if we eventually work with someone else?"

Businesses change. You might outgrow a freelancer, or they might move on. A professional will have clean documentation and a smooth transition process.

Red flags: Proprietary systems that lock you in, resistance to discussing this, or no documentation practices.

Reference Check Questions

References are gold—but only if you actually contact them and ask the right questions.

Questions to Ask References:

1. "What was the project, and what was your role?" — Establishes context and confirms the reference is real.
2. "Did the project stay on timeline and budget?" — Direct question about reliability.
3. "How was communication throughout the project?" — Reveals working style.
4. "What happened when there was a problem or disagreement?" — Most revealing question.
5. "Would you hire them again?" — The ultimate test.
6. "Is there anything you wish had gone differently?" — Permission to share concerns.

Don't just check references—check the right references. Ask for contacts from projects similar to yours, and from projects that had challenges. Anyone can provide happy references; how they handled difficult situations matters more.

Red Flags to Watch For

Sometimes the best decision is walking away. These warning signs suggest trouble ahead.

More Red Flags:

• Pushes a specific platform regardless of your needs—they may only know one tool
• Reluctant to put things in writing—contracts protect both parties
• No examples of recent work—what have they been doing?
• Badmouths previous clients—you'll be the next story they tell
• Wants full payment upfront—standard is milestone-based

Making the Decision

After interviews and reference checks, how do you decide?

Create a Scorecard

Rate each candidate on the factors that matter to you:

• Relevant experience (similar projects, technologies)
• Communication quality
• Process and professionalism
• Cultural fit
• Price and value
• References and reputation

Trust Your Gut—But Verify

If something feels off, it probably is. But also recognize that the most polished presenter isn't always the best developer. Substance over style.

Consider a Small Test Project

If you're uncertain, offer a small paid project as a trial. A few hundred dollars to test the working relationship is cheap insurance against a five-figure mistake.

We were torn between two developers. We hired both for small projects. One delivered on time with great communication. The other missed deadlines and was defensive about feedback. Easy decision after that.

Startup Founder