The Forever Website?

I mentioned last week that I had been updating an old site build, stripping out Twig templating which feels unnecessary in the age of the Block Editor, and fixing deprecated block registration. This week, I’ve been working on a major update to another website I manage – a site I didn’t build myself, but inherited from another developer.

Both of these sites are more than five years old, but still going strong, still receiving daily use from the owners and their customers, and still doing exactly what they were designed and built to do. In both cases, when additional development was needed, it was found to be more time and cost-effective to build on what we had, rather than throwing everything away and building a new site from scratch.

The web industry often feels like it’s all about pushing forward, immediately jumping onto the latest platform or technology, lest we be left behind. That’s how the industry want us to think – it’s the kind of thing that drives investment and profits – but let’s face it, it’s also the way most of us think already. We love getting excited about new tech, new working practices and the latest hot design trends. It’s fun, and ties in with the culture of experimentation that underlies much of the web – plenty of us started out messing about with code in our bedrooms, hacking together sites and apps, reverse engineering components and designs we found online. I know I certainly did, and it’s an ethos that persists to this day.

It’s good to keep on top of everything that’s going on in the industry. It keeps things interesting, and means you’re always aware of what’s coming down the pipe. But, when it comes to my day-to-day work of building websites for people – businesses and organisations who need their site to reliably fulfil a specific function – I take a different approach. 

While it can be tempting to jump in on the latest thing, swapping tech on every build, riding the cutting edge, impressing peers on social media, a better way is to build something for the long haul.

There’s value in picking an established, well-known platform (like WordPress!), writing clear, maintainable code, and taking the time to consider less exciting aspects of the site such as accessibility, the editing experience, and establishing a solid hosting and maintenance routine.

As I have been working on these two old sites these past few weeks, I’ve been thinking about some of the things I consider important when building websites.

• Ensuring you don’t rely on specific content – Websites change. What the client wants to say when the site launches may be very different from what they want to say two, three or five years down the line. The design, code and content management system should be flexible enough to cope with content changes without falling over.
  
  
• Writing sustainable, maintainable code – It’s easy, during a build, to prioritise speed over maintainability. Solving problems is fun, structuring and documenting your code is not.  But no matter how clear and concise your code feels when you first write it, a few months or years down the line it’s a very different matter. And that’s assuming you’re the one returning to it. If you’re writing code to last, that might not necessarily be the case. We’ve all had the joy of inheriting another dev’s code, so be kind to whichever future developer has to decipher what you’ve written – even if that developer is you.
  
  
• Reducing dependencies – It can be tempting to lean on plugins to support and enhance your site, or even to help build it. WordPress has a vast array of plugins available, covering almost every aspect of website development, management and maintenance: it’s one of the platform’s great strengths. However, every plugin you add is another potential point of failure, another level of complexity for you to maintain. That’s not to say you shouldn’t use plugins, but choose them carefully, and prioritise ones that are well-written, with good documentation and support.
  
  
• Establishing a long-term support plan – Think about what will happen after the site launches. Who is responsible for things like content changes, platform and plugin updates, licences, hosting, security, bug fixes? If the client wants to look after the site themselves, have they been given the appropriate documentation and training?
  
  It’s one thing to build a functional, nice-looking website on day one, but if you want that site to last, continuing to perform well for the client over the long term, it’s vital to have a defined plan in place.
  
  I see a website as a long-term project. I’ve worked with the majority of my clients for years, looking after their websites and dipping in to do larger updates when needed. In situations where clients just want to work with us on the initial project, we provide advice on looking after their site, and help setting up so they can manage things themselves.

There’s a thrill in being an early adopter, but as time goes by I find I get more satisfaction and take more pride in projects like the ones I have been working on recently, the sites that carry on, quietly and consistently, delivering what they set out to, far beyond everybody’s expectations.