Static site or dynamic site? Which one is right?

A friend of mine was about to have a showcase site built. He’s a construction engineer; he’d put up photos and videos of the villas and housing projects he’s finished, and he also shares them on Instagram. Someone had told him “use Supabase or Firebase in the back.” When he asked me, I said “you don’t need it,” and we argued about it for a good while.

This post is the tidied-up version of that argument: for a site whose content is mostly fixed, should you go static or dynamic? I’ll walk through how I decide, and when each one is the right call, with examples. My goal isn’t to say “this technology is the best” — because the question isn’t which one is better, it’s which one fits your job.

Let me give the short answer up front: for sites where most of the content stays fixed — a portfolio, a showcase, a blog — a static site is enough; it’s cheaper, faster and more secure. But the word “static” brings a few misconceptions to mind, and the real work is clearing those up.

What is a static site, what is a dynamic site?#

Before deciding, let me make these two words clear, because the names are confusing.

A static site builds all of its pages once, while I’m preparing the site, and keeps them as ready-made files (HTML). When someone visits, the server sends that ready file as-is; it calculates nothing on the spot, looks at no database. The page is already prepared.

In a dynamic site, the page isn’t prepared in advance. Every time someone visits, the server builds the page on the spot: it pulls the data from a database, assembles the page, then sends it. So a program runs in the back on every visit. WordPress, for example, works this way.

The difference matters right here:

• In static, there’s no running program or database; the site is just ready-made files. That’s why it opens very fast, hosts very cheaply (often for free), and there’s nothing to hack — there’s no server to take over, no database to steal.
• In dynamic, a server and a database run in the back for every visit. This is necessary if the content genuinely changes on the spot (logged-in users, orders, different content for everyone…), but in return it means a system that runs constantly and has to be maintained and secured.

And let me say this up front, because the biggest misconception is here: static does not mean “can’t be changed later.” It only means “the page is produced beforehand, not at visit time.” I’ll open this up in the next section.

”Static” doesn’t mean old#

When people hear “static,” most picture the 2010s sites where you hand-wrote HTML and pushed it to a server. They assume “static = you can’t change it again, you’ll fiddle with files one by one for every change.” That’s not how it is today.

Modern static site generators (like Astro, Hugo) work like this: you write your content, then the site rebuilds itself from scratch and gets published. When I add a new post to this blog, all I do is write a file and push it:

# add the new content, push — the system handles the rest
git add .
git commit -m "new project: Villa X"
git push

That’s it. Within a few minutes the new content is on the site. I don’t log into a server and fiddle with anything, I don’t move any file to a server by hand.

So the word “static” is true about the site’s output (the visitor gets a ready page), but you can change the content as much as you like. They’re two different things. Being static doesn’t mean being unchangeable.

First, ask this question: is the content fixed or changing?#

Before thinking long and hard about static vs dynamic, one question is usually enough: is the site’s content fixed, or does it change constantly?

Fixed content means what you put stays as it is — you add a new one now and then, but the page looks the same to everyone. A portfolio, a showcase site, a blog, a menu… all like this.

Changing content is content that varies per visitor or on the spot: logged-in users, a cart and orders, a panel personal to each person, a live list (stock, price, reservations)…

What’s on my friend’s site? Photos and videos of the projects he’s finished. So the content is fixed — when a new villa is done, one more project gets added, that’s all. There’s no user account, no order, no data that changes on the spot. So he doesn’t need a dynamic system; because the problem dynamic solves never even comes up on his site.

What about ready-made systems like Firebase or Supabase?#

I used Firebase as an example here, but it’s not the only one — there’s Supabase, Appwrite, PocketBase, and plenty more like them. Some are paid, some cheap, some free. But which one you pick, or how much it costs, isn’t the point. For this job the result is the same with all of them: you’re adding to a fixed-content site an extra system you have to constantly maintain, update and secure. Being free doesn’t change that — “free” doesn’t mean “necessary.”

So what exactly do these systems do? In short: they give you a database (where the content lives), a file store (images/video) and a login/session (user accounts). Useful things — but all parts of a dynamic site. If your content is fixed, you need none of them.

There are two concrete headaches, too:

• Bill surprises. Most of these services charge “by usage”: the more data gets downloaded, the more you pay. Since a portfolio site is heavy on images and video, once a little traffic comes in the bill can turn out higher than you expected. The same applies once you cross the limit on the ones with a free tier.
• Security. The moment you have a database, you have to configure it correctly. Setting these services’ access rules wrong is one of the most common causes of data leaks on the internet. With static there’s no such worry, because there’s no database to configure.

So who updates the content, and how?#

The one point where critics of static sites are right is this: how will someone who doesn’t know code update the content? The answer depends on who’s doing the updating.

If you’re updating it (and you’re not afraid of file work): you write the content as a plain text file and push it, and the site rebuilds itself. My own site is like this — there isn’t even a panel, I write the file and push. For a technical person, this is the simplest way.

