By 
Choosing a web development agency is mostly about avoiding surprises. Projects rarely go sideways because the developers couldn't code. They go sideways over scope, ownership, communication, or what happens after launch. The 12 questions below are meant to bring those issues up before you sign anything, whether you're hiring a web development company in the USA, an agency in Canada, or a team overseas.
12 questions to ask before you hire
Ask every agency on your shortlist the same questions, and pay attention to how they answer as much as what they say. Specific, unhurried answers are a good sign. Vague reassurance is not.
1. Who will actually write the code?
Some agencies sell with a senior team and deliver with a different one, sometimes subcontractors you'll never meet. That isn't automatically bad, but you should know who is working in your codebase and whether you can talk to them directly.
What a good answer sounds like: "Here are the people who would be on your project and what they've built before. You'll have direct access to the lead developer." If any work is subcontracted, they say so up front and explain who is accountable for it.
2. How do you scope the project and produce an estimate?
An estimate is only as reliable as the discovery behind it. A firm number after one short call usually means someone is guessing, and you'll pay for that guess later in change requests or cut corners.
What a good answer sounds like: They describe a discovery step, ask about your integrations, content, and third-party systems, and come back with a written scope that lists assumptions and what is explicitly out of scope. They tell you which parts are uncertain and why.
3. Fixed price or time-and-materials, and why for this project?
Both models work. Fixed price gives you budget certainty but depends on a tight scope, so changes go through formal change requests. Time-and-materials is more flexible and suits products that will evolve, but it needs visibility into hours and an agreed budget ceiling.
What a good answer sounds like: A recommendation tied to your specific project, plus a clear explanation of how changes, overruns, and approvals work under that model. Be wary of an agency that simply offers whichever model sounds cheaper on paper.
4. What does your staging and QA process look like?
You should never be the first person to discover that a feature is broken, and your customers definitely shouldn't be.
What a good answer sounds like: A separate staging environment where you review work before it goes live. Testing on real devices and browsers, not just the developer's laptop. Someone other than the original developer checking the work. Deployments through version control, not edits made directly on the production server.
5. Who owns the code, and will I have repository access from day one?
If you can't see the code while it's being written, you can't easily verify progress, and you may have trouble getting it back later.
What a good answer sounds like: "You own the code once it's paid for, and the contract says so. The repository lives in your GitHub or GitLab account, or we transfer it to you, and you can see commits as the work happens." A good agency will also point out any licensed themes, plugins, or components that come with their own license terms.
6. Who owns the hosting, domain, and third-party accounts?
Your domain registrar, hosting, Shopify store, payment gateway, analytics, and email services should all be registered to your business. The agency should be a user on those accounts, not the owner.
What a good answer sounds like: "Everything is in your company's name. We'll be added as collaborators, and at handover we'll share credentials through a password manager, not a spreadsheet in an email."
7. How will we communicate, and how much time-zone overlap will we have?
Communication problems cause more project pain than technical ones. This matters even more when your team and the developers are in different time zones.
What a good answer sounds like: A specific cadence, such as a weekly call plus written updates in Slack or email, a named point of contact, a typical response time, and the actual hours their team overlaps with your business day. "We're always available" is not an answer. A schedule is.
8. What happens after launch?
Launch is the start of the site's life, not the end of the project. Platforms update, dependencies need patches, and real users find edge cases that testing missed.
What a good answer sounds like: A defined warranty period for bugs within the original scope, followed by clear options for ongoing support, whether that's a retainer, hourly work, or a clean handoff to your team. They can tell you how urgent issues are reported and what a reasonable response looks like.
9. Can I see relevant work and talk to a past client?
A polished portfolio shows what an agency can make look good. It doesn't always show what they actually built or how the project went.
What a good answer sounds like: Case studies close to your project in type and complexity, explaining the problem, what was built, and exactly what role the agency played. Where clients agree to it, they can connect you with a reference who will talk about the working relationship, not just the result.
10. How do you handle security and accessibility?
Both tend to get treated as finishing touches, and both are much cheaper to build in than to bolt on. Accessibility is also a legal consideration, under the ADA in the US and under provincial rules such as the AODA in Ontario.
What a good answer sounds like: On security: keeping dependencies updated, least-privilege access, no secrets committed to repositories, spam protection on forms, and regular backups. On accessibility: a named target such as WCAG 2.2 AA, semantic markup, keyboard navigation, and color contrast, checked with both automated tools and manual testing. Be skeptical of anyone promising "full compliance" through a single plugin.
11. How will you protect our SEO during a redesign?
A redesign that changes URLs without a plan can quietly undo years of search visibility. This is one of the most common and most avoidable redesign mistakes.
What a good answer sounds like: They crawl your current site, map every existing URL to its new equivalent with 301 redirects, carry over page titles, meta descriptions, and structured data that are already working, and keep the staging site out of search engines. After launch, they monitor Google Search Console for crawl errors and broken links.
12. What happens if we part ways?
Nobody likes asking this at the start, which is exactly why it belongs in the conversation. How an agency answers tells you a lot about how they'd behave if things got difficult.
What a good answer sounds like: Clear exit terms in the contract: a notice period, payment for work completed, and a handover of code, credentials, and documentation. The documentation should be good enough that a new developer can pick up where they left off without starting over.
Red flags worth walking away from
- A firm quote before they've asked meaningful questions about your project.
- Reluctance to tell you who will actually be doing the work.
- Keeping your repository, domain, or hosting in their own name "for convenience."
- No staging environment, or changes made directly on your live site.
- Guarantees of specific rankings, traffic, or revenue.
- Pressure to sign quickly because a discount or opening is about to expire.
- "Yes" to every request, with no pushback on timeline, budget, or scope.
- Vague answers about post-launch support, such as "don't worry, we'll take care of you."
Onshore vs. offshore vs. hybrid: the honest tradeoffs
Where a team is located shapes the working relationship, but it predicts quality less than people assume. Here's how the options generally compare.
Onshore (US or Canada). You get a shared or nearby time zone, easier real-time collaboration, and a team that already knows your market and business norms. The tradeoff is cost: onshore teams typically charge more, which can limit how much you can build with a fixed budget.
Offshore. Offshore teams often let a budget go further, and many are excellent. The challenges are real, though. Limited overlap in working hours can turn a quick question into a day-long round trip, and communication quality varies widely from team to team. A time difference can work in your favor when work happens overnight and handoffs are well organized. It works against you when your project needs a lot of fast back-and-forth.
Hybrid. Some agencies pair a local presence with a remote development team, aiming to combine easier communication with more manageable costs. It can work well, but ask the same direct questions: where the developers actually are, who your day-to-day contact is, and how many hours of overlap you'll really get. A local phone number doesn't tell you who is writing your code.
In practice, a well-run offshore team will outperform a disorganized local one, and the reverse is just as true. The 12 questions above will tell you more than a map will.
Ask us the same questions
If you're comparing agencies, use this list on every one of them, including us. Take a look at what we build, then tell us about your project and ask any of these 12 questions. You'll get straight answers before you commit to anything, and if we're not the right fit, we'll tell you.
