Computer Science & Algorithms
Section 1
Core Idea
Zawinski's law (Jamie Zawinski, Netscape/Mozilla): "Every program attempts to expand until it can read mail. Those programs which cannot so expand are replaced by ones that can." The joke is that successful software accretes features—email, chat, calendaring—until it becomes a platform. The serious point: feature creep and scope expansion are the default; programs that stay focused are the exception and often get displaced by ones that do more. It's a warning: without discipline, "one more feature" wins and complexity compounds. Building & scaling: the pull toward becoming everything is strong; resisting it is a design choice.
Free playbook
Get The Business Model Playbook
58 business models, one visual page each: how the money flows, the metrics that matter, and who runs it. Free when you join the Faster Than Normal email.
Free. No spam. Unsubscribe anytime.
Section 2
How to See It
Building & Scaling
You're seeing Zawinski's Law when a product or system that started with a clear purpose keeps adding capabilities (messaging, notifications, integrations) until the core job is buried under scope. The program "expands until it can read mail."
Section 3
How to Use It
Treat scope expansion as the default. Actively resist: define the minimal job, say no to "and also," and split into smaller programs or services when one tool is doing too much. Prefer composition (small tools that work together) over one mega-app. In product: guardrails (roadmap discipline, "one thing" positioning) counter the law.
Decision filter
"Is this feature necessary for the core job, or are we expanding until we can read mail? If the latter, consider a separate tool or saying no; keep the program focused."
As a founder
Product and roadmap drift follow Zawinski's law: the temptation is to add messaging, workflow, analytics—until the product is everything. Resist by defining the one job and refusing scope that doesn't serve it. Compose with other tools instead of absorbing their functions.
Section 5
Founders & Leaders
Marc AndreessenCo-founder, Netscape; co-founder, a16z
Andreessen was at Netscape when Zawinski formulated the law—they lived the tension between focused software and "expand until it can read mail." Andreessen later backed companies that chose focus (e.g. single-use tools) and those that became platforms. Founders can take the lesson: expansion is the default; focus is a choice. Decide explicitly whether you're building one thing well or a platform, and structure accordingly.
Section 7
Connected Models
Reinforces
Gall's Law
Gall's law: complex systems that work evolved from simple systems that worked. Zawinski's law is the failure mode: adding features before the core works. Resist Zawinski by obeying Gall—get the simple thing right first.
Tension
Modularity
Modularity says: split into coherent pieces. Zawinski's law says: one program tends to absorb more. The tension: modularity (separate mail reader, chat, calendar) is the antidote; one app that does everything is the law in action.
Leads-to
Technical Debt
Feature creep adds code paths, dependencies, and edge cases—technical debt. Zawinski's law predicts that creep; debt is the accumulated cost. Controlling scope controls debt.
Section 8
One Key Quote
— Jamie Zawinski (attributed)"Every program attempts to expand until it can read mail." The rest of the law: those that don't expand get replaced by ones that do. A caution against unchecked scope.
Section 11
Summary & Further Reading
Zawinski's law: programs tend to expand in scope until they do everything (including "read mail"); focused programs get replaced by expanders. Treat expansion as the default; resist with focus, modularity, and composition.
01
Essay
On Unix philosophy and the value of small, composable tools—the opposite of Zawinski's expansion.
02
03