A while back I went looking for the hosting bill for one of our client websites, because I wanted to check we were charging them correctly for it.
I couldn’t find it. Not because it was buried in an account somewhere - because there wasn’t one. The site had been live for years, it gets a steady stream of patient enquiries, and the entire annual cost of running it was the domain name.
That’s not a trick, and it isn’t a corner we cut. It’s just what happens when a website is actually a website.
What we mean by static
A static site is a stack of plain HTML files sitting on a server. When someone asks for a page, the server hands them the file. That’s the whole transaction.
The alternative - which is what most of the internet quietly is - is a machine that builds the page fresh every time somebody asks for it. Someone visits the “about us” page, and a server wakes up, runs a program, asks a database some questions, assembles the HTML from templates, and sends it back. Then the next person arrives and it does all of that again, for the same page, which hasn’t changed since 2023.
We still build the site the modern way. This one runs on Hugo - I write these posts in Markdown, and templates turn them into pages. The difference is when that assembly happens. Hugo does it once, on our machine, when we publish. Not eight thousand times a month on a server we’re renting by the hour.
You get all the convenience of a content system, and then you throw the engine away before it ever reaches the internet.
The bill is the headline, but it isn’t the point
Let’s do the money first, because it’s the bit people react to.
A static site is a folder of files. Any number of hosts will serve a folder of files for free, or for so close to free that it rounds down. There’s no application server, no database, no runtime, no per-seat licence, no plugin subscriptions. Most of the sites we look after sit comfortably inside a free tier and always will.
Compare that to the standard setup for the same brochure website: a virtual server, a managed database, a CDN in front of it, backups, and a stack of plugins on annual renewal. Call it somewhere between a few hundred and a few thousand dollars a year, forever, for a site that shows twelve pages of information that changes twice a year.
But here’s the thing - the hosting bill was never the expensive part. It’s the smallest number on the page.
The expensive part is attention. It’s the hour a month someone spends applying updates. It’s the Tuesday morning where the site is down and nobody knows why. It’s the plugin that stopped being maintained, the PHP version that went end-of-life, the certificate that lapsed, the database that filled up with spam comments. It’s the fact that a dynamic site is a living system, and living systems need feeding whether or not anything is happening.
A static site has none of that. There’s no server to patch because there’s no server. There’s no database to leak because there’s no database. There’s no admin login for someone to brute-force, because there isn’t one - the content lives in Git, and Git is behind our accounts, not on the public internet.
Take away the attack surface and you take away the maintenance with it. That’s the actual saving. The hosting bill is just the part you can see.
They’re absurdly fast, almost by accident
We don’t do much performance work on our static sites, and I want to be honest about why: there isn’t much to do.
The page is already built. There’s no database query to optimise because there’s no query. No caching layer to configure, because the whole site is effectively cache. The file goes out from whichever edge location is nearest the person asking. It arrives.
We’ve spent serious money and serious months making dynamic systems fast - it’s real, difficult, worthwhile engineering. It’s also work you simply don’t have to do when the answer was computed in advance. The fastest query is the one you ran last Tuesday on your laptop.
Which matters most for exactly the businesses least equipped to think about it. A specialist’s practice website is often being opened by someone anxious, on a phone, on mobile data, in a waiting room. It should be instant. With static, instant is the default state rather than something you have to go and buy.
Where we actually use them
This isn’t theory for us, it’s most of a decade of delivery.
A big chunk of our client work is static. The surgical and specialist practices we look after - ENT Group, Dr Suheelan Kulasegaran, Dr Barnaby Smith, Dr Nick Lilic and others - are Hugo sites in GitHub, built and deployed automatically on every commit. Someone approves a wording change, it’s live in about ninety seconds, and no one has to log in to anything to make that happen.
These are practices where the surgeon is the business. They do not want a content management system. They do not want a monthly platform fee, a dashboard, or a notification telling them seventeen plugins need updating. They want their information to be correct, their site to load, and to never think about it again. Static gives them precisely that, and the money they’re not spending on hosting is money spent on something that actually moves their practice.
This site is the same setup, and it’s also where we take our own medicine. When Hugo shipped a version that stopped allowing raw HTML files in the content folder by default, our build broke - a couple of our pages are hand-written HTML. It took one line in the config to fix and about ten minutes to understand. I mention it because I don’t want to sell you a fairy tale: static sites aren’t zero maintenance, they’re low maintenance. The generator still moves underneath you. The difference is that when it breaks, it breaks on our machine at a time of our choosing, rather than in production at 2am.
The bit I actually love: they make ideas cheap
Everything above is the sensible business case. This is the part I’d argue for even if the money were identical.
The cost of trying something on a static site is close to nothing, and that changes what you’re willing to try.
Back in 2020, Paul got interested in WebAssembly and built a couple of experiments - Go compiled to run in the browser, drawing to a canvas, with JavaScript doing essentially nothing. Small, curious, no client attached. We wrote it up and published the demos as static pages. They’re still sitting there six years later. They have cost us nothing to keep online in all that time, and they’ve never needed a single minute of maintenance.
Think about what that means for how you experiment. If publishing an idea requires provisioning infrastructure, it needs a justification. Someone has to decide it’s worth a server. It goes on a list, and the list is where ideas go to die comfortably - I’ve written about that list before. But if publishing costs nothing and running it forever costs nothing, you don’t need permission from anyone, including yourself. You just put it up and find out.
That’s the whole loop we try to work in. Get to something real, fast and cheap. Put it in front of a person. Learn something true instead of something you assumed.
Static is the cheapest version of that loop I know of for anything that lives on the web. Landing pages to test whether a product idea has any pull. Prototypes for a client to click through before we commit to building the expensive version. Documentation. Microsites. A one-page thing that exists for a fortnight and then doesn’t. When a failed experiment costs you an afternoon and zero dollars a month afterwards, you run a lot more experiments - and the reps are the point.
And the ones that don’t work out don’t linger as a line item on a bill, quietly making you feel bad about them. You delete the folder.
Where static stops being the answer
Now the honest part, because I’d rather you trusted the rest of this.
The moment you need to catch something, static stops being enough. The classic case is a contact form. Static sites can’t receive anything - there’s no code running to receive it. So you bolt a server onto the side of a site that was beautiful specifically because it didn’t have one, and now you own a server forever, for one form.
We hit that on every single project, solved it five different ways, and eventually built Static Contact because we were sick of it. Forms into email, no server, no database. It runs this site’s contact form and a good number of our clients'.
And when the thing is genuinely an application, build an application. FNA Manager knows who you are, pulls live data out of Xero and calculates real job costs. Client Invoices has to know which client is logged in and which invoices are theirs. You cannot pre-build those pages, because there’s a different correct answer for every person and every hour of the day. That’s a Laravel application with a real database, and no amount of enthusiasm for static changes it.
There’s also a middle ground where reasonable people disagree, and I want to be fair about it. A site with a hundred authors publishing daily needs a proper editorial workflow. A large e-commerce catalogue with live stock levels is a real system. If a non-technical person genuinely needs to add pages themselves at 9pm on a Sunday, a git-based workflow is friction we shouldn’t pretend away.
The trap isn’t picking dynamic. The trap is picking it by default - reaching for a database-driven platform for a nine-page brochure site because that’s what everyone reaches for, and then paying rent on that decision for the next decade.
The question worth asking
For most business websites, most of the time, the honest answer is that the content changes rarely and the same page gets served to everybody.
If that’s your site, you’re renting a machine to repeatedly compute an answer that never changes. It’s a bit like keeping a chef on staff to make the same sandwich eight thousand times a month, when you could have made it once and it would still be perfect.
So the question we ask at the start of every website project is a boring one, and it’s this: does this page need to be different for different people, or at different times?
If yes - great, that’s a real application, and we’ll build you one properly. If no, we should be handing people a file.
Most of the time, it’s a file.
We build both, and we’ll tell you honestly which one you need - including when the answer is the cheap one. If you’re staring at a hosting invoice wondering what exactly you’re paying for, or you’ve got an idea you’d like to put in front of real people this month rather than next quarter, come and have a chat.