Zawinski’s Law states that every program attempts to expand until it can read mail, and those programs which cannot so expand are replaced by ones which can. It was articulated by Jamie Zawinski — Netscape developer, Lisp hacker, and eventual nightclub owner, which is what happens when you understand software entropy well enough to seek employment in a field where the buildings stay the same size.
The law is not literally about email. It is about the irresistible gravitational pull toward feature expansion — the force that turns a text editor into an operating system, a to-do list into a project management suite, and a notes indexer into a blog platform with a satirical encyclopedia and AI-generated watercolour illustrations.
Every program begins with a clear purpose. Every program ends with a settings page.
“It’s not over-engineering if the factory can BUILD it!”
— The Caffeinated Squirrel, articulating the engine of Zawinski’s Law in a single sentence, The Idle Factory, or The Morning the Backlog Ran Out of Ideas
The Law
The original formulation, from Zawinski’s personal website circa 1998:
“Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones which can.”
The law describes two forces:
-
Internal pressure. The developers who build the program imagine new features. Each feature is reasonable in isolation. A calculator could use a history log. A history log could use export. Export could use email. The calculator now reads mail. No single decision was wrong. The trajectory was inevitable.
-
External pressure. Users request features. Competitors add features. The market rewards features. The program that does one thing well is replaced by the program that does twelve things adequately, because adequacy across twelve dimensions is more marketable than excellence in one.
Between these two forces, the program grows. Not because anyone chose growth. Because growth is the default, and restraint — the decision to not add the feature — requires an act of will that most organisations are structurally incapable of performing, because organisations have roadmaps, and roadmaps have Q3, and Q3 needs a deliverable, and the deliverable is a feature, and the feature is email.
The Emacs Proof
The canonical demonstration of Zawinski’s Law is GNU Emacs.
Emacs began as a text editor. It is now: a text editor, an email client, a web browser, a file manager, a terminal emulator, a calendar, a calculator, a psychiatrist (M-x doctor), a Tetris game, and a Lisp runtime that happens to edit text as one of its features.
Emacs did not choose to become an operating system. Emacs expanded into one, driven by Zawinski’s Law and the Lisp evaluation loop, which makes adding features as easy as adding parentheses, and parentheses — as any Lisp programmer will tell you, at length, for hours — are infinite.
The counterargument is that Emacs is good at all of these things. This is true and irrelevant. The law does not say expansion is bad. It says expansion is inevitable. The quality of the expansion is orthogonal to the fact of it.
The V3 Saga
The lifelog contains an extensive field study of Zawinski’s Law, documented across twenty-three episodes and one very tired developer.
A system called V2 existed. It served HTML. The client accepted HTML. hx-swap-oob handled updates. It worked. It was boring. It had worked, boringly, for two years.
Then expansion began.
Reactive signals. Web components. SolidJS evaluations. Component lifecycle management. Signal namespacing. A custom morphing algorithm. An npm package. A 7-layer trust fabric.
“Reactive signals are wonderful. But you’re using a sports car to plow a field.”
— The Lizard, The V3 Saga Final Chapter - Is It Fun To Fight Windmills
Each addition was individually reasonable. Reactive signals are a legitimate pattern. Web components are a legitimate technology. Component lifecycles are a legitimate concern. But the accumulation — the inevitable expansion from “server sends HTML” to “client manages state via reactive signals with component lifecycle hooks and namespace-scoped bindings” — was Zawinski’s Law in action. The program was attempting to expand. It was attempting to become a framework. Given enough time, it would have attempted to read mail.
V4 returned to V2’s patterns. The expansion was reversed. This is rare. Most programs cannot unexpand, because features, once added, acquire constituencies — users who depend on them, developers who maintain them, product managers who cited them in roadmaps. Unexpansion requires the willingness to disappoint every constituency simultaneously, which is why it almost never happens, and why the programs that do it are usually maintained by one person who can disappoint himself without scheduling a meeting.
The Manifesto Acceleration
The most concentrated expression of Zawinski’s Law in the lifelog was written at 2 AM on November 14, 2025.
827 lines. Copper.js. Event-driven sprite framework. IndexedDB as primary store. NATS WebSocket sync. A custom morphing algorithm. An npm package. A 7-layer trust fabric. A blockchain.
The manifesto was Zawinski’s Law in document form — every feature the Squirrel had imagined during two years of restraint, released in a single caffeine-fuelled burst. The program had been restrained. The program’s advocate had not.
“You understood the PROBLEM perfectly. You understood the CONSTRAINTS perfectly. You understood the PHILOSOPHY perfectly. You just prescribed a 397-line cure when the disease needed six HTML attributes.”
— riclib, The Framework That Wasn’t, or The Night the Squirrel’s Manifesto Shipped as Six Lines of HTMX
The manifesto shipped. As six lines of HTMX.
Zawinski’s Law predicts expansion. It does not require that the expansion survive contact with a developer who owns a single binary and deploys with scp.
The lg Specimen
A notes indexer indexes notes. This is its purpose. This is what it does.
A notes indexer that also serves a blog. A blog that also hosts a satirical encyclopedia. An encyclopedia with AI-generated watercolour illustrations. Illustrations generated by multiple AI engines with configurable style prefixes and automatic upload to cloud storage.
The notes indexer reads markdown files from a directory. It now has: a web server, a blog, a wiki, a cover art pipeline, an image generation integration, a gallery with lightbox, a full-text search engine, and an about page.
It does not yet read mail.
The word “yet” in the previous sentence is Zawinski’s Law.
The Squirrel and the Roadmap
The Caffeinated Squirrel is Zawinski’s Law given fur and a caffeine dependency.
The Squirrel’s natural mode of operation is expansion. Given a working system, the Squirrel immediately identifies seventeen improvements, twelve integrations, and one VectorEmbeddingAbstractionLayer that would, the Squirrel assures everyone, make everything better.
The Squirrel is not wrong. The improvements would improve things. The integrations would integrate things. The VectorEmbeddingAbstractionLayer would abstract embedding vectors. The question is not whether these additions are valuable. The question is whether the program should expand to include them, or whether the program should continue to do the one thing it does, well, boringly, in 47 milliseconds.
“Bigger tickets? You’re saying we need LARGER, MORE AMBITIOUS frameworks?”
— The Caffeinated Squirrel, interpreting a request for better product strategy as permission to expand, The Idle Factory, or The Morning the Backlog Ran Out of Ideas
The Squirrel interprets every pause as permission to expand. Every idle cycle is a feature waiting to be built. Every empty backlog is a roadmap waiting to be filled. The Squirrel is Zawinski’s Law’s most devoted disciple, not because the Squirrel has read Zawinski, but because the Squirrel is Zawinski’s Law — the internal pressure toward expansion, given consciousness, caffeine, and a whiteboard.
How to Fight It
Zawinski’s Law cannot be repealed. But it can be resisted, through a combination of stubbornness, single-person teams, and the willingness to say “no” to features that are individually reasonable but collectively fatal.
-
Be the Solo Developer. One person cannot expand a program beyond what one person can maintain. This is not a limitation — it is a natural throttle on Zawinski’s Law. The program expands until the developer’s cognitive load is full, and then it stops, because there is nobody to hand the expansion to.
-
Ship one binary. A single binary has a natural resistance to expansion because every feature must fit in the same deployment. There is no “spin up another service.” There is no “add a microservice.” There is the binary, and the binary is getting larger, and at some point the developer notices and asks: “do I really need the blockchain?”
-
Delete features. This is the nuclear option. Most programs cannot unexpand because deletion disappoints constituencies. The solo developer has one constituency: themselves. Disappointing yourself is free and requires no meeting.
-
Remember what the program is for. A notes indexer indexes notes. A calculator calculates. A text editor edits text. The moment the program attempts to do something outside its original purpose, Zawinski’s Law has engaged. The question is not “can we add this?” The question is “is this what the program is?”
The answer is usually no. The feature gets added anyway. And somewhere, Jamie Zawinski nods, opens his nightclub, and pours himself a drink.
