Reverse the promise that going over never blocks capture

The decision

Refuse new decisions once a workspace has spent its monthly allowance — in the app, over email, on every path that writes a record — and email the owner once at ninety percent of the allowance and once at the wall.

Why, at the time

The published promise was that the allowance was a meter and never a lock, on the reasoning that the hard part of this product is getting teams to log decisions at all. That reasoning held while nobody could pay: refusing a write that no amount of money could unblock is not a price, it is breakage. Once Checkout existed the refusal had a way out, and an allowance nobody is ever held to is a price list rather than a price.

What happened

Shipped and deployed on 11 September behind two conditions, so it stays inert unless the limit is switched on AND a checkout could actually complete. Nothing has been refused yet — the only workspace is at seven of ten decisions for the month — and nobody has paid, so this supersedes the 3 September entry above, which still reads as though billing were switched off. Two things did not survive contact: the meter counted the decision rows that still existed, so deleting one refunded allowance and the limit could be spent over and over, which took a database trigger and a counter that only climbs; and the environment variable that arms the limit turned out to arm every paid-feature gate as well, so the same deploy closed export, import and the weekly and monthly reports for that workspace, which nobody had decided to do that day.

Lesson

A meter can count what is there. A cap has to count what happened — the moment a number can refuse a write, deleting a row becomes a way to buy another one.

Every entry in this ledger is real and was checked against the commit or migration that carries it. Want to keep your own this way? Start with the free decision log template.