Static-first: why our marketing sites don't reach for a framework

Most new marketing-site projects start with the same question from the client: "What framework will you build this in?" And usually, the more useful question is the one we ask instead: "Does this page need to compute anything?"

If the honest answer is no, we build it static. This post explains why, and where the line is.

#The default is not a framework

The marketing pages of a typical business do a small number of things:

• present information
• link to other pages
• collect contact details
• maybe integrate a booking calendar or a checkout

None of those require a client-side renderer. Serving pre-rendered HTML from a CDN satisfies all of them, with fewer moving parts than the smallest React setup.

What a framework buys you is dynamism: data that changes per-user, interactive UI at scale, and complex state. A marketing site almost never has those. When you add a framework without needing it, you pay for it in four ways:

1. JavaScript shipped to the browser — a bundle that must parse and execute before some pages can show anything at all.
2. Runtime risk — hydration bugs, version churn, and more surface area for security issues.
3. Build complexity — Node version constraints, lockfile conflicts, and deployment steps that don't exist for plain assets.
4. Longer iteration cycles — every visual tweak travels through a build pipeline.

#The decision framework we use

Before reaching for a tool, we ask ourselves four questions:

• Is the content read, not edited? A blog, a brochure, a documentation site — static generation is the right tool.
• Does the page depend on the reader? If the HTML changes based on who's looking, you need a server or client-side logic.
• Are we building a product or a page? An authenticated portal is a product. A landing page is a page. Don't build the first with the tools of the second.
• Can we measure the downside? The cost of a static site is the cost of a rebuild when content changes. With a small content model, that cost rounds to zero.

When any of the first three answers point toward the application side, we switch tools — but we switch deliberately, not by default.

#What "static" actually buys you

Serving files instead of rendering HTML per request has two practical effects that matter to a business:

Caching is trivial. A static asset can be cached aggressively at the edge with a max-age and immutable header. Meaningful performance gains don't come from micro-optimizing JavaScript — they come from not forcing the network to do work twice.

The deploy is boring. Changing a page means regenerating HTML and pushing files. There is no blue/green dance, no migration risk, no "the deploy broke something" fear that makes teams avoid shipping.

#Where we stop being static

The static-first approach has a hard boundary: anything that mutates state. Booking a call, submitting a form, checking out — that's where the server has to exist.

Here's the important nuance: a static site can talk to a server without stopping being static. Your pages are static; your endpoints are dynamic. The HTML never waits on a database query — the interactive bits call an API only when the visitor triggers them.

So the architecture of a modern marketing site is:

• Static HTML, CSS and a little vanilla JavaScript — shipped from the edge, cached forever, rendered instantly.
• A thin API layer — does exactly the mutations the page needs (lead intake, search, checkouts).
• A strict content pipeline — markdown in, validated, generated, agreed-upon URLs out.

#The uncomfortable truth

The reason a lot of agencies reach for a framework on a brochure site often has little to do with technology. In many cases it's because React and Next.js are what the marketplace recognizes, and "we wrote HTML" doesn't sound like work.

It is work — skilled work. Semantic, accessible, well-typed markup is hard to write and easy to get wrong. But it doesn't need a JavaScript runtime to serve.

A framework is a tool for a job, not a badge of quality. The best runtime for a marketing page is usually nothing at all.

We built this blog the same way — you can read exactly how in our next post.