Bring a business goal, not a finished solution
You do not need a sitemap or a platform decision before the first conversation. It is more useful to explain what your business does, who you serve, and what the current website is not helping you achieve.
Examples of customer questions, difficult tasks, or missing information can make the starting point concrete. A potential partner should be able to connect those needs with the work being proposed.
Understand what the proposal includes
A website project can involve strategy, content structure, writing, visual design, development, integrations, testing, migration, and handover. Different proposals may use the same headline while including different work.
Ask what is included, what is provided by you, and what would change the scope. Discuss the pages, functionality, review stages, and assumptions rather than comparing only the total or the number of pages.
Ask how the direction will be reviewed
A clear process makes it easier to give useful feedback and avoid late surprises. Ask when you will see the structure, creative direction, and working website, and which decisions need approval.
Agree on a point of contact and how feedback will be consolidated. Ask how new requirements or additional revision requests affect the plan. A good working relationship makes those conversations ordinary rather than awkward.
Clarify ownership, access, and licenses
The finished experience may include custom work, third-party fonts, stock assets, plugins, hosting, and other services. Ownership and access should be described in the agreement.
Ask which accounts you will control, what licenses are needed, and what happens at handover. Make sure recurring services and maintenance responsibilities are understandable before the website depends on them.
Make a content plan early
Content often determines the structure and pace of a project. Existing text may need editing, imagery may need replacement, and new services may need a clear explanation.
Agree on who supplies, writes, approves, and uploads the content. If an existing website is being replaced, discuss the important pages and URLs before the launch plan is final.
Look closely at the evidence
A portfolio should explain what the team actually did. A concept can demonstrate a visual idea, while a completed project can demonstrate delivered work. Measured results need their own context.
Ask about the brief, decisions, responsibilities, and limitations. A result without a starting point or explanation may be difficult to assess. A clearly labeled smaller collection can be more useful than a large unexplained gallery.
Plan for the day after launch
Discuss how the site will be updated, who maintains the setup, and what support or training is included. Your team should understand how the finished website fits into normal operations.
Explore our approach for an example of the questions to agree together. When you are ready, tell us what you are building; a little context is enough to begin.
KEEP EXPLORING
A related perspective.
THE ENQUIRY JOURNEY
Why Your Website Gets Visitors but Not Enquiries
Explore the difference between website traffic and useful enquiries, including audience fit, clear messaging, trust, mobile usability, and form friction.
Read the perspectiveWORKING TOGETHER
What to Expect During a Website Redesign
A practical walkthrough of discovery, content, design reviews, development, migration, testing, launch, and handover during a website redesign.
Read the perspectiveYOUR NEXT HORIZON
Have a question about your own website?
Tell us what you want to improve and where you are starting from.