If someone who doesn’t know code is updating it (like my engineer friend): you add a management panel to the site. The general name for these panels is “Headless CMS.” The name sounds technical but the idea is simple: a panel that lets you manage the content (add a post, upload a photo) but doesn’t touch the site’s appearance. The “headless” in its name says exactly that: the site’s visible face — its “head” — isn’t in this panel; Astro draws that, you just enter the content.

“Headless CMS” isn’t a single product, it’s a category; there are different brands under it. The two that work best with Astro are these:

• Keystatic: the closest to Astro. It installs right inside the site and works in tune with Astro’s content structure. There’s a team (a company) behind it, so it’s maintained regularly; the panel is clean and modern.
• Sveltia: a light and fast panel. Since it’s the modern version of the long-used Netlify/Decap CMS, anyone familiar with that tool sets it up easily.

Both are free, and the usage is the same in both: the person logs into the panel, says “new project,” drags in the photos, writes the description, hits “publish.” In the back the panel writes this content to the site’s files and the site rebuilds itself — but the person using it sees neither code nor files.

Most importantly: this panel keeps the site static. So you get both an easy management panel and a site that’s still fast, secure and free; you don’t have to move to a dynamic system or a database.

Where do I put this site?#

I said “static hosts for free”; but where exactly? There are a few places that host static sites for free — the best known are Cloudflare Pages, Netlify and GitHub Pages. All three work the same way: you connect the site to a code repository (like GitHub), and every time you push content they build and publish it themselves. Normally, for a site you’d either buy monthly hosting, or rent a VPS/VDS or a server; here you need none of those, and there’s nothing to set up.

I host this blog on Cloudflare Pages. When I push a new post, within a few minutes it rebuilds and publishes the site; and it distributes the content across its own network so it opens fast from anywhere in the world. I don’t pay anything for hosting.

What about photos and video?#

A portfolio site’s real weight isn’t text, it’s the images. Keeping them in the right place matters.

Photos will be many and high-resolution. You need to compress them (small but sharp) and serve them that way; Astro can do this itself — it produces the right size for each screen and doesn’t weigh the page down needlessly. If the number of photos grows a lot, you can put the files in a cheap store like Cloudflare R2 (free up to a limit).

For videos the most important advice is this: you don’t need to host the video yourself — in fact, don’t. Video is a heavy file; on every play it both slows the site down and (on those usage-based services) inflates the bill. Instead you upload the video to YouTube or Vimeo and embed it into the site. My friend already posts his videos to Instagram anyway; so the videos live somewhere else from the start, and only a link comes to the site. This is independent of the static-vs-dynamic debate: video is done this way regardless.

But I need a contact form — isn’t that dynamic?#

A portfolio site often wants a contact form: “your name, your message, send.” At first glance it looks dynamic — the form is sent, it has to reach somewhere. But you don’t need to set up your own database or server for this either.

There are two simple ways:

• Ready-made form services (like Formspree, Web3Forms): you add a few lines to the form, and when a visitor fills it in and sends it, the message lands straight in your email. There’s no server or database of yours running in the back; their service does the work. Most have a free tier too.
• Without even a form: for most cases a click-to-message WhatsApp button or an email link is even more practical. For a construction guy, say, WhatsApp is worth its weight in gold.

So a “contact form” isn’t a reason to turn a static site dynamic either.

When is dynamic actually needed?#

I’ve been describing static up to here, but dynamic sites aren’t bad — they’re just for a different job. If one of these is the case, a dynamic system (and a database) really is needed:

• User accounts: people sign up, log in, everyone sees their own content.
• E-commerce: cart, orders, payment, stock tracking.
• Data that changes on the spot: live prices, a reservation calendar, a constantly updated list.
• A big site where many people constantly enter content.

I’m not against dynamic; I’ve been building sites with WordPress for years too, and for most jobs WordPress is a perfectly right choice (I wrote separately about why I still built this blog with Astro instead of WordPress). The point is this: if none of the needs above exist, a dynamic system isn’t a benefit to you, just extra weight. None of them exist in my friend’s portfolio — so, static.

Summary: how I decide#

The decision really comes down to a single question:

Will the site’s content mostly stay fixed, or will it constantly change?

If the answer is “fixed” — like a portfolio, a showcase, a blog — build a static site. It’ll be faster, cheaper (often free) and more secure. Two extra notes:

• If someone who doesn’t know code will update the content, add a management panel (a Headless CMS — like Keystatic or Sveltia) to the site. The site still stays static.
• If there’s video, don’t host it yourself; put it on YouTube or Vimeo and embed it.

If the answer is “changing” — like user accounts, orders, data that changes on the spot — build a dynamic site and set up the database. A static site can’t do these; here the server and database that dynamic brings aren’t wasted, they’re exactly what the job needs.

The result for my friend’s site: a static site with Astro, a management panel for updates, videos on YouTube. Monthly cost is nearly zero, the site opens fast, there’s nothing to hack, and the engineer adds his content himself. Where “Firebase is a must” was claimed, none of it was actually needed.