How to Choose a Web Development Agency: 8 Questions That Actually Matter

A strong portfolio confirms a team has shipped work you'd be happy to put your name on — what we offer covers ecommerce, custom software, AI, and design, each with portfolio examples. But a portfolio doesn't tell you how they handle scope creep, what happens when a sprint runs long, or whether the person who built the showcase project will be on your account.

Portfolio reviews are a necessary starting point — they filter out teams whose aesthetic sensibility is genuinely misaligned with yours, and they give you a basis for a conversation about approach. But they're a weak signal for project outcome. The projects in a portfolio represent the best work a team has shipped, selected and presented to appeal to prospective clients. They don't represent the average project. They don't show you the projects that ran late, the clients who were difficult to work with, or the technical decisions that seemed right at the time and created maintenance problems two years later.

A useful reframe for a portfolio review: instead of asking 'do I like this work?' ask 'do I understand why they made these specific choices?' A team that can explain the reasoning behind a specific layout decision, a particular technology choice, or a specific information architecture is a team that made those choices deliberately. Deliberate choices, even ones you'd have made differently, are a much better signal than aesthetically pleasing output whose reasoning nobody can articulate.

Some agencies sell via senior leads and deliver via junior contractors. Ask directly: who will be working on this project day-to-day, and what's their background? A team that can't answer this clearly is telling you something.

The answer to this question reveals more about an agency's operating model than any other single question. An agency that routes all new business through a senior director or CTO, then hands the actual build to a team of developers you've never met, is a different product from an agency where the person doing your initial discovery call is also writing your code.

Neither model is inherently wrong. A larger agency with a defined production process can deliver consistent quality at scale. But if you're choosing a smaller agency specifically because you want direct access to the people building your product, you should verify that's what you're actually getting. Ask to meet the specific engineers and designers who will work on your project before you sign anything. Ask whether those people will be on your project for its full duration or whether staffing is fluid based on team capacity.

For complex or technically demanding projects, also ask about the depth of experience in the specific technologies your project requires. 'We've done React projects before' and 'we've built three multi-tenant SaaS platforms in React with the specific architecture your project needs' are different answers.

Scope change is inevitable. The question is whether the agency has a defined process for it — a change-order system, honest re-estimation, and a clear conversation — or whether it gets absorbed silently until it causes a delayed launch.

Every project has scope change. The business environment changes, a competitor launches something new, a key stakeholder joins and brings different priorities, the initial assumptions turn out to be wrong. An agency that pretends scope changes don't happen is either inexperienced or not being straight with you.

What you want is an agency with a transparent change management process. When scope changes — and it will — you want to know about it immediately, understand the cost and timeline implication, and make an informed decision about whether to proceed, deprioritise something else, or accept an extended timeline. What you don't want is an agency that absorbs scope changes silently, works overtime to stay on schedule, and delivers on time but with features that are half-baked because the team ran out of hours.

The question to ask: 'Give me an example of a project where the scope changed significantly mid-build. How did you handle it, and what was the outcome?' A good answer describes the specific change, the specific conversation, and the specific resolution. A vague answer about 'being flexible' is a signal that the team doesn't have a defined process.

Code ownership, documentation, staging environment access, and credentials should all transfer cleanly at project close. Ask for this in writing before signing anything.

This is a question that reveals a lot about an agency's confidence in their own work. An agency that builds on proprietary frameworks, hosts your site on infrastructure they control, or retains code ownership for any reason is creating a dependency that limits your future options. You should own your code, your domain, your hosting environment, and your credentials from day one.

At project close, the handover should include: the complete codebase in a repository you control, deployment documentation that explains how to rebuild the environment from scratch, admin credentials for every third-party service used in the project, and a handover call where the team walks through the architecture with whoever is responsible for maintaining the project going forward.

Also ask about post-handover support specifically: for how long, at what level, and at what cost. Most projects have bugs or unexpected behaviours that surface in the first 30 days of real usage. A support window that covers this period is standard and reasonable. An agency that provides no post-launch support, or charges standard rates for every bug fix, is placing all the risk of implementation quality on the client.

Most things that need fixing appear in the first 30 days of real traffic. An agency that disappears after launch isn't actually done. Ask what the support arrangement looks like — retainer, ad-hoc hours, or SLA — and what their typical response time is.

Post-launch support availability is the most reliable leading indicator of agency quality. A team that builds with care knows that real-world traffic will surface edge cases that weren't caught in testing. They expect to be available for a support window and plan for it. A team that treats project close as a clean handoff and expects the client to handle everything that comes next is either very confident in their testing (warranted only if the QA process was rigorous) or doesn't expect to hear about problems (not a good sign).

The specific support arrangement matters less than whether one exists and whether it's documented. A two-week intensive support window with same-day response SLA is better than an open-ended 'reach out if you have issues' with no defined response expectation. Ask for the support terms in writing as part of the project agreement.

A reference from a client who ran a two-week landing page build won't tell you much about how the agency handles a 12-week ecommerce rebuild. Ask for references from projects that resemble yours in scope and complexity.

The most useful reference conversation asks three specific questions: Did the project deliver on time and on budget? If not, what happened and how did the agency respond? And would you hire them again, specifically for a project of the same type and complexity?

The third question is the most important. Many clients would hire an agency again for simple work even if a complex project went poorly. What you want to know is whether clients who ran a project like yours — complex, multi-phase, significant budget — came out of it wanting to continue the relationship.

Weekly video call, async Slack, shared Notion board, or a mix — there's no universally right answer, but a team that can't describe its communication cadence probably doesn't have one.

Communication cadence is a proxy for project management maturity. An agency with a defined process — weekly sprint reviews, a shared project board with status updates, a defined escalation path when something is blocked — is a different experience from an agency that sends updates when they remember to.

Match the communication style to your own working preferences. If you need to be closely involved in every decision, an agency with a highly collaborative process is right. If you prefer to set the brief and see the result, an agency with a more autonomous process works better. Neither is better in the abstract — the fit is what matters.

A cheaper quote from a team you can't evaluate is a more expensive outcome than a fair quote from a team with a clear process. Get the process right, then compare on price. If you'd like to evaluate us against that standard, get in touch and we'll walk through how we work before any commitment is required.

This is counterintuitive in a market where RFP processes often start with a budget ceiling and filter from there. The problem with price-first filtering is that it selects for teams who are either very efficient (which is good) or who have underestimated the scope (which is common) or who will cut corners under budget pressure (which is the worst case).

Price is a valid input after you've filtered on process, verified who does the work, confirmed the post-launch support terms, and spoken to references from comparable projects. At that point, the price difference between the remaining options reflects real differences in team capacity, experience level, and margin — all of which are assessable. Before that point, price is noise.