Chapter 1: Complexity Does Not Arrive All at Once
The little thud
Complexity enters quietly. You do not wake up one morning and decide to make your life unlivable. You open the refrigerator and see half a jar of sauce that expired two years ago. You do not throw it away because throwing it away would require a small decision, and small decisions are exactly what you are already tired of making. Every time you open the refrigerator, your mind makes a little thud.
That little thud is the taste of accumulated complexity. It is not catastrophic. Catastrophe would at least command attention. This is worse in a quieter way: a low-grade tax on the nervous system.
The same thing happens with software, wardrobes, kitchen devices, investment accounts, social obligations, and filing systems. Each item entered with a good reason. The kitchen machine would save time. The collaboration platform would increase transparency. The storage boxes would create order. The new investment account would diversify risk. None of these reasons was absurd. Complexity rarely enters by absurdity. It enters by plausibility.
Second-order growth
The trouble is that complexity does not grow linearly. One new object is not just one new object. It creates relations. The machine requires attachments, cleaning, storage, repair, and the memory of how to use it. The app requires notifications, permissions, updates, passwords, and the social expectation that you will respond inside it. A system is not a pile of parts. It is a web of dependencies.
This is why the first year feels good. The storage boxes line up. The labels are clean. The spreadsheet has colors. Order gives a narcotic pleasure. By the second year, the labels no longer match reality. By the third year, you are sitting on the floor, surrounded by perfectly folded clothes, unable to find the black sweater because the classification system has become more important than the weather.
The most sinister feature of complexity is that it makes you blame yourself. If the system is beautiful and you are exhausted by it, you assume you lack discipline. Perhaps you are not organized enough. Perhaps you need a better routine. Perhaps the problem is not that the system is hungry, but that you are morally insufficient as its caretaker.
Sometimes the honest answer is simpler: the structure is too expensive to maintain.
The first principle
A structure should be judged not by what it can do on its best day, but by what it demands on an ordinary day. Anyone can admire a complex system during setup. The real test comes three weeks later, when you are tired, the phone is low on battery, the child is asking where the scissors are, the meeting starts in seven minutes, and the system wants you to categorize something before it will let you move on.
Low maintenance begins with this question: what does this structure require from my ordinary self? Not the heroic version, not the launch-week version, not the person who is temporarily excited by new labels. The person who will actually have to live with it.
Chapter 3 will return to the fantasy-self problem in detail. For now, the rule is simple: judge the structure after the shine has worn off.
The recruitment of complexity
Complexity is recruited one reasonable decision at a time. Nobody says, 'I would like a drawer full of dead cables, three incompatible note systems, and a kitchen appliance whose cleaning brush has its own cleaning brush.' We say, 'This might be useful.' We say, 'I should be prepared.' We say, 'The advanced version is only a little more expensive.'
Each sentence has a grain of truth. Preparedness is good. Capability is good. The advanced version may indeed do more. The problem is that the mind evaluates the new object in isolation, while life pays for the portfolio. One extra app is trivial. Forty-seven small accounts, alerts, renewals, settings, and update prompts become an attention climate.
A structure also changes the meaning of what surrounds it. A new storage system creates categories; categories create sorting decisions; sorting decisions create exceptions; exceptions create guilt. A new collaboration tool creates channels; channels create expectations; expectations create response norms; response norms create the feeling that silence is failure.
Complexity does not announce itself as complexity. It arrives as improvement and later reveals itself as upkeep.
Why the first year lies
The first year of a new system lies because novelty pays the maintenance bill. You are excited, so categorizing feels like control. You are proud, so the weekly review feels like identity. You are still close to setup, so the logic remains fresh. The system borrows energy from the story you are telling about becoming a better person.
By the second year, the story has cooled. Now the system must justify itself without romance. The labels need updating. The boxes no longer match the seasons. The app changed its interface. The automation failed once, and now you half-trust it. The structure has entered the less glamorous phase where it must be maintained by ordinary motivation.
This is the phase that reveals truth. If the system still works when the honeymoon ends, it may be sound. If it needs the emotional temperature of a new purchase to survive, it was not a structure. It was a mood with a dashboard.
Low-maintenance thinking therefore distrusts launch-day impressions. It asks how the structure behaves after boredom arrives.
The small permission problem
The first act of complexity is often permission. You give an object permission to remain, a tool permission to notify you, a process permission to require explanation, a social group permission to expect your presence. The permission feels temporary. It rarely is.
A friend once bought a small label printer to organize pantry jars. For three weeks it was delightful. The labels looked neat. The jars matched. Then the printer needed new tape, the app wanted an update, and the household began debating whether raisins belonged under Baking, Snacks, or Emergency School Lunch. The label printer had not destroyed the family. That would be too dramatic. It had simply added a tiny court system to the pantry.
This is how complexity recruits us: through small permissions that do not look like governance until they have multiplied. A new category asks to be defended. A new tool asks to be remembered. A new process asks to be taught. At first each request is reasonable. Later the total arrangement feels like a committee has moved into your house and brought its own mugs.
The counterargument is that some complexity is the price of capability. True. A pantry without any order is not freedom; it is lentils hiding behind cereal until 2029. The point is not to reject labels. The point is to notice when the label system becomes more alive than the cooking.
The moment before saying yes
The most important moment in the life of a structure is often the moment before you say yes to it. Before the purchase, before the installation, before the new process, before the new habit tracker, before the new agreement. At that moment, the structure is still innocent. It exists mainly as promise.
Promise is cheap because it is paid in imagination. You imagine the bread made by the kitchen machine, not the dried dough inside the attachment. You imagine the team's clarity after adopting the new platform, not the Friday afternoon debate over whether a task should be marked blocked or waiting. You imagine the organized closet, not the future self refolding clothes according to a doctrine invented during a more optimistic season.
A low-maintenance mind pauses before yes and asks for the maintenance shadow. What will this thing ask for after the excitement leaves? Where will it live? Who will clean it, update it, remember it, explain it, repair it, cancel it, or feel guilty about it? What other systems must now coordinate with it?
This pause is not negativity. It is adulthood. Children evaluate the toy. Adults evaluate the toy, the batteries, the storage, the noise, the cleanup, and the likelihood that the toy becomes a small plastic monument to a Saturday mood.
The same rule applies to institutions. Before creating a committee, ask who will prepare the agenda, write the minutes, track the actions, maintain the membership list, and decide when the committee should die. Every structure deserves a death clause. Without one, temporary solutions harden into background conditions.