One of six promises

It never becomes a project again

You shouldn't be rebuilding every two years. The sites I build are still running five years on, and I'm the one looking after them: updates tested before they go live, backups every day, security watched.

Most business websites get rebuilt every two or three years. Not because the business changed, but because the builder went stale, a plugin broke the forms, or the developer vanished. And every rebuild resets the visibility the last one had built up. That cycle is the most expensive thing about most websites, and it’s optional.

Why mine last

Written by hand. No page builder, no off-the-shelf theme. There’s nothing to go stale, nothing that breaks on update day because a third party changed their mind, and other developers can read it if they ever need to.

Lean. A hand-built site is typically a fraction of the code of a builder’s output, which is why it’s fast and why it stays fast.

Looked after. Every update is checked, tested on a copy of the site, applied, then the live site is reviewed. Never automatic. A backup before every change and every day regardless. Security watched around the clock.

What “looked after” includes

Hosting on managed infrastructure, not shared servers. Daily off-site backups and a snapshot before every update, with one-click restore. Firewall, malware scanning, two-factor login. Uptime watched and alerted. Updates tested and reviewed by a person. And when something needs attention anyway, you email me, not a ticket queue.

The question to ask anyone looking after a site

“Who owns updates?” If the answer is the host’s automation, nobody is checking whether the forms still work. If it’s “we do them when we remember”, it’s untested and unbacked. If it’s “we’re not sure”, that’s the risk. The answer you want is a person, a schedule, a backup every time and a test every time.

Month to month

A fixed monthly amount per site, no long contract. Most of my clients stay on for years; it’s the part that stops the website ever being a project again.

Questions people ask me about this

What does looking after a site actually involve? Hosting is where the site lives. Care is someone looking after it: updates tested before they go live, a backup every day, security watched, and a person who answers. Most businesses buy the first and assume the second is included. It usually isn't. What’s different about how you build a website? Every site is written by hand. No page builders, no off-the-shelf themes. It loads faster, it doesn't break on update day, your team can edit words and prices without touching the layout, and it's still running five years on. Why did our site break after an update, and how do we stop it happening again? Because something was updated without anyone checking what it would do. Nearly every break after an update is preventable: read what's changing, back up first, test on a copy, look at the live site afterwards, and fix before applying the next one. The real question is who owns that process. If the answer is "we're not sure", that's the risk. What’s the difference between hosting and looking after a site? Hosting is where the site lives: the server, the speed, the uptime. Care is someone looking after the site itself: testing updates, keeping backups, watching security, fixing small things before they become big ones. Most businesses buy the first and assume the second is included. It usually isn't. Why don’t you use page builders? Because they're borrowed decisions. A builder ships thousands of lines of code for things your site doesn't need, slows everything down, breaks unpredictably on update, and locks you to its roadmap instead of yours. Most builder sites get rebuilt within three or four years. Mine don't. What does hand-coded actually mean for us? It means the site was written for your business rather than assembled from a kit. In practice: it loads fast, it doesn't break when a third party changes their mind, your team edits content without touching layout, and any competent developer could read it. Simplicity is the feature. We’re on Webflow. Can we move without losing our rankings? Yes. Your content moves across into clearly labelled fields rather than being rebuilt by hand, every old address redirects to its new one so rankings and links are kept, and you end up owning the site outright, with no seat-based pricing climbing as the team grows. We’ve outgrown Squarespace or Wix. What now? Move to a site you own. Squarespace and Wix are fine until you need several locations found separately, a booking or inventory system connected, or more than the template allows. The content comes across, every address redirects, and the result is faster, yours, and built to be found. Should we fix the site we have or rebuild it? Fix it if the foundation is sound and the problems are content: wrong words, missing pages, thin locations. Rebuild if the foundation is the problem: a slow, fragile page builder, a platform that can't do what you now need, or a site so patched that every change breaks something. A free audit tells you which in days, and I'll say so either way.

Ask me about this, or anything else.

talk to the real Warren