How to choose a web agency: 10 non-disputable criteria for a working partnership

Choosing a web agency is one of the structuring decisions of a digital project.

Comparing multiple providers remains complex. Proposals are difficult to compare, many promises, varying levels of detail...

A website is not a fixed deliverable. It's an evolving product: patches, updates, new features, regulatory requirements, security, performance.

Choose a agencyTherefore, this is not only a comparison of estimates or models. It is an assessment of the ability of a team to build a solid, sustainable and understandable foundation over time.

If you are CTO, CDP or Marketing Manager, the issue goes beyond the final rendering. It concerns the quality of the code, governance, performance, security and the ability to change the project without weakening it.

Before entering the criteria, let us set a simple framework.

What is not evaluated in a tender

In the call for tenders, the comparison naturally focuses on visible elements: budget, planning, models, technical stack.

These criteria are legitimate, but they remain incomplete.

We're talking a lot less about Maintenance (TMA), ALS, release governance, technical debt or reversibility provider.

However, over time, it is precisely these elements that structure the relationship and the actual cost of the project.

The terrain shows this regularly: a site can be delivered in time and in accordance with the specifications, while becoming difficult to evolve a few months later.

Over three years, the run is often the majority of the total cost.

This is not a supplement to the original project: it is its natural extension.

Comparing an agency is therefore not just an assessment of its ability to deliver. The aim is to estimate its ability to maintain, evolve and secure a system over time.

Here are 10 points to explore, and what it really says about a claimant.

1. Comparable (and verifiable) references

A non-comparable reference may give a false sense of security.

An SME showcase does not necessarily prepare for a complex IS.

A simple e-commerce does not guarantee the maintenance of an interconnected ecosystem (CRM, SSO, ERP, DAM...).

The most common risk: underestimation of loads and integrations.

What it is relevant to verify

• Similar projects in volumetrics and complexity.
• Comparable stack.
• Possibility of exchanging with a customer.
• Detailed cases constraints and arbitrations.
• Post-delivery indicators (stability, performance, evolution).

Low Signals

• Portfolio only design oriented.
• Refusal to detail technical complexity.
• Old or very vague references.

A case lived: a "great account reference" that turned out to be an isolated microsite, without SI integration. The target project involved SSO, CRM and multi-team workflow. Four months later, marketing comparability had shown its limitations.

2. Real internal competencies (including technical)

Why is it decisive?

If key skills are unstable or highly outsourced, quality becomes unpredictable.

Subcontracting is not a problem in itself.

The lack of transparency, yes.

What it is useful to ask

• Organization chart project name.
• Lead developer identified.
• Average old age.
• Subcontracting rate.
• Possibility of exchanging with the technical team.

Delays related to a large turnover or poorly organized subcontracting are a common scenario. Team stability is often an underestimated asset.

3. Quality & Maintenance

A poorly structured site becomes fragile.

Each evolution costs more than the previous one.

Points to be objective:

• Documented standards.
• Formal code reviews.
• Automated tests.
• AC/CD active.
• Explicit monitoring of technical debt.

A simple hand test deserves to be dug.

Expected concrete evidence:

• Capture of CI/CD pipeline.
• Static analysis report.
• Example of a requested sweater commented.
• Backlog priority debt.

This criterion conditions the ease of development. He naturally prepares the following: performance.

4. Performance & Accessibility

Performance and accessibility are not "end of project" optimizations.

They influence SEO, conversion and compliance.

Core Web Vitals (LCP, INP, CLS) are measured in real-life conditions, not only in the laboratory.

It is often more relevant to check:

• A formalised performance budget exists.
• Laboratory and production measures.
• An accessibility audit (RGAA/WCAG).
• Continuous monitoring.

A project where performance is delayed in "phase 4" frequently leads to costly arbitrations later.

Early treatment of these subjects reduces heavy corrections.

5. Security & Compliance

A security incident quickly exceeds the original cost of the project.

Without being alarmist, it is healthy to check:

• Update policy and hardening.
• Regular vulnerability scan.
• Backups tested (not only enabled).
• Documented incident plan.
• Formalized access management.

GDPR Confounding and Cookie Banner is still a common shortcut.

6. Cost transparency

An incomplete estimate often becomes a succession of amendments.

It is preferable that the explicit agency:

• Structural assumptions.
• The off-perimeter.
• Recurring costs (run, licenses, hosting).
• The recommended TMA budget.

A long-term partner helps project the cost of evolution, not just the cost of launching.

7. Governance & method

Without clear governance, decisions become diffuse.

Points to be clarified:

• RACI formalized.
• Ritual projects.
• Risk management.
• Recipe plan.
• Documentation delivered.

A method is not an absolute guarantee. But the lack of a framework makes drifts more likely.

8. Ability to manage the RUN

A site really starts to live after posting.

It is reassuring to see:

• A clear SLA contract.
• A formalized incident process.
• A structured backlog run.
• A controlled release management.
• Active monitoring.

An incident on a Friday night without a penalty quickly reminds that the RUN is an insurance, not a supplement.

9. Reversibility & Property

Changing agencies without rebuilding everything is a basic principle.

To be checked:

• Full access to rest.
• Documentation of architecture.
• Infra-as-code.
• Lack of blocker owner dependencies.
• Formalised transfer procedure.

Reversibility is not a lack of confidence.

It's a balancing mechanism.

10. Ability to challenge

A partner does not automatically validate everything.

He proposes arbitrations.

He's questioning a risky demand.

It helps to prioritize according to technical value and sustainability.

Request:

"When did you ever say no to a client?"

can be more revealing than a portfolio.

The honest shortcut to reduce risk

Choosing a web agency does not mean selecting the best presentation or the most competitive estimate. The aim is to assess the ability of a team to build a sustainable, secure and evolving system.

The criteria proposed here are not check boxes, but analytical angles to direct the discussion towards the structuring topics: code quality, governance, run, security, reversibility, ability to arbitrate.

A strong partner agrees to go into detail and take on his choices.

If some of these remain unclear in your current consultation or project, un outside look can help objectiveize risks and clarify pre-commitment arbitrations.

The goal is not to replace your team, but to secure the duration.