Static vs Dynamic

TL;DR - Most people building a website for the first time have no idea they're making an architecture decision - but they are. This unit breaks down the key choices (static vs. dynamic, what a tech stack actually is) and gives you a way to make those decisions confidently, even if you've never thought about this before.

Estimated time: 30-45 minutes

Outcomes & What you'll make

By the end of this unit you'll understand:

• The difference between static and dynamic websites, and which suits your project
• What a tech stack is and what a sensible one looks like
• How to use AI to help you make technical decisions you're not sure about

What you'll make:

• A Tech Stack section added to your SITE PLAN.md

Architecture... but I'm not building a house, am I?!

Web site architecture is something most of us have never, ever thought about. And why should we? We don't think about the plumbing as soon as we enter a new building. But it matters a lot actually!

In this chapter, we're going to compare a couple of website architecture types. These are only meant to give you an idea of what may be suitable for your site.

The architecture of your site determines how site administration works as well as affecting the visitor experience. Have you ever heard of a tech stack? It's like a well-known sandwich (think, BLT, bacon lettuce tomato!) for technologies that work well together - in our case, for websites. How the technology works together and constitutes our website - is known as the architecture.

I am a designer, and absolutely not an expert on web site architecture, so how did I choose my own approach?! Do you remember Unit 2, where we let different AIs debate the best approach to a given problem? That's how I landed on my own website architecture. More on that at the end of this chapter.

Macro architecture: these matter the most

Static vs. Dynamic

90s websites didn't have much in terms of architecture. They were often isolated pages, that loaded fully - and remained as they are. You can't enter any text, fetch live updates or interact meaningfully beyond perhaps sending information through a contact form. Once you'd created your page layout, the information that goes on it.. it was all fixed, or static!

Everything changed in the past 20 years with the introduction of dynamic pages. Many modern web pages load content by fetching it from a server, and then pour it into pre-made layouts. If you have a photography website, creating a new album page would be as simple as adding a new folder of images. No need to manually adjust the web site.

So which one do you need? Here's a rough guide:

You probably want a static site if...

• Your site is mostly publishing content - a portfolio, a blog, articles
• You'll be the one updating it, and you're comfortable editing a text file
• You want it to be fast, cheap to host, and simple to maintain
• You don't need user accounts, a shop, or live data

You probably want something dynamic if...

• Other people need to update the site without touching any files (a client, a collaborator)
• You need a shop, bookings, user logins, or anything that stores information
• Your content updates very frequently and you want a proper admin panel to manage it

For most people reading this guide - a creative, a freelancer, someone building a portfolio or personal site - a static site is the right call. They're faster to build, faster to load, cheaper to host, and much simpler for an AI to help you maintain. If your use case is more complex, don't worry - that's exactly what the AI debate technique is for.

What about a CMS?

You may have heard of WordPress, Squarespace, or Wix. These are Content Management Systems - platforms that let you build and update a website through a visual editor, without touching any code. They're genuinely great for certain use cases.

But there's an important distinction worth making. Platforms like Squarespace or Wix are all-in-one - they host your site, provide the templates, and run the editor. You're working within their system, their rules, and their limitations. You can use AI to write copy or generate images, but the actual website is built inside their platform. That's fine! But it's a different guide.

The more interesting option for our purposes is a self-hosted CMS - a lightweight editing layer you add on top of your own site. Tools like Decap CMS (which I use on my own portfolio) let you manage content through a tidy browser interface, while the underlying code and files remain entirely yours. You're not locked into anyone's platform. If you ever want a collaborator or client to update content without touching a single file, this kind of setup is worth knowing about.

For now, don't worry about it too much - a self-hosted CMS is one of those things you can bolt on later, which is exactly what the micro architecture section is about. But it's good to know the option exists, because it sits in a nice middle ground between "fully DIY" and "handing over the keys to Squarespace."

The tech stack

Once you know whether you want a static or dynamic site, the next question is: what specific tools make up your stack?

For a static site, a common and beginner-friendly setup might look something like:

• A static site generator - a tool that takes your content (written in simple text files) and builds HTML pages from it. Popular options include Eleventy, Hugo, and Astro.
• CSS - for design and layout, as we covered in Unit 5.
• A hosting service - somewhere for the finished files to live. More on this in Unit 10.

You don't need to understand all of these deeply. What matters is that you have a rough idea of the moving parts, so that when you ask an AI to help you set things up, you can understand what it's suggesting - and push back if something sounds overly complicated.

Letting AI help you choose

Here's my honest recommendation: don't agonise over this alone. Open up two different AI tools - Claude, ChatGPT, Gemini, whichever you have access to - and describe your website to each of them. Share your SITE PLAN.md if you have it. Ask them: "What architecture and tech stack would you recommend for this project, and why?"

Then do something fun: take one AI's recommendation and share it with the other. Ask the second one to critique it. Do they agree? Where do they push back? You'll learn a lot from watching them disagree - and the answer that survives both tends to be a pretty solid one.

This is exactly how I chose the stack for my own site. I'm not a web developer. I didn't study this. But I described what I wanted, watched the AIs make their cases, and made a call I felt confident about. You can do the same.

Once you've landed on an approach, add a Tech Stack section to your SITE PLAN.md. It doesn't need to be detailed - just enough so that any new AI session you start knows what it's working with. Something like:

## Tech Stack

- Static site generator: Eleventy
- Styling: Plain CSS
- Hosting: Netlify
- No frameworks or app libraries unless clearly necessary

Micro architecture: useful things you can add later

The big decisions above need to be made before you build. But there are smaller additions - libraries, plugins, tools - that you can bolt on later without having to rethink the whole site. These are worth knowing about, even if you don't need them yet.

A library is a ready-made bundle of code that does a specific job. Rather than asking AI to build something from scratch, you can point it at a library and say "use this." Libraries tend to be well-tested, well-documented, and much more reliable than one-off AI-generated code for complex tasks.

A few categories worth knowing about:

Animation - If you want elements to fade in, slide around, or move in interesting ways, libraries like GSAP are widely used and well-supported. Much better than asking AI to hand-roll complex animations.

3D - If you want 3D objects or scenes on your site (think spinning product models, interactive globes, abstract visuals), Three.js is the standard choice. It's powerful, but adds complexity - worth considering whether it's truly needed.

Icons - Rather than sourcing individual icon files, icon libraries like Lucide or Phosphor give you a consistent set of scalable icons you can use anywhere on the site.

CMS add-ons - Even on a static site, you can add a lightweight CMS layer so you can edit content through a browser interface rather than a text file. Decap CMS is one option that works well with static generators.

You don't need any of these right now. But describing them to your AI - or simply sharing your SITE PLAN.md - means it can flag when one might be useful, rather than reinventing the wheel.

📄 Go ahead and open your SITE PLAN.md and add a Tech Stack section. It doesn't need to be long - just enough so any new AI session knows what it's working with.

Learning reflections

• You just made a technical decision without being a technical person - by describing your needs clearly and letting the right tools emerge from that. Where else in your work or life do you make decisions that way?
• The guide suggests using two AI tools to critique each other's recommendations. How does that change the way you think about AI advice in general?
• A static site is fast, simple, and yours. A dynamic one is more powerful but more complex. That trade-off between simplicity and capability comes up everywhere in creative work - where have you faced it before?