Why we still build most marketing sites as static sites
Every year someone tells us static sites are a phase. Every year most of the marketing sites we ship are still static HTML behind a CDN, and the clients who chose that route are the ones who call us least. This note explains the reasoning, and the cases where we deliberately do something else.
What "static" means for us
The content lives in a headless CMS or in Markdown files. A build step turns it into plain HTML, CSS and a small amount of JavaScript. The result is uploaded to object storage or a CDN. There is no application server waiting for requests, no database that can be slow, and no admin panel exposed to the internet.
Why it keeps winning
- Speed by default. A pre-rendered page served from the edge is fast on a cheap phone on a bad connection. We do not have to work for that; we have to work to break it.
- Almost nothing to attack. The most common support call we used to get was "the site is hacked". With static output there is no plugin to exploit and no login form to brute-force.
- Boring hosting. Bandwidth is cheap, uptime is somebody else's problem, and a traffic spike from a TV mention costs a few cents, not an outage.
- Clean handover. The client gets a repository, a build command and a short document. Any developer can pick it up in an afternoon.
Where we do not use it
Static is the wrong answer when pages depend on the visitor: logged-in areas, carts with live stock, prices that change per customer, search over thousands of records. For those we build a proper application or put a small API next to the static site. The key is to keep the dynamic part as small as it can honestly be.
The CMS question
Clients do not care about build pipelines; they care about editing a page without calling us. We pair the static output with a hosted CMS that has a friendly editor and a preview. The editor saves, the build runs, the site updates in a minute or two. For very small sites we skip the CMS entirely and edit Markdown together during the monthly maintenance call.
Takeaway
If your site is mostly content and forms, start static. If a feature really needs a server, add exactly that feature, not a whole platform. It is less exciting than the alternatives, and that is the point.