Hiring a web developer is harder than it should be. The barrier to calling yourself one is basically nothing — a laptop, a GitHub account, and enough confidence to send a proposal. That's not a knock on anyone starting out; it's just the reality of the market. There's a wide range of skill, professionalism, and reliability under the same job title, and it's not always obvious which one you're talking to.

Most people find out after the fact. The project drags. Milestones get missed. The work looks nothing like the portfolio. Or it looks fine, but then the developer disappears and nobody can update a plugin without breaking the whole site.

Here's what to look for — and what to watch out for.

The red flags

They quote without asking questions. If someone gives you a firm price within the first ten minutes of a conversation, they haven't thought about your project. A real estimate requires understanding the scope, the complexity, any integrations involved, and what "done" actually means. Fast quotes are template quotes. They often come back as change orders.

The portfolio has no business outcomes. A portfolio should show more than visual design. You want to know: did it work? Did the site generate leads, increase sales, improve conversion? If a developer can only talk about how a site looks and not what it accomplished, they may not be thinking about your business — just their craft.

They say yes to everything. Ask them directly: "Is there anything this project needs that's outside your wheelhouse?" A good developer will be honest. "I can build the frontend and backend, but you'll need a separate specialist for the email marketing integration" is a better answer than "absolutely, no problem" to every question. The honest one protects your timeline and budget. The yes-person protects their opportunity to close you.

Vague or verbal agreements. If they're not putting scope, deliverables, timeline, and payment terms in writing, that's a problem. Not because developers are untrustworthy, but because memory is unreliable and expectations drift. A contract isn't adversarial — it's how two parties agree on what they're actually building. A scope of work protects you as much as it protects them — don't skip it.

No questions about maintenance and hosting. A website isn't a one-time deliverable. It needs to run somewhere, it needs updates, and at some point something will break. If a developer doesn't mention what happens after launch, ask them directly. "Who hosts this? How do I make content updates? What's the support arrangement?" If they haven't thought about it, you'll be on your own when something goes wrong.

The green flags

They ask about your business before your budget. The first questions should be about what you're trying to accomplish, not what you're willing to spend. A developer who leads with your goals is thinking about the right thing.

They tell you what they'd do differently. Show them your current site (if you have one) and ask for honest feedback. A good developer will give you specifics: "The load time on mobile is over four seconds, which is killing your SEO." "Your contact form is buried — that's why leads are low." Someone who just nods along isn't going to bring anything you couldn't have thought of yourself.

They explain tradeoffs. Scope, timeline, and budget are always in tension. A developer who can say "we can hit your deadline if we cut this feature to phase two, or we extend by two weeks and include everything" is thinking about your project, not just their task list.

They have a clear process. How do they handle revisions? What does the feedback loop look like? When do they need content from you? How are decisions made when requirements evolve? A developer with a process has done this before and knows where projects go sideways.

They push back on the timeline when it's unrealistic. If you say "I need this in two weeks" and they say "that's tight for what you're describing — here's what's realistic and here's what we could cut to hit that date," that's the honest version of project management. If they just say "sure, we can do two weeks" — that's a warning sign.

What to actually ask in the first conversation

  • "Walk me through how you handle a project from kickoff to launch."
  • "What's the most common reason a project goes over budget or timeline, and how do you prevent it?"
  • "Can you show me an example of a project similar to mine and tell me what went well and what didn't?"
  • "What would you need from me to keep the project on track?"
  • "What happens after launch — support, updates, hosting?"

You're not interrogating them. You're finding out how they think. The answers tell you more than their portfolio does.

The bottom line

A good developer is someone who makes you feel like they've done this before — because they have, and because they'll bring that experience to your project instead of learning on your dime.

They ask smart questions. They give honest answers. They put things in writing. They tell you when something won't work before you've paid to find out.

That's not a high bar. It just feels like one because the market has trained people to expect less.

You don't have to settle. If you want to have that kind of conversation about a project you're thinking about, reach out. We can figure out if it's a good fit.