What Your Web Agency Needs Before the Project Starts

Bring context, not a pre-designed answer

Clients sometimes delay contacting an agency because they believe the brief, sitemap, features, and visual direction must already be solved. That removes much of the value a capable team should provide.

The useful preparation is different. Make the business problem, audience, evidence, constraints, ownership, and existing systems visible. The agency can then turn that context into a responsible scope.

1. A reason stronger than “the site is old”

Age is not a business problem. Explain what the current website prevents or makes unnecessarily difficult.

Examples:

• buyers cannot distinguish the services;
• the strongest work is difficult to find;
• editors cannot publish without developer help;
• the brand no longer matches the company;
• mobile journeys fail or perform poorly;
• organic landing pages do not guide visitors onward;
• important systems require manual re-entry;
• the product or market has changed.

Write the reason in one paragraph and identify why the project matters now. A clear trigger helps the team decide what the new site must preserve, remove, or prove.

2. Priority audiences and decisions

“Everyone” does not give the interface a priority. Name the people whose successful visit matters most and what they are trying to decide or accomplish.

For each priority audience, provide:

You do not need fictional personas with names and hobbies. Real questions, objections, tasks, and evidence are more useful.

3. Evidence from the current site

Give the agency access to facts before asking it to change the system.

Useful inputs include:

• analytics and conversion events;
• Search Console queries and landing pages;
• CRM lead quality or sales feedback;
• support and enquiry themes;
• user research or usability findings;
• common internal complaints;
• pages with valuable backlinks;
• current performance and accessibility reports;
• editorial workflow problems.

Numbers need interpretation. A page with high traffic may serve irrelevant demand; a low-traffic service page may produce the strongest enquiries. Pair quantitative data with what sales, support, and customers actually experience.

4. Existing content and a named owner

Create a rough inventory of pages, documents, images, videos, tools, downloads, and case studies. Mark what is current, questionable, duplicated, missing, or legally required.

Then name one owner for content decisions. That person does not need to write everything. They must coordinate subject experts, consolidate review, and decide when the copy is approved.

Clarify early:

• Will the agency write, edit, or only structure copy?
• Who can approve claims?
• Which content needs legal or compliance review?
• Are photography, diagrams, or video required?
• Who handles translation?
• How much existing content must move?

Content delays are rarely caused by typing speed. They come from unclear ownership and late disagreement.

5. Brand assets and the truth about their condition

Provide the logo files, fonts, colour definitions, imagery, voice guidance, and any existing brand documentation. Also state what is working and what is open to change.

Do not present outdated guidelines as untouchable if the website project is expected to fix the brand indirectly. Decide whether the engagement is applying the identity, extending it for digital use, or redesigning it. Those are different scopes.

6. Systems, integrations, and data flows

List every system the website touches, even if the connection appears simple:

• CMS;
• CRM and marketing automation;
• analytics and consent management;
• ecommerce, payment, inventory, or booking;
• authentication and user accounts;
• product or location databases;
• search, forms, email, or support platforms;
• translation services;
• internal APIs.

For each integration, answer:

1. What data moves?
2. In which direction?
3. Who owns the external system?
4. Is documentation available?
5. Who can provide credentials and test access?
6. What should happen when it fails?

An integration named in week one can be investigated. One discovered during launch becomes a crisis.

7. Access—without sharing passwords in documents

Identify who controls the domain, DNS, hosting, current CMS, repository, analytics, Search Console, tag manager, email delivery, and third-party accounts.

Do not paste passwords into the brief or project chat. Invite named users, use a password manager, apply the least privilege required, and remove access when it is no longer needed.

Check domain ownership especially early. A forgotten registrar login can hold an otherwise complete launch hostage.

8. Constraints the team must design around

Constraints are useful when they are real and harmful when they are hidden.

Name:

• budget range;
• immovable dates and why they are immovable;
• approved or prohibited technologies;
• hosting, security, privacy, or procurement rules;
• accessibility requirements;
• browser and device needs;
• supported languages and markets;
• internal maintenance capacity;
• legal or regulatory review;
• systems that cannot change.

Separate a true constraint from a preference. “Our security team requires EU hosting” is a constraint. “The CEO likes WordPress” is a preference until a business reason supports it.

9. The decision-maker and stakeholder map

Name one person accountable for final project decisions. Then list contributors and the questions they own.

For example:

• marketing owns positioning and acquisition;
• sales owns buyer objections and lead quality;
• product owns functionality;
• engineering owns integration and security constraints;
• legal owns claims and privacy;
• leadership approves budget and strategic direction.

Not every stakeholder needs to review every screen. Broad, unstructured review produces contradictory feedback and replaces user needs with internal preference.

Agree on how comments will be consolidated and how disagreements will be resolved before the first design review.

10. Review capacity

The agency can reserve production time; it cannot approve work on the client's behalf.

Put review sessions and decision deadlines into calendars at the beginning. Ensure the people required for content, technical access, legal review, and final approval are available during their relevant windows.

If a launch date overlaps a leadership retreat, product release, annual leave period, or legal freeze, surface the conflict before the project plan assumes otherwise.

11. A first version of success

Choose a small set of signals that reflect the reason for the project.

Possible measures include:

• qualified enquiry completion;
• navigation from informational content to commercial pages;
• time required to publish a new resource;
• completion of a key self-service task;
• search impressions for an important topic set;
• Core Web Vitals by template;
• accessibility defects;
• support contacts caused by unclear website information.

Record the current baseline before replacing the site. Do not make every measure a target the agency guarantees; use the measures to learn whether the intended improvement occurred.

The pre-kickoff checklist

The project is ready to begin when these statements are true:

• [ ] We can explain why the project exists now.
• [ ] We know the priority audiences and tasks.
• [ ] We have shared current performance and customer evidence.
• [ ] We have inventoried the existing content.
• [ ] One person owns content approval.
• [ ] Brand assets and open brand questions are available.
• [ ] Required systems and integrations are listed.
• [ ] Account owners and access methods are known.
• [ ] Budget, date, technical, and legal constraints are visible.
• [ ] One decision-maker is accountable.
• [ ] Stakeholders know which questions they own.
• [ ] Review time is reserved.
• [ ] A baseline for success has been recorded.

You do not need every answer before the first conversation. Missing answers should be visible so discovery can resolve them intentionally.

Common questions