TIL: When a Static Site Becomes Easier Than a CMS

A client recently asked me for a landing page for their laboratory.

At first, the request sounded like a classic small website. They needed a clean page with the usual things: what the lab does, which services they offer, a few words about the team, contact details, and a way for visitors to understand whether this lab is relevant to them.

Nothing strange there.

Then the blog requirement came up.

They wanted a blog section too, but not in the way a media company or a busy marketing team needs one. The plan was to publish only a couple of posts per year. Maybe an announcement. Maybe a short update about the lab. Maybe one article explaining a service in more detail.

That changed the whole decision.

My first thought was the usual one: use a CMS. WordPress would work. A headless CMS would also work. Even a small admin panel with a database would work, if we really wanted to build one.

But then I stopped for a second and asked the boring question that usually saves time later.

What are they actually going to edit?

For this project, most of the website would stay stable for months. The landing page content would not change every week. The services would not need constant updates. The team section might change once in a while, but not often. And the blog would get maybe two or three posts per year.

So a full CMS started to feel heavy.

Not wrong. Just too much for the job.

WordPress would have solved the editing part, but it would also have added a second system to maintain. Users, roles, plugin updates, theme updates, database backups, security checks, admin settings, and all the small decisions that come with content management. For a bigger site, that tradeoff makes sense. For a small laboratory website, it felt like adding a control room to turn on one light.

That’s why I went with AstroJS.

The site itself could be fast, simple, and mostly static. Astro fits this kind of work really well because the final output is clean pages, with very little JavaScript unless you actually need it. The landing page gets the performance benefits, the structure stays easy to reason about, and the whole project remains close to normal frontend development.

For the blog, I used PagesCMS.

That was the missing piece. I didn’t want the client to open the repo and write Markdown by hand. That would be fine for developers, but not for someone who just wants to publish a short post every few months. PagesCMS gives them a friendly editing layer, while the content still lives as Markdown files in the project.

So the flow became simple.

The client writes or edits a post inside PagesCMS. PagesCMS commits the content as a Markdown file in the repository. Astro reads the content during build time. The site is rebuilt and deployed again.

That’s it.

No database. No plugin stack. No CMS dashboard that needs regular care just to keep a low-volume blog alive.

I had already worked through a similar PagesCMS and GitHub Actions setup before, where the main issue was making the publishing flow trigger the right build at the right time. I wrote about that in TIL: PagesCMS, GitHub Actions, and the workflow dispatch payload. That earlier setup helped shape this decision too, because I already knew the rough edges before choosing it for a client project.

Another nice part of this setup is content ownership.

The posts are not trapped inside a database. They are simple Markdown files. If the client ever wants to move the website, change hosting, or rebuild the frontend, the content is still there in a format that is easy to read and move around. It’s not magic. It’s just files.

That matters more than it sounds.

Small websites often live longer than expected. A landing page that starts as a quick project can stay online for years. During that time, the worst thing is not usually a missing feature. It’s maintenance that nobody wants to deal with. A static site avoids a lot of that by default.

Of course, I wouldn’t choose this setup for every client.

If the client needed daily publishing, scheduled posts, many editors, preview workflows, complex permissions, advanced media management, or multilingual content with a lot of editorial control, I’d probably pick something else. Maybe WordPress. Maybe a headless CMS. Maybe a custom admin, depending on the project.

But this laboratory didn’t need all that.

They needed a clean website, a fast landing page, and a simple way to publish the occasional article without calling a developer every time. Astro and PagesCMS gave them that without forcing the project to carry the weight of a full CMS.

The funny part is that “static” can sound limiting, especially to non-technical people. It feels like something old. In practice, it can be the opposite. The site is still easy to update, but it avoids a lot of moving parts.

That’s the thing I liked most about this decision.

The client gets a simple editing experience. I get a codebase that’s easy to deploy and maintain. The website stays fast. And nobody has to babysit a CMS for two blog posts a year.

The real question was never “CMS or no CMS?”

It was simpler than that.

How much system does this client actually need?

In this case, not much. And that was exactly the point.