How to Hire a Web Developer: 15 Questions, 10 Red Flags and a 90-Second Test

Most bad website projects are decided at the hiring stage, not during the build. By the time a project is visibly going wrong, the decision that caused it was made weeks earlier — usually on the strength of a portfolio that looked nice and a quote that looked reasonable.

Where we sit: Webko builds websites for a living, so this is a guide to vetting people like us, written by one of them. The tests below are the ones we would want a client to run on us, and everything here works just as well as a reason not to hire us as a reason to.

The 90-second portfolio test

Do this with every candidate before you book a single call. It costs about ninety seconds each and removes most of the field.

1. Open three live sites they built — on your phone. Not screenshots, not Dribbble shots, not mockups. Live URLs. If the portfolio shows only design mockups, you’re looking at a designer, not a builder, which is a different hire with a different deliverable. If the sites are broken, slow or awkward on a phone, you have your answer already.
2. Run one through Google PageSpeed Insights. A mobile score below 50 on a recent build is a meaningful signal. You’re not looking for a perfect score — you’re looking for whether performance was considered at all.
3. View the page source. You don’t need to read code. Check whether headings use real heading elements, whether images carry alt text, and whether the page is a wall of nested generic containers. Semantic structure is a reliable proxy for craft.
4. Check the sites are still live. Portfolio links that 404 mean either the client left or the site was never maintained. Both are worth asking about.
5. Look for work of your complexity. Forty beautiful restaurant sites does not predict success on a booking platform with payment integration.

The 15 questions to ask

These fit in one structured call. The value is less in any single answer than in whether the answers are specific.

1. Can you show me three live sites you built, and your role on each?

Listen for whether they designed it, built it, or “worked on” it. Vagueness here is meaningful.

2. What would you do differently if you rebuilt your favourite project today?

Strong developers answer immediately and specifically. It reveals self-assessment, and whether their skills have moved in the last two years.

3. Which platform would you recommend for my project, and why not the others?

Be wary of anyone who recommends the same platform for every client regardless of need. That is a capability limit being sold as a preference.

4. Walk me through your process from kickoff to launch.

You want named phases, approval gates and deliverables — not “we’ll design it and then build it.”

5. Do you use a staging environment and version control?

The answer should be an immediate yes to both. Anyone editing files directly on a live site in 2026 is telling you how the project will go.

6. How many revision rounds are included, and what happens after that?

Two rounds per stage is standard. “Unlimited revisions” is either priced defensively or heading for a conflict.

7. What do you need from me, and by when?

Good developers have a clear answer: content, brand assets, credentials, a single decision-maker. Anyone who says “just leave it with us” will be waiting on you in week five and calling it your delay.

8. What exactly is included, and what isn’t?

Get copywriting, photography, SEO setup, training and post-launch support each explicitly classified as in or out.

9. What is your payment schedule?

A 30–50% deposit with the remainder at milestones is standard practice.

10. What happens if the scope changes mid-project?

You want a defined change-order process, not an awkward conversation deferred until it is expensive.

11. Who owns the code, designs and accounts when we’re finished?

The only acceptable answer is that you do. Get it in writing.

12. What documentation will I receive at handover?

Hosting details, credentials, plugin list, custom code notes, and instructions for updating content.

13. What is included in post-launch support, and what do you charge after?

A 30–90 day bug-fix window is standard. Confirm the hourly rate that applies once it ends.

14. If I want to work with someone else in two years, how hard will that be?

Watch the reaction rather than the answer. Defensiveness suggests lock-in; a straightforward reply suggests confidence.

15. Can I speak to a client you worked with over a year ago?

Recent clients talk about the build. Year-old clients tell you about support, reliability, and whether the site still works.

10 red flags

1. No written contract. Nothing else on this list matters if this one is present.
2. Full payment demanded upfront. A deposit is normal; 100% before work begins removes every incentive to finish.
3. A quote arriving without questions. Anyone who prices a website without asking about your goals, audience and functionality is pricing a guess.
4. Vague, single-line pricing. “Website — $5,000” is not a quote. Expect line items, page counts and revision limits.
5. Registering the domain or hosting in their own name. This happens more often than you would think, and it is how businesses end up hostage to a former contractor.
6. Guaranteed Google rankings. Nobody can guarantee rankings. The claim is either ignorance or dishonesty, and both disqualify.
7. Slow or unclear communication during the sales process. This is their best behaviour. It does not improve after you have paid.
8. No portfolio, or mockups only. Unbuilt designs prove nothing about whether someone can ship working software.
9. Dramatically underbidding everyone else. A quote at a third of the market rate usually means misunderstood scope, a template dressed up as custom, or a project that gets abandoned partway — what a website actually costs is the context that makes an outlier quote legible.
10. Pressure to decide immediately. Limited-time discounts on professional services are a sales tactic, not a value signal.

What genuinely qualified looks like

Credentials matter less than evidence here. There is no universal licence for web development, and self-taught developers are frequently stronger than credentialed ones. What actually predicts a good outcome:

• Live sites that load fast on a phone — the single most reliable indicator, and the reason the portfolio test comes first.
• Plain language — someone who cannot explain a technical trade-off without jargon will be hard to work with for eight weeks.
• Questions about your business, not just your taste — the good ones ask what the site has to achieve before discussing layout.
• Honest limits — “that is outside what I do well, you want a specialist” is a strong signal, not a weak one.
• Documented process — contracts, staging sites, version control, written handovers.
• Clients who stayed — multi-year relationships mean someone is delivering something worth renewing.
• Platform partner status where relevant — Shopify Partner, Webflow Expert and similar directories provide a baseline of verification.

Comparing quotes fairly

Send every candidate the same written brief. Without one you are comparing different products and concluding that the cheapest is the best value. Your brief should state your business goals and primary conversion action, an approximate page count and required functionality, whether you are supplying content and images, design expectations with two or three reference sites, your deadline and budget range, and any required integrations.

Then compare on these axes rather than on price alone:

The lowest quote is rarely the cheapest outcome. The most common expensive scenario is paying twice — once for a build that fails, then again for the rebuild. Whether you are weighing individuals or firms, which model fits your project is the decision underneath most of these quotes.

Frequently asked questions

Conclusion

Hiring well is mostly a filtering exercise. The 90-second portfolio test removes the clearly unsuitable, the fifteen questions remove the disorganised, and the ten red flags remove the risky.

What is left is a small group who could all do the job — at which point you are choosing on communication and fit, which is a far easier decision than the one you started with.

If you want to run the test on us, our work is live and the sites are linked. Or tell us about the project on the contact page and we will tell you honestly whether it is one we should be building.