How to choose a web agency — ten questions before the contract

A new website often starts with a visible frustration: the site does not convert, editors struggle with the CMS, or an old system cannot be changed. It is natural to look for a web agency with polished cases. But the most important difference rarely appears in the first screen — it appears in how the agency helps you cut scope, understand technical debt and protect ownership.

When you choose a web agency, you are really choosing a way of working. Some work best as a body shop: they deliver skills into a task you have already defined. That can be right if you have strong product leadership and internal capacity to manage quality. Other assignments need a product partner who will challenge the brief and propose a smaller solution.

This is especially important when the site connects to marketing, sales, data and integrations. The wrong partner can deliver something that looks finished at launch but becomes heavy to change. The right partner makes the first decisions clear, documents trade-offs and makes sure you own enough to act freely later.

So the question is not only how to find 'the best web agency'. It is how to find the partner who can explain when custom development is necessary, when Shopify is enough, and when a Next.js solution gives better long-term control. The advice before the code reveals whether the agency is working for your outcome or for the next delivery.

A body shop can be useful when the task is clearly described, the architecture is decided, and your team can review code and manage the backlog. In that situation you are buying capacity — and that can be efficient if the main risk is execution.

But many web projects start with uncertain assumptions: which audience matters most, which integrations are truly necessary, and which requirements are just old habits. If the agency only asks for a requirements list, you may end up paying to produce the first assumption at high quality — even though it should have been challenged.

A product partner asks what must be true for the project to succeed. They distinguish between the first version and what can wait. They explain the consequences of a headless CMS, a custom checkout or a design system — and they are willing to say that an existing platform is enough if the problem does not require custom software.

Listen to the language. Do they mainly talk about skills and staffing, or about decisions, risk and operations? Do they ask who owns the product internally on your side, and how success should be judged after launch? Those questions are often stronger signals than a long technology list.

Ownership is one of the most underestimated topics when choosing a web agency. Many conflicts happen because it was never made concrete: who owns the Git repository, hosting account, DNS, environment variables and deploy flow? Who can recreate the project if the vendor is no longer involved?

A healthy setup makes it possible for you to continue without the original vendor. That does not mean you should switch — it means the relationship is based on quality, not friction. You should be able to give a new developer access to code, documentation and environments without starting over.

When the agency owns too much, technical choices can become the vendor's business model instead of your architecture. Proprietary CMS solutions, hidden plugins and manual deploys make small changes slow. An open setup with versioned code, documented infrastructure and clear access roles gives you freedom to act.

Ask directly: do we own the code even if the collaboration ends? Can we access the repository from day one? How are operations documented? Which parts could another competent vendor take over? An agency confident in its own value rarely needs to hide the answer.

Discovery is sometimes sold as a loose workshop phase. The purpose should be to reduce uncertainty before anything is built: which user journeys matter most, which pages should be editor-managed, which integrations are critical, and what should be measured once the solution is live?

A strong discovery ends with decisions — prioritized scope, technical recommendations, a content model and a risk overview. It should also uncover where a simpler solution is better. If Shopify and a well-chosen theme solve the problem, a responsible agency should say so. Custom development is powerful, but only when the problem deserves it.

For you as buyers, discovery is a test of agency maturity. Notice whether they ask questions that make the assignment narrower and clearer, or whether they simply confirm every wish. Notice whether they can explain trade-offs in plain language, and how weekly demos work in practice.

This is also where you should get a feel for the collaboration model. Are the same people pitching and building? How are decisions handled when stakeholders disagree? Who says no when scope grows? If the answer is unclear, the risk is not only delay — it is a project without product direction.

Logos on a case page can be relevant, but they rarely tell enough. A familiar logo does not tell you whether the agency managed scope, took responsibility for technical quality or enabled the client to own the solution afterwards.

Instead, ask for references that resemble your situation in complexity — many stakeholders, multiple languages, integrations, CMS freedom for marketing, or a move away from a locked vendor. You do not need private details. You need to hear how the agency thought.

Good reference stories contain friction. They explain what was unclear at the start, which options were rejected, and how the team handled change. If every case sounds smooth, substance is missing.

Also ask who from the agency worked on the case. Some pitch with senior profiles and deliver with another team. That is not necessarily a problem — but it should be clear if you are buying advice.

The contract often reveals more than the presentation. If the agreement is unclear about ownership, handover, access or responsibility, you should pause. The same applies if scope is described so loosely that every important detail becomes a later discussion.

Pay special attention to wording that binds you to the agency's own platform without a clear reason. There can be good reasons for custom-built components — but they should be explained. If you cannot get an honest description of exit, that is a warning signal.

Another red flag is the absence of a decision process: who approves design, who prioritizes the backlog, how change requests are handled, when you see working software. If all of that has to be discovered along the way, the contract becomes a source of negotiation instead of a steering tool.

The best contract reflects a collaboration where both parties know what they own. You own business goals and decisions. The agency owns method, technical advice and delivery quality. Together you own prioritization.