Hiring someone to build a website should be straightforward, shouldn’t it? You know what you want, they know how to build it, money changes hands, website appears. Job done.
Except it almost never works that way. The same problems keep sinking projects.
I’ve been building websites professionally since 2005, and I’ve watched the same problems come up over and over again. The projects and the teams change, but the underlying issues stay remarkably consistent. What’s interesting is that most of these problems don’t show up during the build phase itself. They are largely a result of a lack of proper research and preparation.
Whether you’re a sole trader commissioning your first site, a marketing manager trying to wrangle a redesign, or part of a larger team navigating internal politics and competing priorities, your website project should move through three distinct phases. Miss any one of them, or rush ahead, and you’re setting yourself up for expensive mistakes and frustrating delays that could have been avoided.
What’s this post all about then?
My goal here isn’t to sell you a website project. It’s to show you how these three project phases work, what commonly goes wrong at each stage, and how to recognize the warning signs. Over time I’ve worked on projects for charities, academic institutions, small businesses, and larger organizations across the UK and Europe and in my role as a website consultant I’ve seen the same negative patterns repeat time and again.
The three project phases (and why you shouldn’t skip any of them)
For arguments sake, let’s assume you’re starting from scratch. You’ve got a rough idea of what you need, but nothing’s been documented, no one’s been hired, and you’re not entirely sure what your first move should be. This is actually a good place to be, because at least you haven’t locked yourself into decisions that might turn out to be damaging.
Every web project moves through three phases, whether you plan for them to do that or not. Think of it like building a house. You need proper foundations, you need the actual construction, and you need ongoing maintenance once people are living there. Skip the foundations and your house develops cracks. Skip the maintenance and it falls apart faster than it should.
Skipping research and discovery is how you end up building the wrong thing beautifully.
Here’s how it breaks down:
Phase 1 is Research and Discovery. This is where you work out what you actually need, who it’s for, and what success looks like. Clients often want to skip this for a number of reasons. They see it as an unnecessary expense, something that is holding up making real progress, or because they know what they want. Unfortunately, skipping it is how you end up building the wrong thing beautifully. In my experience client’s often know what they want, but they seldom know what they ‘need’. This is the difference between being focused on the end users needs, the tasks they need to complete, and the decision makers personal preferences.
Phase 2 is Design and Build. This is what most people think of as “the web project” the visible work of creating layouts, writing code, and assembling something you can click through. It’s important, obviously, but it only provides a good outcome if Phase 1 was undertaken thoroughly.
Phase 3 is Ongoing Maintenance. Websites aren’t static. WordPress updates, plugins needing patching, content drifts out of date, and your business evolves. Treating a website as a finished product the moment it launches is like buying a car, leaving it unlocked and never servicing it or changing the tyres.
Treating a website as a finished product the moment it launches is like buying a car and never servicing it.
Now, I know what you’re thinking: surely we can start at Phase 2 if we’ve already got a clear brief? And the answer is: you can, but you’re taking on unnecessary risk. If anything was incorrect or incomplete in the work that came before, you’re building on shaky ground.
So let’s walk through each phase. I’ll show you what should happen, what typically goes wrong, and what you can do to avoid the common pitfalls.
Phase 1: Research and Discovery (or why clients often want to skip the most important bit)
This is the phase clients often want to rush through or skip entirely, and it’s also where most projects quietly start to fail. Discovery is about working out what you actually need (or more accurately, what your end users need) before anyone touches design software or writes a line of code. It sounds obvious, but you’d be surprised how many projects jump straight to “we need a new website” without asking “do we actually need a new website, and if so, why?”
In my experience, most clients I onboard say they need a new website. It doesn’t take much prodding before that assertion starts to unravel.
Most clients I onboard say they need a new website. It doesn’t take much prodding before that assertion starts to unravel.
What should happen during discovery? You’re trying to answer some fundamental questions:
- What’s the website supposed to achieve for your business?
- Who are you building it for, and what do those people actually need?
- What works on your current site, if you have one, and what’s causing problems?
- What are your competitors doing that works, and where are the gaps you could fill?
- And critically, what does success look like, in specific terms you can measure?
This isn’t just a nice-to-have. If you skip proper discovery, you’re building on assumptions. Maybe those assumptions turn out to be right, but more often they’re partially wrong or they miss something important. And once you’ve built a site based on those faulty assumptions, unpicking it later is expensive and frustrating. It’s that “error carried forward” problem you remember from maths lessons at school. Everything downstream inherits the mistake.
The data backs this up. Research from Nielsen Norman Group found that performing a proper discovery phase cuts the risk of project failure by 75%. That’s not a marginal improvement. That’s the difference between a project that succeeds and one that doesn’t.
Let’s not forget one really important thing though. The research and discovery phase of a project is also about giving your contractor or agency time to learn about you. To absorb as much information as possible so they understand the value that you deliver, with the purpose of allowing them to communicate like you and align with your values. That kind of investment increases the chance of harmonious interaction, reduce the chance of project failure and makes working together much more straightforward.
Research from Nielsen Norman Group found that performing a proper discovery phase cuts the risk of project failure by 75%.
A good discovery process involves talking to your team, understanding your customers, looking at data if you have it, and documenting what you learn in a way that everyone can refer back to. The output should be a clear brief that defines scope, sets realistic goals, identifies your audience, and establishes what success looks like. It’s not glamorous work, but it’s the difference between building something that works and building something beautiful that misses the mark. This is where having an experienced website consultant guide the process can prevent expensive mistakes down the line.
Where discovery can go wrong
Here’s what typically derails this phase, and what to watch out for.
You don’t dig deep enough into what you actually need. This usually happens when timelines are tight or budgets are squeezed, so discovery gets compressed into a single kickoff meeting. You end up with surface-level information (“we need an e-commerce site”) but no real understanding of the business problem you’re trying to solve, the audience you’re serving, or the constraints you’re working within. The result is a website that technically does what was asked for but doesn’t actually solve the underlying problem.
Communication breaks down between you and whoever’s building the site. This one’s insidious because it doesn’t announce itself with dramatic failures. It just quietly accumulates misunderstandings. You say “modern design” and they hear “minimalist.” You say “easy to update” and they build something technically updatable but requiring skills you don’t have. Clear, specific communication matters, and it matters most at the start when you’re establishing the foundations.
Nobody defines what success actually looks like. If you can’t measure whether the site’s working, you can’t improve it, and you can’t make informed decisions about what to prioritize. “Increase conversions” isn’t specific enough. “Increase newsletter signups by 25% in the first quarter” is something you can actually work towards and measure. Without concrete goals, you’re just hoping things work out and let’s remember, hope is not a valid strategy.
You skip the user research and build based on what you think people want. I’ve watched this happen more times than I can count. Internal teams build sites based on their own preferences or assumptions about users, and then wonder why engagement is poor. Your users aren’t you. They have different technical abilities, different priorities, different pain points. If you don’t talk to them or look at how they’re actually using your current site, you’re guessing. Actually, this is one of two ‘difficult conversations’ I try to get out the way as early as possible. The first is to discuss money. The second is to remind the client that what we are designing, isn’t for them, it’s for the users and it’s the users that we need to delight.
Expectations get set that don’t match reality. This happens when there’s a disconnect between what you want to achieve, how much time you have, or what your budget can buy. Sometimes it’s driven by optimism, sometimes by pressure from stakeholders who don’t understand what’s involved. Either way, setting unrealistic expectations at the start means disappointment later. Better to have honest conversations early about what’s actually achievable within the project constraints and to develop a strategy such as phased development where the goals aren’t achievable within budget or time.
Phase 2: Design and Build (where everything gets real)
This is the phase most people think of when they picture a web project. It’s the visible work: the designs, the layouts, the actual clicking through pages and seeing something take shape. If you’ve done Phase 1 properly, this is where that groundwork pays off. If you skipped it or rushed through, this is where you discover what you missed.
The work typically starts with structure before it gets into aesthetics. You’re mapping out how the site fits together, what pages exist, how they connect, what the user journey looks like. Wireframes are basically rough sketches that show where things sit on a page without worrying about colors or fonts yet. They’re useful because they let you test the logic of the layout before anyone gets attached to how it looks. Once you’ve got agreement on structure, then you move into the visual design work, choosing colors, typography, imagery, all the things that make it look like your brand rather than a generic template.
Wireframes are basically rough sketches that show where things sit on a page
Then comes the build, where designers hand over to developers who turn those static designs into something that actually works. This is HTML, CSS, JavaScript for the front end that users see, and whatever back-end systems are needed to make everything function. Content management, databases, e-commerce, forms, all that. Throughout the build there should be testing happening to catch issues before launch. Different browsers, different devices, different screen sizes. It’s tedious but necessary, because what looks perfect on your laptop might be a mess on your customers phone.
Once it’s built and tested, there is usually a round of snagging, because hey, we’re all human and we all are capable of making mistakes. Sometimes goals adapt during the project, and that’s fine so long as it doesn’t break the scope of the project. Then there’s usually some handover and training so you can actually manage the thing once the build team moves on. Whether I’m handling the development directly, overseeing an agency’s work, or collaborating with your in-house team, the goal is always the same: a site that’s not just nice to look at but actually works for your users and achieves what you set out to do in Phase 1.
Where design and build go wrong
Even with good discovery, this phase has its own set of problems waiting to trip you up.
The design doesn’t match what you were expecting, or it doesn’t feel like your brand. This usually points back to communication problems. Maybe the brief wasn’t clear enough, maybe the designer made assumptions, maybe you approved something at the wireframe stage without realizing how it would feel once the visual design was applied. Design is subjective, which makes it tricky. What looks “modern” to one person looks “cold” to another. The way to avoid this is to be really specific about what you like and don’t like early on, and to check in regularly rather than waiting for a big reveal at the end. A good agency or freelancer will keep you involved so that there is a very very low risk of any surprises.
Scope creep turns your fixed-price project into a nightmare. Scope creep is when new features and changes keep getting added during the build. It starts innocently enough (“while we’re at it, could we just add…”) but those small additions accumulate. Timelines blow out, costs increase, and suddenly the project that should have been done weeks ago is still dragging on. The best defense is a clearly defined scope from the start and a change control process.
If something new comes up, fine, but it gets documented and costed and everyone agrees before it gets added. If it’s minor it can be incorporated. If it’s more significant, it can be addressed after go live as a smaller add on project, quoted and billed separately so as to not hold up progress. If it’s project breaking in nature then the project should be stopped, paid up and concluded with a new project brief and a new budget and timeline. The latter is incredibly rare in my experience unless something major happens like a company being bought out, a team being disbanded or a sudden unexpected company wide rebrand happening.
It starts innocently enough (“while we’re at it, could we just add…”) but those small additions accumulate.
The site looks good but doesn’t actually work well for users. This happens when the focus goes heavily on aesthetics without enough attention to user experience. Navigation that looks slick but is confusing to use. Forms that are beautifully designed but frustrating to fill out. Content buried three clicks deep because the structure prioritizes looking minimal over being useful. User experience isn’t about making things pretty, it’s about making them work intuitively for the people who’ll actually use them.
User experience isn’t about making things pretty, it’s about making them work intuitively for the people who’ll actually use them.
Nearly 80% of website redesigns underperform because they focus too much on aesthetics and less on functionality. This is one of the most common mistakes in the design and build phase, creating something that looks modern but fails to serve its actual purpose.
Technical problems surface late in the process. Maybe the site works perfectly in Chrome but breaks in Safari. Maybe it’s fine on desktop but the mobile version has issues. Maybe it’s slow to load because nobody optimized the images or tested the hosting setup properly.
These problems are avoidable if testing happens throughout the build rather than being left to the end. Fixing browser compatibility issues at the last minute when you’re meant to be launching is stressful and potentially time consuming ie. expensive. Better to catch them early when they’re small problems rather than late when they could becomes significant complications.
Phase 3: Ongoing Maintenance (or why launch day isn’t the finish line)
Most people want to treat launch day as the end of the project. The site goes live, everyone celebrates, the agency or freelancer moves on to their next project, and that’s that. Except it isn’t, because websites aren’t static. They are best thought of as organic, they need ongoing attention or they deteriorate. It’s not dramatic like you wake up one morning to find your site completely broken. But gradually, over time, without maintenance, things start to go wrong.
WordPress is constantly being updated to patch security vulnerabilities and to implement performance improvements. Plugins subsequently need updating to stay compatible with those WordPress core updates. Themes also need patching when vulnerabilities are discovered. If you’re not keeping on top of this, you’re leaving doors open for hackers. Sites do get hacked, and a number of my clients first came to me because their site had broken, got defaced or were showing content the client rather wouldn’t be associated with. Usually events such as these occur as a consequence of plugins that have known vulnerabilities not getting patched.
About 90% of WordPress vulnerabilities are in outdated plugins
Beyond security, there’s performance to think about. Websites slow down over time as databases fill up, images accumulate, and code gets bloated. You need regular optimization to keep things running smoothly. This is exactly why ongoing website maintenance should be part of your planning from day one, not an afterthought when problems emerge.
And then there’s content. If your site is still showing your 2023 opening hours in 2026, or your team page lists people who left two years ago, that’s a problem. Outdated content makes you look unprofessional and harms your search rankings because Google can see the site isn’t up to date.
The improvement side of maintenance is about evolving the site as your business changes and as you learn what’s actually working. You look at analytics to see where users are dropping off, what content they’re engaging with, what’s driving conversions. Then you make adjustments based on that data. A good website gets better over time because you’re continuously learning from how it’s being used.
A good website gets better over time because you’re learning from how it’s being used.
Where maintenance falls apart
This is the phase most businesses get wrong, usually by ignoring it entirely until something breaks. Until it is either too late to fix, or expensive to fix. It makes sense to think about site maintenance as an insurance policy.
Security updates get neglected until there’s a problem. Sites go months or even years without updates, and then one day they get hacked or stop working because a plugin that wasn’t updated is now incompatible with everything else. WordPress releases updates for a reason: they’re patching security holes and fixing bugs. When you ignore those updates, you’re taking unnecessary risks with your site and your users’ data. Something you would have a tough time defending to the ICO (Information Commissioners Office) if any user data is exposed or lost.
To prove this point, I ran an experiment. I built a typical business WordPress site with e-commerce functionality and a collection of the most commonly used plugins, then deliberately left it unmaintained for 6 months. No updates, no security patches, no maintenance whatsoever.
The deterioration was faster than even I expected. By Week 1, over a third of the plugins already needed updates. By Week 11, every single plugin on the site was out of date. By Week 23, the site had blocked over 1,700 unauthorized login attempts.
And this was a site with almost no visibility. A real business website with actual traffic would face far more aggressive attacks. The numbers are stark: about 90% of WordPress vulnerabilities are plugin vulnerabilities, with most attacks targeting outdated third-party plugins rather than WordPress itself. When you skip those plugin updates, you’re essentially leaving the front door unlocked.
Nobody’s watching the analytics, so opportunities get missed. You’ve got data sitting there telling you how people use your site, where they struggle, what works and what doesn’t. If nobody’s looking at that data, you’re flying blind. You can’t improve what you don’t measure, and you can’t see problems until they become obvious enough that people start complaining. Regular analytics reviews help you spot issues early and capitalize on what’s working.
Content drifts out of date and nobody notices. That blog post you published two years ago still gets traffic, but the information in it is now out of date and you’re giving people the wrong advice. Your service pages don’t reflect the services you actually offer anymore. Your contact details changed but the website still shows the old information. Each individual instance might seem minor, but collectively they erode trust and make your business look sloppy or potentially even like a scam.
The site gets left behind as web technology moves forward. Web standards evolve. Browser capabilities change. User expectations and browsing habits shift. A site that looked modern five years ago may look dated now. Performance benchmarks that were acceptable in 2020 aren’t good enough in 2026. If you’re not periodically reviewing and updating your technical foundation, your site becomes the digital equivalent of a shop with peeling paint and a flickering neon sign. Technically it’s still a shop, but it might not want to be somewhere customers want to go.
The difference between hoping it works and knowing it will
If you’ve read this far, you’re probably either planning a web project or trying to rescue one that’s already gone sideways. Either way, you now know more than most people starting out. You understand that web projects aren’t just about picking a nice template and filling in some text. They’re about doing proper groundwork, managing the build carefully, and committing to ongoing maintenance once the site is live.
Here’s the thing that nobody tells you at the start: most web projects that fail don’t fail because of bad developers or impossible requirements. They fail because someone skipped one of these three phases or rushed through it without doing the work properly. The discovery phase gets compressed into a single meeting because budgets are tight. The build phase prioritizes looking good over working well. The maintenance phase gets ignored entirely because everyone assumes launch day is the finish line.
Most web projects that fail don’t fail because of bad developers or impossible requirements.
You don’t have to make those mistakes. Now that you know where the common pitfalls are, you can avoid them. You can insist on proper discovery even when people want to jump straight to design. You can push back on scope creep before it derails your timeline. You can plan and budget for ongoing maintenance from day one rather than treating it as an afterthought.
Does this mean your project will be easy? No. Web projects can be complex, and they involve coordinating multiple people with different priorities and expertise. But knowing what to expect at each phase, understanding what can go wrong, and recognizing the warning signs early, that’s what separates projects that succeed from projects that limp along and eventually get abandoned.
Does any of this strike a chord?
If you’re looking at a web project and feeling a bit overwhelmed by everything I’ve outlined here, that’s actually a good sign. It means you’re taking it seriously. And if you’d like someone in your corner who’s navigated these three phases more times than they can count and knows where the problems hide, that’s exactly the kind of work I do.
I help organizations get their web projects right, whether that’s leading the build myself, consulting on strategy and discovery, working alongside your existing agency, or stepping in when things have gone off track.
You can see more about how I work as a website consultant here, or get in touch directly on 01903 527927 or via the contact page. I promise, no sales pitch, just a straightforward conversation about your project and whether I can help.