Why we fixed our own rules four times

Four times in the past two months, we applied a rule we’d set for ourselves too broadly or too narrowly, and had to fix it. As our September 1 planning doc says, we started with a tool that put one shop’s operations on one screen. This is the record of those two months, before that tool became an open protocol for AI agents.

Splitting what we observed from what we assumed

We had a rule: never make up an amount we haven’t observed. The rule was right, but we applied it to simulations too, in the same way. That stopped us from computing any “what if” at all. So we split the two. Records of what actually happened leave unknown amounts blank, and any calculation built on assumptions is labeled as such. Two days later we found the same rule was also throwing away values users had typed in themselves. What we meant to block was numbers developers hard-code, not values users enter. So we narrowed the rule again.

The day we went too narrow

Then we made the opposite mistake. On October 1 we rewrote a definition that read “a cash calendar for restaurants.” Cash is just the most visible outcome. It was never everything we meant to handle.

Reading first, then asking

One design assumed people would upload their files and we would compute from there. In practice, people don’t upload everything, and what they do upload has gaps. So we switched to reading what people had already given us, and asking only about anything that looked off. Around the same time, we took back a sentence that called a simple method “adopted” because it won a test. The data came from one shop and covered less than a year. The win didn’t show the method was good. There just wasn’t enough data to tell. Since then we call it “a baseline to beat,” and before we start, we write down that if we can’t beat it, we drop the idea.

We weren’t slow because there was too much to build

In mid-October we dropped a plan to put all our effort into the payment screen. When we looked at why we had slowed down, it wasn’t the number of features. It was how long each round of designing, reviewing, and fixing took.

The takeaway: even the people who write a rule can apply it too broadly or too narrowly. So we keep a dated record of every fix.