How this startedNobody we spoke to had a planning problem.
They had limits they believed in. They had a rough sense of which categories ran hot. Some of them had a genuinely good spreadsheet. What none of them had was a reading of their own spend that was current enough to act on while the cycle was still running.
The pattern repeated with a consistency that stopped being interesting and started being the product brief. A category breaches somewhere around the middle of the cycle. Nobody notices, because noticing requires someone to categorize a few hundred transactions and compare the totals to a set of limits. Three or four weeks later an accountant confirms what happened, and almost always there was unused room sitting in a neighbouring category the entire time.
Two halves of a solvable problem, kept apart only by the fact that nobody had the time to put them together on day 11.
What we decided to buildClose the gap between the spend and the reading of it.
That meant categorization had to be automatic, because a loop that depends on somebody sorting transactions is a loop that runs at month-end regardless of how fast everything else is. It meant tracking had to be continuous rather than reported. And it meant that when a category breaks, the product should already know where the room is instead of leaving you to go and find it.
It also meant drawing a line we have not moved since. The engine suggests. It does not act. We had every technical opportunity to let it apply its own reallocations, and declining that was deliberate: a budget changed without a named approver is a budget nobody can defend, and a product that quietly moves your limits is a product you will eventually stop trusting.