A website build is expensive not only because of design and development, but because it forces strategic decisions. If those decisions are avoided at the beginning, they reappear later as delays, scope changes, weak conversion, messy content, and systems that do not support the team after launch.
Before commissioning a website, ask five questions. The answers will shape the architecture, content, budget, timeline, and long-term value of the project.
1. What work must the website perform?
Do not start with pages. Start with work. Should the website generate qualified leads, collect applications, manage events, support members, publish research, onboard clients, sell services, host resources, route inquiries, or integrate with internal tools?
Once the work is clear, the page structure becomes easier to define. A site built only around how the organization wants to present itself may look good but fail to support daily operations.
2. Who are the priority users?
Most organizations have more than one audience. Funders, clients, members, applicants, partners, journalists, staff, researchers, donors, and prospects may all use the same website for different reasons. The problem is trying to serve everyone equally on every page.
Define priority journeys. What should each audience understand? What should they do next? What proof do they need? What friction currently blocks them?
A clear website brief is less about the pages you want and more about the decisions the system must support.
3. What content needs structure?
Identify recurring content types early: services, case studies, events, resources, reports, team members, programs, testimonials, sectors, locations, partners, grants, articles, or products. If these are not modelled properly, they will become manually maintained pages.
Structured content makes the site easier to update, filter, reuse, and extend. It also helps the organization maintain consistency as the site grows.
4. What systems must connect?
A modern website rarely works alone. It may need to connect to CRM, newsletter tools, payment systems, analytics, booking tools, grant systems, member databases, social platforms, or internal dashboards. These integrations affect architecture and should not be treated as last-minute add-ons.
Even simple integrations require decisions about data ownership, consent, security, workflow, and reporting.
5. What happens after launch?
Who will publish content? Who will manage forms? Who reviews analytics? Who owns technical maintenance? Who updates integrations? Who improves conversion paths? Who trains new staff? A launch without ownership becomes a slow decline.
The right build includes handover, documentation, training, and a support model that matches the organization’s capacity.
The pre-build clarity map
Use these questions in your internal brief
- What should the website make easier for the organization?
- Which audience journeys matter most commercially or operationally?
- Which content types will be reused or updated regularly?
- Which tools need to connect from day one or phase two?
- What internal capacity exists for ongoing ownership?
A better brief creates a better build
A strong website brief is not a list of pages. It is a clear explanation of the organization’s goals, audiences, workflows, content, integrations, and ownership model. When that clarity exists, design becomes sharper, development becomes more focused, and the final platform is more likely to produce value after launch.
The best time to prevent a failed website project is before the project begins.