A website redesign becomes expensive when the team starts with pages and visual references before agreeing on the business problem. The first planning document does not need to be long. It needs to make the important unknowns visible.
This guide is for founders, marketing teams and product leaders preparing to speak with a website design or frontend partner. It helps structure the conversation; it is not a fixed price or schedule for every project.
Write the problem before the page list
Describe who uses the site, what they are trying to decide and where the current experience fails. Separate evidence from assumptions. Analytics, search queries, sales questions and support conversations can reveal different parts of the problem.
- Which audience and action matter most?
- Which content is inaccurate, duplicated or missing?
- What must remain technically unchanged?
- Who approves copy, design and implementation?
- Which outcome can actually be measured after launch?
Scope content, states and integrations
A page count is not a complete scope. List reusable page types, forms, search, account states, languages, analytics, CRM or CMS connections, and the responsive behaviours that matter. Decide who supplies final copy and imagery because content readiness often controls the timeline.
Use a budget range to shape the approach
A budget range helps a partner propose the right level of discovery, custom design and engineering. Ask what is included, which assumptions affect cost, and how changes are handled. The cheapest proposal is not comparable if it silently excludes content migration, accessibility, QA or launch support.
Build a timeline around decisions
Work backward from a real launch constraint, then reserve time for stakeholder review, content production, integration testing and fixes. A responsible plan includes dependencies and owners rather than presenting one optimistic delivery date.
Compare partners using one real scenario
Ask each candidate how they would approach one important journey and one difficult constraint. Look for clear questions, relevant case-study reasoning, responsive detail and honest boundaries. If you need help turning the brief into a practical scope, review my website design and frontend development service. Website design and frontend development ↗
A short brief with explicit decisions is more valuable than a long document full of implied expectations.
When the scope is still uncertain, start with a bounded discovery phase. It should produce usable decisions—priorities, journeys, content structure and implementation risks—even if the larger engagement does not continue. Discuss a project ↗
