Full disclosure: we’re an IT company and we built our own website. That’s either reassuring or obvious depending on your perspective. Either way, the decisions behind how we built it reflect how we think about technology generally - so it seemed worth writing up.
The short version
The site is built on Hugo, hosted on Cloudflare. There is no database, no CMS, no login page, and no server to maintain. Pages are pre-built files served directly from Cloudflare’s global network.
It’s fast. Proper fast. It scores 100/100 on Google PageSpeed across every page, on both mobile and desktop.
Why now?
Let’s put it this way: for 18 years Hayes IT had no website. We did have a site very early on but decided it wasn’t quite right so pulled that down, put up a holding page and left it up for 15 years. We started work on the site several times behind the scenes but since we didn’t really need a website - we had enough work coming in through word of mouth - the website work would get superseded by client stuff. When we then went back to build the site we’d have to apply myriad updates before we could even get working on the content again. It was so tedious. And looking back, in truth we were probably also guilty of letting perfect be the enemy of good.
Building the new site in the way we did took less than 3 weeks from initial concept to final deployment. And that included me working on the content, then learning how to properly use git, Hugo and getting Cloudflare configured. None of which was rocket science but needed attention to detail to get it all integrated correctly - and moving quickly meant less time to overthink decisions and more time making actual progress.
Why not WordPress?
As of the time of writing WordPress powers around 40% of the web. It’s capable, flexible, and has a vast ecosystem of plugins and themes. It’s also the most attacked platform on the internet, requires regular updates to core, themes and plugins to stay secure, and introduces a database and server-side PHP layer that creates both performance and security overhead.
For our site: a brochure site that doesn’t need user logins, e-commerce, or dynamic content - and where the primary goals are security, low maintenance and performance - WordPress is the wrong tool. Not because it’s bad, but because it’s solving problems we don’t have while introducing problems we’d rather avoid.
We work with web designers and agencies who build websites for their clients - many of which are WordPress based sites - and they do it very well. We even host WordPress sites for many of them. This isn’t a criticism of that choice for those use cases: it’s an explanation of why it wasn’t the right choice for us.
If you are thinking of working with us as a technical partner and you build WordPress sites for your clients - we’re not suggesting you should change and we can still support you. Your clients likely have requirements that make WordPress the right choice. But if your clients ever ask questions that fall outside your core brief - hosting, DNS, email, performance - that’s where we come in.
What a static site actually means
A static site generator takes content - in our case, markdown files and HTML templates - and builds a complete set of HTML, CSS and JavaScript files at deploy time. There’s no server processing requests, no database being queried, and no application layer that could be compromised.
When someone visits hayes-it.com, Cloudflare serves a pre-built file from a data centre close to them. That’s it. No PHP, no MySQL, nothing to exploit at runtime.
The attack surface is essentially zero. The worst someone can do is request a file that doesn’t exist.
Editing and testing locally
One of the practical benefits of this approach is that the entire site runs on a local machine during development. Hugo’s built-in development server means any change to content, templates or styles is visible in a browser within milliseconds of saving the file - no uploading, no waiting for a server to process anything. I can test tens of iterations of a page layout in minutes.
The local environment is identical to the live site. What I see on my local development platform is exactly what will appear at hayes-it.com once deployed. There are no surprises when changes go live. The worst case is some misformatted text or a typo.
We maintain a separate staging environment for template and CSS changes - these get tested there before being pushed to the live site. That should mean an end to the days of accidentally pushing breaking updates. Content additions like this post go directly to live without needing a staging step, since there’s no application logic that could break.
For a small business that wants to keep control of its own website without depending on an agency or developer for every change, this workflow is genuinely liberating. Writing a new post is no more complicated than writing a document and saving it.
The performance outcome
The 100/100 PageSpeed score isn’t something we initially aimed for - we just wanted a site that ran well. However it would also be true to say that when the site first went live and I saw unoptimised scores over 90 across the board that I decided to aim for full marks. Because, why not?
Broadly the performance is a natural consequence of the architecture decisions: we’d decided on a low image site for aesthetic reasons, no third-party frameworks or libraries loaded at render time. The only external dependency is Google Analytics, which we’ve managed to remove from the critical performance path.
But that was the start point and only got us to the 90’s. To squeeze the additional 10 points took some optimisation, removing a few dependencies and tweaking of the remaining CSS.
For context: most WordPress sites with a commercial theme score somewhere between 50 and 80 on mobile PageSpeed. Getting above 90 typically requires significant additional optimisation work and caching. Getting to 100 on a WordPress site without stripping it back considerably is genuinely difficult. And if you can then the maintenance burden at update time becomes painful.
Why does it matter? Google likes quick loading sites, so that’s one reason. But it’s also nice to have a snappy site: for visitors to click things and just have them load. And if it lends us a little extra technical credibility then there’s no harm in that either.
The maintenance reality
The site has no updates to apply. There is no WordPress core update, no plugin update, no theme update. There are no excess hosting bills for a managed WordPress host. There’s no theme or plugins to renew each year.
Content changes - like this post - are written in markdown, committed, and deployed automatically within 60 seconds. No CMS login, no editor interface, no database backup to worry about.
What this reflects about how we work
We didn’t build the site this way to be clever. We built it this way because after a bit of research we discovered it was the right tool for the job.
A lot of technology decisions in IT - for websites, for infrastructure, for software - are made based on familiarity, inertia, or the path of least resistance rather than what the situation actually requires. WordPress gets chosen for brochure sites because everyone knows WordPress. Expensive on-premise servers get renewed because they’ve always had on-premise servers. People stick with Windows because it’s a known solution.
We try to start from the requirements and work outward to the solution, rather than starting from a solution and fitting the requirements around it. Sometimes that leads to the obvious choice. Sometimes it leads somewhere less expected.
In this case it led to a more secure, faster, cheaper-to-run website than we’d have had otherwise.