I’ve witnessed a couple of occasions lately of people being given the hardsell into getting a new website built – when as an onlooker I don’t really think there was cause. Meanwhile I’ve seen 2 recent cases of people who could really do with one but decide not to.

There are so many reasons to get a new site. Perhaps your organisation has outgrown what it’s got and it’d actually be cheaper to start again – let alone cleaner and fresher from a code and UX point of view; sometimes muddling through, despite being as thorough as possible, just isn’t as streamlined as an experience as a fresh start. It could be that you need new features, or that your traffic levels or user base have grown so much you’re creaking at the seams and your old site just isn’t up to the job.

Perhaps you got hacked – and your old site is so riddled with nasties the only safe option is to start over (and next time keep up to date with upgrades and security best practice!). Or perhaps it’s just not efficient or practical for your team to update the site you’ve got and they need something else. It may be that your site was based on a plugin or piece of software which is no longer supported (this is a reason why it’s a good idea to avoid relying too heavily on things like WordPress plugins) and so isn’t secure any more, or maybe your site was built on a really obscure framework which no one really uses and once you stop working with the developer who set it up, you’re stuck.

There are many many reasons why you might decide to embark on a new website. But there are also a few key reasons why not to.

A new developer doesn’t like the inherited code

I get it. No one likes working with someone else’s code. It’s so much nicer to write your own and know the system inside out. It’s not just about the code – especially now a days when things are done on frameworks like Laravel and so there’s a prescriptive formula for how things should at least be laid out. It’s also about wanting to do a good job of supporting the system moving forward. If you didn’t build the site, then no amount of handover will tell you absolutely everything there is to know about the site and how it got to where it is now. Why the client wanted something done a certain way, or why a previous feature meant that something else was coded to suit that but now that earlier feature has gone and so the latter feature seems a little odd.

If you want to support a client, and be able to answer their queries and jump quickly on their requests, it’s so much easier to do so if you know the site inside out. And if you don’t want a bug to look bad on you, you don’t want to inherit something which may have faults you don’t know about.

However, building a new website can often cost a lot of money and take a lot of time – of the client’s as well as the developers. And so if you’re moving to a new developer and they’re suggesting you start over, it’s worth trying to dig deeper and identify if the new developer just doesn’t want to work with the old code or if the site really does have issues that can’t be cost effectively rectified. This may require a 3rd party audit to get a unbiased opinion – which is basically just another developer again taking a look at it.

Your current developer wants to get more work from you

Some developers just don’t like supporting old projects and want to start again. I’ve seen this recently when a company were dragging their heels and not doing updates for their client because they said they didn’t want to support the framework the site was on – even though they’d built it. That client came to me asking if we could take over the old CodeIgniter site, and we said we could as we look after a lot of big CodeIgniters still – but in the end they decided to get a new site built, on a newer framework, by their usual development team. 

And I get it. They’d worked with that development team for years so it makes sense to stick with them. And that development team of course know the requirements like no one else as they’d built the site already. But if the new site isn’t getting any new features – then really, what’s the point? 

My concern in this scenario is what happens after that site launches? Will the old development team want to support it then? Or will they, again, get bored of it and be slow in doing updates and helping the client move forward as they’re off building a new site for the next client? And if you move to someone new then, will you be in the situation above where no one wants to inherit the code?

For me in this situation you’ve got to really carefully weigh up the pros and cons of what you’ve got, and whether you need to invest in a new site or if a move to another developer – which is of course super risky – is a safer move than staying with someone who wasn’t really supporting you. 

A flashy salesman in a shiny suit says you need one

This one says what it is on the tin really – don’t be sold something you don’t need. Before making any big decisions off the back of a cold call or a sales pitch over a networking breakfast, have a proper conversation with your current developer to ascertain whether they too had been thinking you needed some changes but didn’t know how to bring it up, and whether it warrants a whole new site or whether just some tweaks could liven things up again.

Someone new to the team wants to make a splash

I’ve only seen it a couple of times in my career, but it makes me groan for the organisation concerned when I do see it. When someone new joins, and basically – as far as I can tell anyway – they want to make a splash and start over. They don’t have any technical reasons why, and the old team were managing perfectly well with the site before they joined and things were going well – but the new team member just doesn’t really take the time to get to know what’s there already and just comes in with the plan to start again.

It may be that the new person feels they want complete ownership of the tool they’re now looking after, and so by being involved in the build project they’ll be more familiar with everything – the equivalent of the developer not wanting to inherit code. But it does frustrate me if I think that the people signing off on the costs are doing so misguidedly. 

Tell tale signs of this are whether the new team member had looked at the site and it’s features before starting to talk about replacing it, and if, when they’re told the old site can do everything they want anyway, these words fall on deaf ears.

A legitimate time to get a new site

Despite the reasons above, there are of course definately times when it’s a good idea to get a new site. And in the last couple of weeks I’ve been reminded of one strong reasons from two WordPress sites we’ve inherited (yes we’re the poor saps who take over inherited code and don’t insist on a rebuild!). In both cases, the sites use waaaaay too many plugins – one has over 45 plugins on it! For context, when we build a WordPress site over at 18a we tend to use about 5 mainstream, well supported ones. (Update: since drafting this someone has come to me with a site they’ve been building themselves for over 2 years and that has over 70 plugins!)

Over 45 plugins means that if a couple of them start to conflict with each other after an upgrade, you’ve got a broken website and a lot of work to do to find out why. Plus you’ve got security vunerabilities if some get out of date or aren’t properly maintained by the people who made them. And let’s face it – plugins are often made and distributed for free so it’s very possible that the guy who did it just can’t look after it forever. As it stands, some of the feature changes they want aren’t possible as the plugins don’t allow it so their project is ticking over but growth is stalled.

On the other inherited site I’ve been looking at again this week, we got their plugin count down from about 25 to 17 – but that’s still 10 more than we’d like! And the upshot of them having so many plugins is that their website needs a really high powered server to run it, which costs them a lot of money every month. They’ve also faced security issues. So they are definately an example of a site who I think just needs a cleanse and a fresh start as their site has already been passed through about 3 different agencies before it landed with us a couple of years ago.

So in these two cases – I strongly think the organisations need to consider a rebuild so that they can move their brands forward. But that’s easy for me to say as I don’t need to pay for it!

Ask yourself…

It can be really hard to know whether you need to build a new website or not – overall, ask yourself, what are the problems with the existing site (or the existing day to day runnings of it), are they fixable – and at what cost? If you don’t like the answers, then yes it might be time for a new site!

Pic courtesy of Unsplash