Building the Sustainable Web How to Create Web Products That Respect People and the Planet

Where were we? Right. Slack notification. A meeting this afternoon. New features to discuss.
Another AI-for-the-sake-of-AI feature, for sure. You close the notification and open the invite. Eight people. The usual names. Someone saw something cool somewhere. Now it is on the roadmap.

You used to push back. You asked whether it had been validated. You raised your hand. At some point you stopped. Not because you stopped caring. Because you got tired of being the person who cared.

The reason you cared has not gone anywhere. You got into this work to build things that actually help people. This book is about how much further that goes than anyone told you.

Chapter 3 is about the decisions that happen before the sprint starts. It asks the question you stopped asking and gives you the argument for when you need to bring it back. Chapter 1 shows you what product decisions cost at scale and the case that tends to move the people around you. Chapter 2 gives you the tools to start estimating that cost. Imperfect, but more than most teams currently have.

Where were we? Right. Slack notification. A meeting this afternoon. New features to discuss.
You already know what the brief will look like. A screenshot or two. Maybe a link. The words "something like this, but make it ours."

You always loved the complexity of design and the psychology beneath it. Why people click where they click. Which emotions can colors raise in people. But it has been years since you had the time to actually research any of that. Now that you think about it, you were never given that time, or space to talk to real users. What you always got were screenshots and a deadline. "More animation," they say. "More movement. Make it feel alive." And you do it.

But you know the difference between a design built for a real person and one built for a conversion metric. You know it when you see it. You hate making it. You used to fight. Now you just send the Figma file.

You got into this work to understand people and build things that actually work for them. That part has not gone anywhere. Chapter 6 is where we bring it back.

It expands who you are designing for. Not just the target user the brief described. Everyone around them. The person on a slow connection. One hand free, battery at 8%, trying to get something done. Not as edge cases. As the actual scope of the work. The questions this chapter asks are ones you already had. What it gives you is the argument for why they belong in the room before anyone writes that brief.

Chapter 3 gets you into that room. It covers the decisions that happen before design starts. Whether something needs to exist, who it actually serves, and how to make the case when the answer is uncomfortable. That is where your instincts have always been pointing.

Chapters 7 and 8 show you what your work becomes after you send the file. What the developer inherits from every animation choice, every asset decision. What the content team builds on. That context changes every decision you make and what you include in the final_final_v3.

Where were we? Right. Slack notification. A meeting this afternoon. New features to discuss.
You already know what that means. Another service to run. More containers to provision. A new database someone scoped in a product meeting without asking what it would sit next to, how it would scale, or what it would cost to maintain six months from now.

You were not in that meeting. You find out when the ticket arrives.

Nothing you build is visible to the people who commissioned it. When the system is stable, nobody notices. When it goes down, you are the one to blame.

You carry the cost of every architectural decision made above you. The new workload nobody asked you about before adding it. The services that kept running through the migration because nobody scheduled the cleanup. The cloud bill went up again this quarter. You know what this looks like. You have cleaned it up before. You know, and you fix it, and six months later the same thing happens somewhere else.

You have always called this waste. You were always right. It costs more than the cloud bill, and more than just your employer. You are the only person on the team who actually knows where to find it. And probably how to fix it.

Chapters 4 and 5 give you the full accounting of what you have always been managing. Chapter 4 turns your hosting decisions into a conversation you can have: not just which region is cheapest, but which is cleaner, and how to make that case to the people who sign off on infrastructure budgets. It gives you the tools to measure what your containers actually consume and the language to bring right-sizing into conversations where it has always been treated as optional. Chapter 5 is the code running on that infrastructure: it makes your language choices, your caching strategies, your architectural decisions legible in terms that go beyond performance and belong in architecture reviews, not just your own head. Chapter 9 is for the next time someone hands you a ticket to integrate an AI feature. It gives you the honest accounting to evaluate whether the workload is worth running, and the grounds to push back when it is not.

Where were we? Right. Slack notification. A meeting this afternoon. New features to discuss.

