Questions to Ask Before Hiring a Web Developer

A Calgary restaurant group hired a development agency two years ago to rebuild their website. The agency had a beautiful portfolio, a slick sales process, and a quote that came in right at budget. Six months later, the project was three months overdue, $8,000 over the original estimate, and the restaurant group still couldn't update their own menu. When they finally launched, the site scored 34 on Google's PageSpeed test, had zero alt text on any image, and was built entirely inside a page builder that locked them into that agency for every future change. Switching developers meant starting over.

They'd asked the wrong questions.

This happens more than anyone in our industry wants to admit. A 2025 Clutch survey found that 81% of small businesses have redesigned their website at least once—and from what we've seen, a significant number of those redesigns happened because the first build went sideways. Not because the business outgrew the site. Because the developer wasn't the right fit.

We're going to walk through the specific questions that would have saved that restaurant group six months and $8,000. Some of these questions will make developers uncomfortable. Good. And yes—we're a web development consultancy ourselves. These questions work on us too. We'd rather you ask hard questions upfront than find out the answers the expensive way.

"Can you show me a site you built that's similar to what I need?"

This isn't about browsing a portfolio page. Anyone can screenshot pretty websites. You want something more targeted.

Ask to see a project that solved a similar problem to yours. If you run a service business that needs to generate leads, don't let them show you an e-commerce build they're proud of. If you need a content-heavy site with a CMS, ask to see one where the client actually updates their own content—then ask how often that client makes updates without calling the developer for help.

A good answer sounds like: "Here's a physiotherapy clinic we built last year. They update their blog weekly and manage their own booking integration. I can walk you through the tech decisions we made and why."

A bad answer sounds like: "We've done lots of sites like that" followed by a portfolio page full of visual mockups with no context about the problems those sites solved.

What you're really testing is whether they think in terms of business problems or just visual design. A developer who leads with how the site looks is a designer. A developer who leads with what the site does is a problem solver. You probably need both, but the thinking should start with the problem.

"What does your process look like from start to finish?"

Every decent developer has a process. The ones who'll cause problems either don't have one or can't articulate it.

You want to hear something like: discovery, then strategy or planning, then design, then development, then testing, then launch, then a support period. The specific labels don't matter. What matters is that there's a clear sequence, you know when your input is needed, and there are defined points where you review and approve work before the next phase begins.

Red flags to watch for:

• No mention of a discovery phase. If they jump straight to "send us your content and we'll build it," they're not learning your business. They're going to build what they assume you need.
• No defined review points. You should never see the site for the first time at launch.
• No mention of testing. Testing isn't optional—it's where you catch the broken contact form, the unreadable text on mobile, the page that takes nine seconds to load on a hotel wifi connection.
• Vague timelines with no milestones. "Six to eight weeks" means nothing without checkpoints.

A process protects both sides. It protects you from scope creep and surprise invoices. It protects the developer from the dreaded "actually, can we just change one more thing" loop that turns a two-month project into a six-month slog.

"How will you handle accessibility?"

This question alone eliminates about 80% of the market. And that's not an exaggeration.

WebAIM's 2025 analysis of the top one million websites found that 94.8% had detectable WCAG failures on their homepage. Low-contrast text appeared on 79.1% of pages tested. The average page had 51 accessibility errors. The web is overwhelmingly inaccessible, and most developers have never been asked to make it otherwise.

Here's what you want to hear: they should mention WCAG 2.1 or 2.2, Level AA specifically (not just "we make accessible sites"), semantic HTML, keyboard navigation testing, screen reader compatibility, colour contrast ratios, and alt text as a standard part of their workflow—not a bolt-on. WCAG 2.2 was approved as an ISO standard in 2025, and it's the benchmark that matters for legal compliance across Canada and internationally.

A strong accessibility practice isn't just ethical. It's a liability question. Accessibility lawsuits have increased year over year, and the Accessible Canada Act is pushing federal organizations and the businesses that serve them toward compliance. If your developer shrugs at accessibility, they're building you a site with a legal blind spot.

What you don't want to hear: "We can add an accessibility overlay." Overlays are third-party scripts that claim to fix accessibility automatically. They don't. They often make things worse, and they've been the subject of multiple lawsuits themselves. If a developer suggests an overlay as their accessibility strategy, that's a walk-away moment.

The developer you hire should be able to explain what WCAG Level AA means, how they test for it, and what specific practices they follow. If they can't, accessibility isn't part of their process—it's part of their pitch.

"What happens to my site's performance after launch?"

Performance is a technical question that has a direct impact on your revenue. Google's own documentation states that sites should be secure, fast, and accessible, and they factor Core Web Vitals into search rankings. A slow site doesn't just frustrate visitors—it ranks lower.

Ask your developer what their performance targets are. If they don't have specific numbers, that's a problem. Here's what reasonable targets look like:

• Largest Contentful Paint (LCP) under 2.5 seconds—this is how fast your main content appears
• First Input Delay or Interaction to Next Paint under 200 milliseconds—how quickly the site responds when someone clicks something
• Cumulative Layout Shift under 0.1—how much the page jumps around while loading

These aren't aspirational goals. They're Google's published thresholds for a "good" user experience, documented in Google Search Central. Ask your developer if they test against these metrics. Ask what tools they use. Ask what happens if the site fails those benchmarks after launch.

A developer who talks about performance in vague terms ("we build fast sites") is different from one who says "we test every page with Lighthouse and WebPageTest, and we don't launch until LCP is under 2.5 seconds." Specifics matter.

If you want to understand these metrics in more depth, we wrote a full breakdown of what Core Web Vitals measure and why they matter.

"How do you handle SEO?"

SEO gets oversold more than almost anything in web development. You don't need an agency that promises first-page rankings. You need a developer who understands the technical foundation that makes ranking possible in the first place.

