Lesson 0.2 · 8 min read
Let me start with a confession that most designers feel but rarely say out loud.
When you build a beautiful prototype in Figma, wire up the screens, and click through it, part of you thinks: this is basically the app. The hard part is done. Someone just needs to make it real now. And then you hand it off, and weeks go by, and you quietly wonder what could possibly be taking so long. It looks finished. What's left?
The answer to that question is the single most important idea in this entire module. There's a line that runs through all of software, and it separates two kinds of things that look identical from the outside but are built in completely different ways underneath. That line is the difference between static and dynamic.
Once you see it, you can't unsee it, and a huge amount of confusion about "why is this so hard to build" simply dissolves.
Picture two coffee shops on the same street.
The first one has a menu painted on the wall. Beautiful hand lettering, fixed prices, the same list every single day. Every customer who walks in sees exactly the same menu. If the owner wants to change a price, someone has to get a ladder and repaint the wall. The menu is gorgeous, and it is completely frozen. It shows the same thing to everyone, forever, until a human physically changes it.
The second shop looks similar from the doorway. But its menu is on a screen behind the counter, and it's alive. Prices shift based on the time of day. Sold-out items grey out on their own. When you walk in as a regular, it greets you by name and shows your usual order at the top. The person next to you sees something different, tailored to them. Nobody is repainting anything. The menu is being assembled fresh, per person, per moment, out of information the shop is constantly tracking.
The first shop is a static experience. The second is dynamic. And that is the whole idea, in its purest form. A static thing shows the same content to everyone and only changes when a human goes in and edits it. A dynamic thing generates its content on the fly, potentially different for every user and every moment, out of live data.
Your Figma prototype is the painted wall. It is static, always. It looks like the second shop, but underneath, it is absolutely the first one. And the gap between those two shops is most of what "making it real" actually means.
Let's be precise, because precision here pays off everywhere later.
A static page is a file that already exists, complete, before anyone asks for it. When a visitor requests it, the server does something almost trivial: it finds the finished file and hands it over, unchanged. No thinking, no assembling, no looking anything up. Like grabbing a pre-printed pamphlet off a shelf and passing it across the counter. Every person who asks gets an identical copy of that same pamphlet.
This is not a weakness. For the right job, static is wonderful. A company's landing page, a blog post, a documentation page: these are the same for everyone, so serving them statically makes them blisteringly fast and almost impossible to break. There's nothing to compute, nothing to query, nothing that can go wrong in the moment. The work all happened earlier, once, when the file was created. At request time, it's just handing over a finished thing.
The defining trait, the thing to hold onto: with static content, the work happens before the request, and the result is the same for everyone.
A dynamic page does not exist yet when you ask for it. It gets built, on demand, in the moment of your request, specifically for you.
Think back to the last post, to Instagram. When you open your feed, there is no pre-made "your feed" file sitting on a shelf. There couldn't be. It would be stale the instant it was made, and there would need to be a separate one for every one of a billion users. Instead, the moment you ask, the server springs into action. It figures out who you are, looks up who you follow, pulls their recent posts from the database, orders them, and assembles a fresh feed that has never existed before and will never exist in that exact form again. The next person's request builds something entirely different. Your own request a minute later builds something different again.
That is dynamic. The work happens at the moment of the request, and the result is specific to who's asking and when. This is why the last post spent so much time on the server and the database. Those two exist almost entirely to serve dynamic content. A purely static site barely needs them. The moment your product needs to show different things to different people, or reflect information that changes, you've crossed into dynamic territory, and you've taken on everything that comes with it.
Here's why this distinction isn't academic. Almost every meaningful jump in difficulty when building a product comes from crossing this line, and you can predict that difficulty in advance once you can see it.
A prototype can fake dynamic. A product has to actually be dynamic, and that's the whole ballgame. In Figma, to show a logged-in user's name, you type their name into a text layer. It looks real. But you typed it. There's no logic there, no source of truth, nothing that would work for a second user. To make that same thing real, something has to store that this user exists, know they're logged in, retrieve their actual name, and place it there, every time, for every different user, correctly. The visual result is identical. The thing underneath is the difference between a drawing of an engine and an engine. This is precisely why handoff takes so long. You designed the appearance of a dynamic system. Making it genuinely dynamic is the large, invisible remainder.
Dynamic means you need somewhere to keep the truth. A static site has no memory. It doesn't need one, because it shows everyone the same frozen thing. The instant your product needs to remember anything, a user's account, their posts, their settings, yesterday's order, you need a database, the system built to hold that truth and hand back the right slice of it on demand. This is the moment a "website" becomes a "web application," and it's not a small step. It's the step. Almost everything you'll build as a design engineer lives on the dynamic side, which is exactly why databases get their own full module later.
Dynamic introduces something that can't exist in a static world: state. State is just the current condition of things, the stuff that's true right now and can change. Are you logged in or out? Is your cart empty or full? Is that post liked or unliked? Has this message been read? A static wall menu has no state; it's the same regardless of anything. A dynamic product is drowning in state, and here's the uncomfortable truth: most bugs you'll ever chase are really state going wrong. The cart that shows the wrong total. The screen that says logged out when you're logged in. The like that doesn't stick. When you understand that dynamic products are fundamentally about managing state, and that state is slippery, you understand where the real difficulty of software actually lives. We'll return to state many times, because it's that central.
Dynamic costs more, everywhere. Static is cheap because the work was done once, up front. Dynamic does work on every single request: thinking, looking up, assembling, per user, per visit. Multiply that by millions of requests and you have real costs in server power, in speed, in complexity, in the number of things that can break. This is why good engineers are almost stingy about it. They ask a sharp question constantly: does this genuinely need to be dynamic, or can it be static? A product that's static wherever it can be and dynamic only where it must be is fast, cheap, and sturdy. One that's needlessly dynamic everywhere is slow, expensive, and fragile. Knowing where to draw that line is a real engineering skill, and it starts with being able to see the line at all.
I've drawn static and dynamic as two shops for clarity, but real products aren't one or the other. They're a deliberate blend, and learning to see the blend is what turns this from a concept into a tool you use.
Look at an online store. The homepage banner is the same for everyone this week, so it's served static, fast and cheap. A product's description and photos rarely change, so those lean static too. But the price might flex with a live sale, your cart is unique to you and changes as you shop, and the "recommended for you" row is assembled fresh from your behavior. Those are dynamic. One page you think of as a single thing is actually a careful mix, static where it can be, dynamic where it has to be, and someone decided each of those, on purpose, based on exactly the trade-offs we just walked through.
That someone is you now, or it's about to be. When you look at a screen and can instinctively feel which parts are frozen and which parts are alive, you've stopped seeing a flat picture and started seeing the machinery. You can look at a feature and know, before writing a line of code or a line of a prompt, roughly how hard it will be, whether it needs a database, whether it introduces tricky state, and what it'll cost to run. That instinct, more than almost anything else in this module, is what separates someone who assembles software from someone who engineers it.
Do this before the next post
Pick an app you use every single day. Open it, and slowly go through one screen, pointing at things in your head, sorting each one into static or dynamic.
The logo? Static, same for everyone. Your name in the corner? Dynamic, it knows who you are. The navigation labels? Almost certainly static. The number badge on your notifications? Dynamic, and changing in near real time. The main content, your feed, your inbox, your dashboard? Deeply dynamic, built fresh for you the moment you arrived.
Do this for two minutes on one real screen. What you're training is the exact instinct we just described: the ability to look at any interface and immediately feel its machinery underneath. Once you can do it without thinking, you're reading products the way an engineer does, and every later post in this series is going to land differently because of it.