Most website projects fail in planning, not execution. After 10+ years of leading digital projects, I can predict which ones will succeed within the first conversation. It’s rarely about the budget or the team. It’s about clarity.
The difference between projects that thrive and those that stall comes down to one thing: how thoroughly you’ve thought through what you’re actually trying to achieve. This isn’t about lengthy documentation or procurement theatre. It’s about answering five straightforward questions before you brief an agency. Get these right, and you’ll scope appropriately, communicate effectively, and avoid the costly rewrites that plague most website projects.
What problem are you actually solving?
“We need a new website” isn’t a problem. It’s a solution someone has already decided on. The real work starts with stepping back and asking what’s not working right now.
Is your current site causing visitors to leave before they’ve understood what you do? Are you losing qualified leads because the user journey is confusing? Perhaps you’re haemorrhaging talent because your employer brand doesn’t reflect your actual culture. As a result, each of these requires a fundamentally different approach. Specifically, building a prettier website won’t fix a broken value proposition.
The Validis rebrand is instructive here. When they approached us, they said they needed a new website. What they actually needed was to fix a profound brand misalignment. Their positioning had shifted, but their website still told the old story. The solution wasn’t incremental refinement; it was a complete narrative reconstruction. We started there rather than starting with design. Consequently, everything else followed logically.
The numbers bore this out: 65% increase in click-through rate, 55% increase in average session duration, 20% reduction in bounce rate. These improvements came directly from clarity about the problem.
Take time to write this down. Not in abstracts, but in specifics. Are you losing leads at initial discovery? Do people not understand your service delivery? Is your technical positioning unclear? Naming the actual problem shapes every decision that follows.
Who’s actually making decisions?
Clarity about stakeholders matters more than most people acknowledge. You need to identify three groups: the decision-maker, the influencers, and the doers.
The decision-maker is the person who says yes or no to investment. More importantly, they’re the person who can live with the consequences of that decision. Influencers advise the decision-maker but don’t carry the risk. Doers execute on the outcome but rarely understand the strategic context. These roles can overlap, but they rarely align perfectly.
Common anti-patterns emerge when these lines blur. Design by committee happens when every stakeholder thinks they’re the decision-maker. Invisible stakeholders are the people who veto decisions after the fact without being part of the planning conversation. Delegated decisions occur when someone says yes on behalf of someone else, only to discover the actual decision-maker wanted something different.
In practice, you need one decision-maker with clear authority. That person should understand the business problem and be willing to accept that the agency’s recommendations might differ from their initial preferences. Specifically, avoid letting different stakeholders tell the agency different things.
What does success look like?
This seems obvious until you start writing it down. Success has to be measurable. Not “our site looks great” but “we increase qualified lead generation by 15% within six months” or “we reduce customer support tickets related to account access by 30%”.
The FlexFactor project demonstrates what happens when success criteria are clear before you start. They’d just raised £17m in Series A funding, and they needed a website that could scale with them. Their success criteria weren’t aesthetic; they were operational. Could the platform handle their growth? Could the content architecture support their expanding feature set? Did the checkout experience convert well enough?
As a result, when we’d finished the project, we could measure success objectively. Clicks increased by 63%. Impressions increased by 58%. These weren’t vanity metrics. They directly reflected the business problem we’d been asked to solve.
Define success for your project before you start. More importantly, agree with your stakeholders on how you’ll measure it. This prevents the post-launch conversation where someone says, “I was hoping it would look different,” after you’ve spent six months and £40k.
What are your real constraints?
Every project has constraints. The honest conversation is about which ones actually matter and which ones you can work around.
The honest answer is usually that you’ve got three constraints that matter: timeline, budget, and technical scope. Content is often a hidden fourth constraint that people don’t acknowledge until they’re three months in.
The Fulcrum project illustrates what happens with serious technical constraints. They’re a fund management platform operating across 15 countries with distinct regulatory requirements. You can’t use standard off-the-shelf platforms when you’re managing compliance across three different jurisdictions. The constraint wasn’t solvable with a conventional approach.
Consequently, we built a custom plugin system that allowed them to manage regulatory requirements per-jurisdiction whilst maintaining a coherent user experience. This wasn’t overengineering; it was the only honest solution to their actual constraint. Understanding this upfront meant we could scope the project realistically and communicate the implications of their technical landscape.
Have the conversation about technical constraints early. What systems need to integrate with your new website? What data needs to flow where? Do you have legacy systems that have to stay in place? These conversations are unglamorous, but they shape the entire project.
What happens after launch?
A website isn’t a project that ends on launch day. It’s a system that needs ongoing care.
Who’ll update content when things change? How frequently? Do you have the internal resources to maintain your site, or will you need ongoing support from your agency? This means specific staffing, training, and budget decisions that need to be made during planning, not discovered after launch.
Some projects benefit from a maintenance retainer. Others work better with a defined support period followed by independence. The choice depends on your team’s technical capability and your content change frequency. In practice, the worst scenario is launching a beautiful new site and then having no ability to maintain it.
Common planning mistakes that derail projects
Several patterns recur across projects that overrun or underdeliver.
Starting with solutions before understanding problems is the most common. Someone has already decided “we need to rebuild in React” or “we need a custom headless CMS” before anyone’s asked whether that solves the actual business problem. This means you’re solving the wrong problem very efficiently.
Underestimating content is endemic. “We’ll write the copy during development” is what people say. Then development finishes, and suddenly you’re supposed to produce 100 pages of compelling copy in three weeks. As a result, launches get pushed, or content goes live half-finished.
Treating “website” as a single thing causes problems. Your website is a website. Your email system is separate. Your CRM is separate. Your analytics stack is separate. Assuming they can all integrate seamlessly in one project timeline is optimistic.
Optimistic timelines without buffer are another pattern. Every project has unknowns. Discovering a legacy system incompatibility at month four isn’t a failure; it’s normal. Building in realistic buffer time prevents this from derailing everything.
Treating budget as infinitely negotiable sets projects up for failure. More importantly, every feature added after the scope is agreed costs time and money. Either the timeline extends, or the quality suffers.
How to scope appropriately
The sweet spot is specificity without prescription. Too vague, and you’ll get proposals that cost anywhere from £5k to £50k. The agencies aren’t being difficult; they genuinely don’t know what you’re asking for.
Too prescriptive, and you’re essentially asking agencies to execute your pre-defined solution rather than solve your problem. This usually ends with a website that technically matches the spec but doesn’t actually work well.
Just right means describing the problem clearly, explaining your constraints honestly, and asking for recommendations on how to solve it. An example: “We need to increase lead generation from our website. Currently, we’re getting 5,000 visitors per month with a 2% lead capture rate. Our main constraint is that we need to go live before Q4. We have about £30k to invest. We have 50 pages of legacy content that needs migrating, and we’ll need support updating content quarterly.” That’s a clear brief that allows agencies to propose sensible solutions.
When to bring an agency into the conversation
This is best done during planning, not after. Many organisations create an internal brief, decide what they think they want, and then ask agencies to estimate building that. This inverts the conversation.
Better practice is to bring potential agencies in during the planning phase to stress-test your thinking. They’ve seen what works and what doesn’t across dozens of similar projects. They’ll raise questions you haven’t considered. Specifically, they’ll challenge assumptions that sound right but don’t work in practice.
You might not brief them for the work, but you’ll make better decisions because of their input. More importantly, if you do brief them, the scope will be realistic because it’s been tested.
Timeline reality checks
Simple websites (marketing sites, documentation hubs, small content updates) typically take 6-8 weeks.
Standard websites (modest feature sets, moderate content, integrations with a few systems) usually take 8-12 weeks. This includes discovery, design, development, content migration, testing, and launch.
Complex websites (custom functionality, significant integrations, large content libraries) typically take 12-16 weeks. This usually involves workstream parallelization and requires experienced coordination.
Major platforms (multi-region deployments, significant technical architecture, bespoke functionality) typically take 16-24 weeks. These are rare. If you’re building a major platform, you already know it.
These timelines assume you’re making decisions promptly and making content available to developers when they need it. If stakeholders take three weeks to approve designs, the timeline extends by three weeks.
The Secomak example
Secomak is a 90-year-old manufacturing brand. They manufacture components for industrial applications. Their previous website was functional but dated, and they weren’t capturing enquiries effectively.
The planning phase was thorough. They identified the core problem: engineers needed to find specific product specifications quickly, and the sales team needed a way to generate qualified leads from product interest. Their success criteria were clear: they wanted to increase organic enquiries by 40% within six months and reduce the time it took for engineers to find what they needed.
Their constraints were realistic. They had a fixed budget of £45k. They needed to launch before their trade show in Q4. Their legacy system had 100+ product pages with detailed specifications that needed migrating.
Because the planning was clear, the execution was straightforward. We delivered a site that increased traffic by 100%, generated 60% of new enquiries from organic search, and made product information findable. More importantly, those 100+ product pages weren’t a burden because everyone understood upfront that content migration was a significant part of the project.
Summary
Start with the problem, not the solution. Understand who needs to decide what. Define success measurably. Name your constraints honestly. Plan for what happens after launch.
These five questions form the foundation of projects that succeed. Skipping them doesn’t save time. It costs months and thousands of pounds when projects stall, scope creeps, or fail to deliver what was actually needed.
Read our detailed case studies for more context: Validis, FlexFactor, Fulcrum, Horizon Global Partners, and Secomak.
For timeline context, see The Real Cost of Waiting Until Q4.
For decision frameworks, see Decision-Making Frameworks for Digital Projects.
For sector-specific service pages, see all sectors, financial services, technology, manufacturing, and start-ups. The 4D Framework covers our underlying process.
Frequently asked questions
How long does a typical website project actually take?
Standard website projects take 8-12 weeks from discovery to launch. This assumes clear decision-making and timely content availability. Complex projects with custom functionality or significant integrations take 12-16 weeks. Optimistic timelines that promise delivery in 6 weeks usually account only for development, not discovery, content, or testing. More importantly, speed often trades against quality or scope.
What’s the difference between a website project brief and a spec?
A brief describes the problem and your constraints. A spec prescribes the solution. Briefs allow agencies to propose what’ll actually work. Specs ask agencies to build what you’ve already decided on. Better briefs usually yield better outcomes because agencies contribute strategic thinking rather than pure execution.
Should we plan everything before we talk to agencies?
Not completely. Rough planning before you approach agencies is wise. Sharing your thinking with potential agencies during planning usually improves the final approach. This means they see your constraints and thinking, not just a finished brief. Specifically, this usually surfaces risks and opportunities that internal teams miss.
What if we don’t know what success looks like yet?
That’s common and honest. Start with what you’re trying to improve. Are you trying to increase leads? Reduce support costs? Improve user satisfaction? From there, define what “increase” or “reduce” means in actual numbers. Success criteria that are measurable guide the entire project. Vague success criteria usually lead to post-launch disappointment.
How much content do we need to prepare before we start?
Ideally, you have an inventory of what content exists and an outline of what needs migrating versus rewriting. You don’t need finished copy before development starts, but you do need to know how many pages you have and roughly how complex they are. This prevents the surprise at month three when you realise you have 200 pages to migrate, not 20.
