Building a website without knowing exactly what you need is a bit like hiring a builder and saying, “I’d like a house, please. Something nice.”
Technically, it’s a starting point.
But before long, somebody is going to ask how many bedrooms you want, whether you need a garage, where the kitchen should go and why there appears to be a swimming pool in the quotation.
The same problem crops up with websites all the time.
When women in business tell me they are stuck with their website, they often describe the problem as a technical one. They're unsure which platform to choose, how to connect a form or whether they'll press the wrong button. Those concerns are real, but they're not always the first obstacle.
You decide you need a new website, find a web developer and immediately start talking about colours, layouts, WordPress, animations and whether the logo should be “a little bit bigger”.
But some much more important questions haven’t been answered yet.
Who is the website for?
What does it need to achieve?
What pages are required?
What should visitors be able to do?
What content needs to be created?
And what does success actually look like?
Getting clarity around your website requirements before design and development begins can make the entire project faster, smoother and considerably less expensive.
Here’s why.
A Website Cannot Make An Unclear Business Feel Clear
This is also why handing the entire problem to a developer can lead to disappointment. A good developer can guide you and ask useful questions, but she or he still needs your knowledge of the business.
Without a clear brief, the developer has to make assumptions about your audience, your priorities and your message. The finished site may then be technically sound but still not feel like you or support the way you want the business to grow.
You Stop Paying Developers To Work Things Out For You
Here’s an uncomfortable little truth: every time your developer has to stop and ask, “What do you want this bit to do?”, somebody is spending time on the problem.
And development time generally isn’t free.
A good developer will absolutely help you explore options and make technical decisions. That’s part of their job. But there’s a big difference between asking a developer to recommend the best way to achieve a defined goal and asking them to work out what your business needs in the first place.
Imagine requesting a quotation for a website and saying:
“I need about five pages.”
Then, halfway through the project, you realise you also need appointment booking, downloadable resources, customer testimonials, an email marketing integration, different enquiry forms and a members-only area.
Your five-page brochure website has suddenly eaten a protein bar and turned into something considerably larger.
The clearer your website brief is at the beginning, the easier it becomes for developers to understand the scope and provide an accurate quotation.
The governments Service Manual makes a similar point about digital projects: understanding users and the problem you're trying to solve gives you the best chance of meeting those needs simply and cost-effectively. It also recommends testing assumptions early to reduce the risk of building the wrong thing.
Practical takeaway: Before requesting development quotes, write down every function you believe the website needs from enquiry forms and payment facilities to booking systems, downloads, integrations and customer login areas.
You Build Around Your Customers Instead Of Your Own Preferences
It's remarkably easy to plan a website around what you like.
You like minimalist websites. Your business partner likes videos. Dave from accounts has seen a competitor using a rotating homepage banner and thinks you should definitely have one too.
Before you know it, the website planning meeting has become an episode of Changing Rooms.
The problem is that your customers are the people who actually need to use it.
As Steve Jobs famously put it:
“You’ve got to start with the customer experience and work backwards to the technology.”
He made that point at Apple’s Worldwide Developers Conference in 1997, and it still remains remarkably relevant to website projects today.
Before thinking about design, identify your main website visitors and what each of them is trying to achieve.
A potential customer might want to:
- understand what you offer;
- decide whether they trust you;
- see examples of your work;
- understand your prices;
- arrange a consultation; or
- ask a question.
Those needs should influence your pages, navigation, calls to action and content.
The GOV.UK Service Manual recommends identifying who users are, what they are trying to accomplish, how they currently do it and what problems they experience.
That is a much stronger foundation for a website than “I quite like the one Apple has.”
Practical takeaway: Write down your three most important types of visitor and complete this sentence for each: “When this person arrives on our website, we want them to…”
Your Content Stops Being An Afterthought
One of the biggest website project bottlenecks isn’t code.
It’s content.
The design gets approved. The developer starts building. Everything is moving beautifully.
Then someone asks:
“Can you send over the final text for the About page?”
Silence.
Suddenly, you discover that you haven't actually written it.
Planning your website structure before development forces you to identify what content will be required. That might include service pages, product descriptions, FAQs, case studies, staff biographies, photographs, videos, testimonials, downloadable documents and legal information.
And content deserves proper thought because people rarely examine every carefully crafted sentence on a website.
The Office for National Statistics reports that in 2024 the average user on its website spent just over two minutes on a page, with most leaving after the first section. Its guidance recommends putting important information first and using clear headings so people can quickly find what they need.
In other words, “we’ll fill the pages later” isn’t much of a content strategy.
Planning content early also allows copywriting, photography and development to happen alongside each other rather than becoming one enormous traffic jam near launch day.
Practical takeaway: Create a simple content spreadsheet listing every planned page, its purpose, the main message, the desired action and who is responsible for producing the content.
You Can Think About SEO Before The Walls Are Already Up
SEO sometimes gets treated like something sprinkled onto a finished website shortly before launch.
A few keywords here. A metadata field there. Perhaps somebody whispers “Google” three times while standing near the server.
Unfortunately, good SEO starts much earlier.
Your search strategy can influence which pages you need, what subjects those pages cover, how information is organised and how pages link together.
For example, a company initially planning one page called “Services” might discover through keyword and customer research that people are actually searching separately for five different services.
Giving each important service its own well-planned page may create a much stronger experience for both customers and search engines.
Google recommends organising websites logically because doing so can help users and search engines understand how pages relate to each other. It also emphasises creating useful, well-organised content rather than chasing supposed ranking tricks.
SEO planning before development also means you can think properly about page titles, URLs, internal links, redirects from an old website and measurement tools.
Fixing all of that afterwards is possible.
It is simply less fun, rather like remembering where the electrical sockets should have gone after decorating the room.
Practical takeaway: Before finalising your sitemap, research the questions and search terms potential customers use when looking for your products or services.
You Avoid The Dreaded Scope Creep
“Could we just add one little thing?”
Those seven words have caused many a web developer to stare thoughtfully into the middle distance.
Small additions rarely sound significant individually.
Could we add a calculator?
Could customers create accounts?
Could it automatically connect to our CRM?
Could the website generate personalised PDF reports and email them to three departments depending on which options somebody selects?
Before long, the original project bears roughly the same resemblance to the finished specification as a bicycle does to the International Space Station.
This is scope creep: the project gradually expands after work has begun.
Not every change is avoidable. You will learn things during a website project, and good development should allow sensible refinement.
But getting your website requirements clear beforehand gives everybody a baseline.
You know what is included.
Your developer knows what is included.
And when a new idea appears, you can deliberately decide whether to add it, postpone it for a later phase or quietly place it in the “perhaps never” folder.
That clarity is especially important when comparing quotations. Two developers might appear to be quoting for the same website while actually making completely different assumptions about what is required.
Practical takeaway: Divide requirements into must have, nice to have and future phase. It is one of the simplest ways to protect both your budget and launch date.
You Make Better Technology Decisions
Should you use WordPress?
Shopify?
A custom platform?
Something else entirely?
The correct answer is deeply annoying:
It depends.
Technology should follow requirements rather than dictate them.
If you know you need to sell 500 products, integrate with stock management software and accept multiple payment methods, that points towards a very different solution from a consultancy needing six informational pages and a contact form.
Google’s guidance for web developers highlights fundamentals including security, speed, accessibility and compatibility across devices alongside search considerations.
Those requirements are much easier to consider when they are discussed before development rather than discovered afterwards.
The danger of choosing technology first is that you can end up bending your business requirements around the tool you have already selected.
It's the digital equivalent of buying a pair of shoes and then trying to find someone whose feet fit them.
Practical takeaway: Define what your website needs to accomplish before asking which platform should power it.
Everyone Knows What “Finished” Actually Means
Perhaps the biggest benefit of website planning is surprisingly simple: everyone knows what they are working towards.
Before development begins, you should ideally have clarity around:
Your audience: Who will use the website?
Your objectives: What business results should it help generate?
Your sitemap: Which pages are needed?
Your content: What text, images and other materials need to be produced?
Your functionality: What must visitors be able to do?
Your calls to action: What should visitors do next?
Your integrations: Which external systems need to connect with the website?
Your SEO: What topics and search opportunities matter?
Your measurement: How will you know whether the website is working?
Once those questions have answers, conversations with designers and developers become dramatically more productive.
Instead of saying, “We need a really good website”, you can say:
“We need a website that helps these three types of customers understand these services and encourages them to book a consultation. These are the pages we believe we need, these are the required functions and these are the results we want to measure.”
Now that is something a developer can work with.
A Little Planning Can Prevent A Lot Of Expensive Guesswork
A website is not simply a collection of attractive pages.
It is a business tool.
And like any useful tool, it should be built for a defined purpose.
Taking time to clarify your audience, goals, content, functionality, SEO requirements and customer journeys before development begins can help you obtain more accurate quotes, reduce unnecessary revisions, control scope and ultimately build a website that does what your business actually needs it to do.
That doesn’t mean you need to arrive at your developer’s door carrying a 94-page technical specification and a scale model of the homepage.
You simply need enough clarity to explain what you are trying to achieve and why.
Get that right first, and choosing how to build it becomes considerably easier.
Because when it comes to websites, a few hours spent thinking before anyone starts building can save an awful lot of time spent saying:
“Ah. We didn’t think of that.”