The bare minimum for a professional website build in 2026:

• Proper heading hierarchy (one H1 per page, logical H2/H3 structure)
• Unique title tags and meta descriptions on every page
• XML sitemap submitted to Google Search Console
• Clean URL structure (readable, hyphenated, no query strings)
• Structured data markup—especially LocalBusiness schema if you serve a geographic area
• Mobile-responsive design that actually works, not just scales
• Image optimization with modern formats

If your developer doesn't mention structured data or schema markup, they're behind. Google uses structured data to generate rich results and AI overviews. The businesses that show up in AI-powered search answers are the ones whose sites speak the language that machines understand. Your CMS choice also affects SEO—some platforms handle technical SEO well out of the box, while others need significant configuration. We compared the most common options in our CMS comparison guide.

What you're really asking with the SEO question is whether this developer understands how search engines read websites, or whether they just install an SEO plugin and call it done. There's a canyon between those two things.

"Who owns the code, the design, and the content after the project is done?"

This is the question that would have saved the restaurant group. They assumed they owned their site. They didn't. The agency had built it on a proprietary framework, hosted it on their own servers, and retained ownership of the custom design elements. Leaving meant losing everything.

Get this in writing before you sign anything:

• Do you own the source code? All of it?
• Can you move the site to a different host without the developer's involvement?
• Do you receive all login credentials—hosting, domain registrar, CMS, analytics, email?
• If you stop working with this developer, can another developer pick up the project without rebuilding from scratch?
• Is the codebase documented well enough for someone else to understand it?

The right answer to every one of those questions is yes. If a developer hesitates on any of them, you've found your red flag.

Vendor lock-in is one of the most common ways businesses get trapped. Sometimes it's deliberate—agencies that want you dependent on them for every small change. Sometimes it's just lazy architecture—building on tools that only one person knows how to maintain. Either way, it costs you.

Red Flags That Should End the Conversation

Some things are immediate deal-breakers. We've been building websites for 25 years, and these patterns haven't changed:

No contract or statement of work. Any developer who wants to start without a written agreement defining scope, timeline, deliverables, and payment terms is either inexperienced or counting on ambiguity working in their favour. Walk away.

They can't explain technical decisions in plain language. You shouldn't need a computer science degree to understand why your developer chose WordPress over a custom build, or why they're recommending a headless CMS. If they can't explain the "why" behind their recommendations, they either don't understand it themselves or they don't respect your ability to make informed decisions. Both are problems.

Their own website performs poorly. Run the developer's website through Google PageSpeed Insights before you hire them. If their own site scores below 70, ask yourself why you'd expect yours to do better. Same goes for accessibility—run their site through the WAVE accessibility checker. If their homepage has 30 errors, they're not building accessible sites for clients either.

They quote without asking questions. A developer who gives you a price based on a five-minute conversation doesn't know what they're pricing. They're either going to cut corners to hit that number or surprise you with change orders. A proper estimate requires understanding your business, your goals, your content, your technical requirements, and your timeline. That takes a real conversation.

They promise search rankings. Nobody can guarantee first-page results on Google. Nobody. A developer who promises rankings is either misleading you or doesn't understand how search works. What they can promise is a technically sound site that gives you the best possible foundation.

Green Flags Worth Paying For

On the other side, some signals tell you you've found someone good:

They ask more questions than you do. The best developers spend more time in discovery than in selling. They want to understand your business before they propose a solution. If the first meeting feels more like an interview than a pitch, that's a good sign.

They push back. A developer who agrees with everything you say isn't a partner—they're an order-taker. You want someone who'll tell you that the feature you're requesting will hurt performance, or that the design you like won't work on mobile, or that your timeline is unrealistic for the scope you're describing. Pushback is a sign of experience.

They talk about maintenance. A website isn't a finished product. It needs updates, security patches, content changes, and periodic performance checks. A developer who talks about what happens after launch understands this. One who disappears after handoff has set a timer on your site's shelf life.

They show you their mistakes. Ask a developer about a project that went sideways. If they can't think of one, they either haven't done enough work or they aren't being honest. The answer you want is specific—what went wrong, what they learned, and what they changed. Ours involves a migration in 2019 where we underestimated the database complexity and blew past the timeline by three weeks. We rebuilt our entire migration checklist because of it.

How to Run This Process

You don't need to interrogate every developer for two hours. Here's a realistic approach:

Start with three to five candidates. Check their portfolio, run their own site through PageSpeed and WAVE, and read their case studies if they have them. That alone narrows the field.

Have a 30-minute conversation with two or three. Use the questions above. Pay attention not just to the answers but to how they answer—are they specific or vague? Do they explain things clearly or hide behind jargon? Do they ask you questions back?

Ask for a written proposal that includes scope, timeline with milestones, specific deliverables, payment schedule, and what's explicitly not included. Compare proposals on those terms, not just price.

The cheapest option is almost never the best value. We've written extensively about why in our breakdown of what websites actually cost at different price points. But the most expensive option isn't automatically right either. What you're looking for is a developer whose process, technical knowledge, and communication style give you confidence that the money you spend will translate into a site that actually works for your business.

We build websites. We've been doing it since 2000. Every question in this article is one we've been asked—and one we think you should ask anyone you're considering, including us. The developers who get nervous when you ask hard questions are the ones who'll give you reasons to wish you had.

Sources

1. Clutch — The State of Small Business Websites in 2025
2. WebAIM — The WebAIM Million 2025 Report
3. W3C — WCAG 2 Overview
4. W3C — WCAG 2.2 Approved as ISO/IEC International Standard (2025)
5. Google Search Central — SEO Guide for Web Developers
6. Google Search Central — Google Search Essentials
7. Google — Core Web Vitals Documentation (web.dev)