Static first, headless always: how we choose the stack

Why Synora sites are built as static output with a headless CMS, when we reach for a framework with a server, and how the editors get a say before the decision is made.

The Nordlys clinic booking homepage, built static-first with a headless CMS.
Fig. 01 · The Nordlys clinic booking homepage, built static-first with a headless CMS.

Every stack decision at Synora starts from the same question: who edits this, how often, and what happens when it breaks at 11pm on a Saturday.

For most companies the honest answers are a marketing team, a few times a week, and nobody wants to be on call. That points to a static site: HTML generated at build time, served from a content network, with no server to patch and nothing to hack into. The Nordlys clinic network runs 14 locations and 2,300 bookings a month on exactly that, with the booking flow handed to a specialised provider behind an API.

What “static first” means in practice

The site is built by Astro. Content lives in a headless CMS chosen with the editors in the room, never before. Images are converted to WebP before they reach the repository and resized at build. Every page is a file, cached at the edge, and a bad deploy is rolled back by pointing at the previous build.

Dynamic pieces, when they exist, are isolated. A search index generated at build and filtered in the browser. A contact form that posts to a provider. A booking widget that loads only on the pages that need it.

When we do not go static

Sometimes the product is the site. A treasury dashboard like Ferrule has authenticated users, live data and a permissions model. That is an application, and we build it with a framework that runs on a server, with a different budget and a different on-call arrangement.

The rule is not “always static”. The rule is “static unless the requirement that prevents it is written down”. Most requirements that seem to prevent it, such as a newsletter form, a filterable catalogue or a multilingual site, do not.

How the editors choose the CMS

In week two of Design, the people who will write the content spend a morning with three candidate systems and their own text. They publish a page in each. We watch, we do not help, and we count the questions.

The system they choose is the one we integrate. We have shipped with five different headless CMSs for that reason, and we would rather learn a sixth than force a team into a tool they resent.

What this buys the client

A site that costs almost nothing to host, cannot be defaced, and loads in about a second on a phone. Editors who were trained before launch, not after. And an infrastructure that we can explain on one page of the proposal, because there is not much of it.

Written by

Priya Raman

Cloud architect

Priya keeps the sites online and the editors calm. She writes about hosting, headless content models and the boring infrastructure decisions that prevent exciting incidents.

All articles by Priya →