When your system stops working
Almost no old rule was a mistake: it was right and then expired. Before removing one, ask for the reason written beside it.
What worked for you with ten clients stops working with a hundred, and it is almost never because someone got it wrong: it is because the decision was right for ten and then expired. Telling «this was wrong» apart from «this expired» is what decides whether a change improves something or breaks something else. And the only way to tell them apart is that somebody wrote down why.
A small, measured case
There is a screen on this site listing the kinds of business I build for. When I made it there was one, and the card showing it stretched from edge to edge: a huge box with three lines inside, and the page read as abandoned, as if something had failed to load. So I capped its width. A correct decision.
Months later there are four. And that same cap made the row of cards end before the box below it.
What I believed
The width cap protects the page from looking abandoned.
What turned out to be true
It protected it with one card. With four it produced 112 pixels of misaligned edge — exactly the sloppiness it existed to prevent. And I did not catch it by looking: I caught it by measuring.
A hundred and twelve pixels is not a catastrophe. But it is one of those things people do not name and do register: the feeling that something is slightly crooked, without being able to say where.
What I did, and what I did NOT throw away
The easy move was deleting the cap: with four cards it was no longer in the way. But that threw away the reason it existed, and the day only one is left —because I remove the others, because I start another section— the old problem comes back and nobody will know why. So the cap is still there, but only when the card is alone.
I could decide that in two minutes for one reason only: the reason sat next to the rule. Without it I had two bad options — keep it out of fear, or remove it blind.
Almost no odd rule is arbitrary: there was a problem and that rule solved it. Many no longer apply because the problem is gone. And from the outside, both kinds look exactly the same.
Where this happens to you
In the price you set when you had spare time. In the discount you gave when there were five clients. In «just WhatsApp me and I will write it down», which worked perfectly until it did not. A gym lives this with billing: chasing each member for their monthly fee is reasonable with twenty and a part-time job with two hundred — in systems for gyms and wellness that is exactly the piece that gets automated first.
None of those decisions was bad. They were all right, and the business grew around them until they stopped serving it.
How to tell whether one of your rules has expired
- How many clients, bookings or orders did you have when you set it? If the number tripled, revisit it.
- Does someone still explain it to new staff as an exception? The exceptions that need explaining are the expired ones.
- Does the problem it solved still exist? If it does not, the rule is pure cost.
- Do you know why it was set? If nobody knows, that is the finding — and it is the first thing to fix.
What is worth asking for
When someone builds something for you, ask them to write down why they made the odd decisions. Not full documentation, which nobody reads: the reason, next to the thing, in a line or two.
It is what makes it possible to change something a year later without breaking it. And it is the difference between a system you can keep growing and one that reaches a point where rebuilding is cheaper — which is the most expensive way to learn this.
And when the time comes to change one of those rules, the other half of the job is proving the change did not take anything down with it: how to know nothing broke.