Website launch horror stories

We are aware launching a new website can cause a bit of a sweat for all teams involved. Especially if you haven’t covered all of the requirements for a smooth, hassle-free launch.

It’s not easy, needs will change dependent on many aspects of the project. So it’s vital to tailor your launch process exactly to your project needs. Something a couple of the ‘big boys’ failed to do…but let’s not point fingers…I’ll delve into that along the way. For now, let’s discuss some important ‘do’s and don’ts’ to make sure we don’t make the same mistake:

1. Skimping on Cross Browser/Device Compatibility Checking

This has to be one of the most common (and most embarrassing!) failures with all website launches. Working in the industry, it would be safe to say we would love it if the world would just come together, open Chrome and forget the other browsers. However, sadly this is not the case. W3 Schools have a little insight into what we are dealing with. If you take a look at the actual percentages, it almost seems pointless but that’s where people go wrong – it isn’t! We are being dominated by many different user preferences…and the likes of Internet Explorer are our ball and chain!
As well as multiple browsers, the introduction of ‘responsiveness’ over the last few years has added a whole new host of issues for us to find on a vast number of devices. But that’s just it – they are there for you to find.  Find them – fix them – the solution is simple!

2. Neglecting those all-important QA hours

Check once. Check twice. Check three times. In this day in age, a site launching with major functionality issues is just not acceptable. No one wants to put a site live to realise you can’t actually submit a contact form or view a product page – CRINGE! Waitrose’s £10,000,000 website was one to make this mistake, loyalty codes failed as users tried to edit their baskets and they were unable to enter long names as usernames, the simple stuff. Sure fire way to lose some sales! In fact something similar happened in the launch of Marks and Spencer’s website and was the blame for an 8.1% drop in sales…ouch! It could have been something to do with the fact users couldn’t get to the checkout, when they could, they couldn’t complete the delivery section. That’s if they even managed to get there without items disappearing from their basket! So again, check once, check twice, check three times - don’t be a fool!

3. Turning a blind eye to usability testing

Did you have meeting after meeting on the design of your website? Should we use this image here? Should the navigation be this colour? I bet you did! Did you follow the steps your users would take to make sure you are giving them a seamless experience? Did you plan out your red routes? Perhaps not! There is almost always a rush in getting a site live by a certain date – slow down and make sure by putting your new site live you’re giving your users a better experience than before!

4. DNS boo boos

DNS changes…a little scary for even the most experienced. Incorrectly updating a DNS record can lead to a very tense go live team! You will of course need to update the A Record to point to the new server but doing so, if not done carefully and correctly can lead to a whole host of issues. If the TTL (time to live) has not been thought about beforehand you could be waiting anywhere from 24 – 48 hours for the internet to reflect the changes. So if you make a mistake, you could be waiting even longer to rectify it. The best thing to do is make sure it’s set to 5 minutes, turning those tense hours into tense minutes!

5. Nuking MX Records

Don’t get trigger happy within the domain control panel…an easy mistake to make if strict instructions are not given. Yes, you will need to update the A record, but unless you have previously agreed to changing where the emails are going, there is no need to repoint the MX Records. Doing so could leave you with a rather unhappy client with no means of sending or receiving emails.

6. Forgetting all about the SSL

This is a launch mistake no one wants to admit to, such a simple but damaging ‘don’t’! With Google’s new rules around SSL, we are likely to see more of this happening amongst the many website migrations every year. No one wants to see a very big, very obvious ‘This site is not secure’ message, especially when launching a site taking online payments. Even worse, if on your server, you will be answering to Mr PCI, a rather costly mistake.

7. Not taking security seriously

The most embarrassing scenario for a lot of web developers would be to launch an insecure website to be taken down by hackers hours after it is introduced to the internet. There are many things you can do to ensure you reduce the risk of a security breach.  A rather simple one, is to ensure it is completely up to date, whatever your platform, whether it be open source or a bespoke build, it is imperative to keep on top of security updates.  With some platforms releasing anything from 1 - 4 new releases per month, it can seem a daunting task, but the risk of not keeping up to date with these patches are all too clear.

8. Underestimating the value of your website performance

Users are impatient – because they can be! With the likes of Google and many other handy apps, we can find what we want, when we want, in a matter of clicks. If your user is sat too long waiting for a page to load, they won’t be a user for very long. There are a few things that can be done to ensure you are making the site as quick as possible:

• Resize and optimise images

• Use caching to your advantage

• Combining any assets (JavaScript, CSS, etc) into as few files as possible.  

9. Make sure it can take the strain!

Often overlooked is ensuring that your infrastructure is able to deal with the demand. It is a difficult balance to make, you never really know how much traffic your site will get and you will be reluctant to invest in hugely expensive servers if they aren't needed. Some things you can do to reduce the risk of being caught out include:

• Identifying bottlenecks, either code or network based

• Ensuring servers have enough head room and capacity to increase the load

• Load balance where possible

• Ensure you have data centres located across the globe that serve local requests

• Ensure you use a content delivery network to serve static resources such as JavaScript and images (learn more about CDNs in our article: https://www.reflectdigital.co.uk/blog/page-speed-lean-in-2017)

• Server monitoring is a must have

You don’t want a terrible Pokemon Go situation on your hands!

10. Launching on a Friday – Rookie!

Launching on a Friday is sure fire way to ensure your inbox is extremely full on a Monday morning. Be sensible and expect post launch bugs. The live environment is different to the staging environment – it’s inevitable. When this does happen you will want to ensure support is at hand to fix these bugs imminently. So be strategic when picking your launch date.

Hopefully these little pointers might help you avoid any major bloopers! Contact us for a free audit and we may be able to help prevent these issues next time around…who knows…there could still be a few issues lingering!