You already know what this one will look like. A screenshot from somewhere. "Can we do something like this?" The answer is always yes. What will not be in the room is any conversation about what that feature costs to ship, what it adds to every user's device, whether the third dependency it needs is worth the weight.

You notice these things as a reflex. The bundle that grew again last sprint. The script that fires on every page and has been there for two years because nobody knows who added it. The image loading full-resolution on mobile because nobody specified it otherwise. You raise it. In standup, in a PR comment, sometimes just quietly to yourself on the way out. Nobody puts it in a ticket. Nobody estimates the time it would take to do it properly.

You raised it because you know what ends up on the other side. What a bloated bundle means for the person on a slow connection, on a device two generations old. That has not gone anywhere.

Chapter 7 takes what you already know and gives it weight. The JavaScript audit questions, the third-party scripts nobody owns, the image and font decisions that compound across every page view at scale. This is the technical argument for every call you have been making on instinct. The unused JavaScript you have been fighting translates into energy use, into CO2 at scale. You were already solving the right problem. This chapter gives you the frame.

Chapter 2 is the measurement layer. What a dependency costs per page view, what an unoptimized image multiplies to at scale, what a third-party script adds to every user session. Your instincts already know something is wrong. This chapter gives you the numbers to say how wrong, and to whom.

Chapter 3 shows you the decisions that were made before the ticket reached you. Not to relitigate them. To understand them. And to know which conversation to have earlier next time.

Chapter 6 shows you what the designer was thinking when they sent that Figma file. What they were optimizing for. What they did not know would happen in your code.

You got into this because something on the screen changes when you tell it to. That is still the best part. This book is about making sure it is worth every kilobyte.

Where were we? Right. Slack notification. A meeting this afternoon. New features to discuss.

You already know what that means. New feature needs a campaign. Keywords to target. Posts to schedule. You will produce them. You are good at it. And somewhere in the process you will wonder, briefly, whether the person at the other end is going to find what they were actually looking for, or whether you built something for Google and dressed it up.

You went into this work because you believed in connection. In finding the right words for the right person at the right moment. Then came the frameworks. Post every day. Post twice a day. Optimize for the algorithm. Be consistent. Be findable. The person who just wanted to make dinner had to scroll through eight paragraphs about someone's grandmother's garden before finding the recipe, because that is what search engines rewarded. You learned to write for robots and call it content strategy. The whole industry did.

You publish because the system needs feeding. You add the tracking scripts because that is how you measure things. You watch the dashboards because that is what you report on.

The question of whether any of this needed to exist stopped feeling like something you were allowed to ask.

Chapter 8 gives you permission to ask it again.

It treats content as what it actually is: a living system that needs pruning as much as growth. What to publish, what to update, what to let go. Not because you ran out of ideas but because intentional is better than constant. Chapter 3 gets you upstream, into the conversation before the brief is written: whether a campaign needs to exist, who it actually serves, how to make the case when the answer is no. Chapter 9 is for the next time someone suggests using AI to scale output. It gives you the honest accounting of what that costs, and the grounds to push back when the cost is not worth it.

Where were we? Right. Slack notification. A meeting this afternoon. New features to discuss.

You will be there. You have already thought of three things they will not have considered. You will mention one of them. Someone will say good point, and the conversation will move on. The decisions will get made without you, in the room you are sitting in.

You are the last person to see the thing before it reaches a real user. You find what everyone else did not think to specify. You add your questions to the ticket comments. Sometimes someone answers. Sometimes the sprint starts anyway.

At some point you stopped mentioning the other two things.

There is no dedicated QA chapter in this book. That is not a gap.

To test a product well, you need to understand what it was built to do at every layer. Not just the happy path in the acceptance criteria. What the infrastructure was designed for. What the code was optimised for. What the design was solving for. What the content was supposed to do for a real person on the other end.

This book is that understanding, layer by layer. After you read it, you will have the definition of done that nobody gave you. And you will know exactly where to look for what did not hold.