The questions to ask before hiring a web developer

Hiring a web developer feels a lot like hiring a builder for your house — you're trusting someone with something expensive, technical, and hard to evaluate until it's finished. The difference between a great experience and a painful one usually comes down to the questions you ask before work begins.

Here are twelve that will tell you almost everything you need to know.

Before the first call

1. Can I see examples of sites you've built?

Not a portfolio of screenshots — live sites you can visit, click through, and test on your phone. Look at how fast they load, how they feel on mobile, and whether the design looks like it was made for that specific business or could belong to anyone.

2. What's your process from start to finish?

A good developer should be able to describe their process clearly: discovery, design, development, review, launch, and handoff. If the answer is vague or starts with “we just kind of figure it out as we go,” that's a warning sign.

3. Will I work with you directly, or will I be passed to someone else?

At agencies, the person who sells you the project is often not the person who builds it. That's not necessarily bad, but you should know upfront. With freelancers, you're usually talking to the person writing the code — which means fewer miscommunications and faster decisions.

About their process

4. What do you need from me, and when?

Content, brand assets, feedback — these are the things that stall projects. A developer who outlines exactly what they need and when is someone who's done this enough to know where delays happen.

5. How will I review progress?

You should see the site in progress, not just at the end. Ask if you'll get a staging link, how often you'll see updates, and how feedback is collected. “I'll send you a link when it's done” is not a process.

6. How many rounds of revisions are included?

Unlimited revisions sounds generous until you realise it usually means the scope was never defined properly. A clear number (two or three rounds is standard) with a defined process for handling extras is healthier for both sides.

7. What happens if the project scope changes?

It will. A good developer will have a straightforward way to handle additions: a conversation about what it affects, a quick quote for the extra work, and your approval before anything changes. No surprises.

About the money

8. Is this a fixed price or hourly?

Fixed-price projects give you certainty — you know the total cost before you start. Hourly billing makes sense for ongoing work or projects where the scope is genuinely unknown, but it puts the financial risk on you. Know which model you're agreeing to.

9. What's included — and what isn't?

Hosting, domain registration, stock photos, copywriting, ongoing maintenance — these are the extras that surprise people. Ask for a clear breakdown of what's in the price and what would be additional.

10. Do I own everything when it's done?

The code, the design files, the hosting account, the domain. You should own all of it. If the developer retains ownership or hosts the site on their own account, you're locked in — and if the relationship ends badly, you could lose your website entirely.

After launch

11. What happens after launch?

Websites need maintenance — security updates, backups, minor content changes. Ask if they offer ongoing support, what it costs, and what happens if you choose to go elsewhere. A good developer will make the transition easy, not punish you for leaving.

12. What's the typical timeline?

For a small business site, four to eight weeks from kick-off to launch is typical. Anything under two weeks is either very simple or cutting corners. Anything over twelve weeks for a standard site suggests process problems.

Red flags to watch for

Beyond the questions, pay attention to how the developer communicates during the sales process. The way they treat you before they have your money is the best version of how they'll treat you after.

• Slow to respond. If emails take a week during the courtship phase, imagine the build phase.
• Can't explain things simply. Jargon is a hiding place. A confident developer can explain technical concepts in plain language.
• No contract. A handshake deal protects no one. Even a simple one-page agreement is better than nothing.
• Pressure to decide now. “This price is only good until Friday” is a sales tactic, not a business constraint. Good developers have enough work; they don't need to pressure you.
• Guarantees that sound too good. “Page one of Google in 30 days” or “triple your sales guaranteed.” No honest professional makes promises they can't control.