I built Calculator Toolkit for a narrow moment: someone has a restaurant bill, wants to check the tip and tax math, then needs to split the total with a few people.
At first I treated the no-account requirement as a small feature. It turned out to be the decision that shaped most of the interface.
A saved-history feature would be convenient. It would also mean sign-in, account recovery, data retention, and an extra decision for someone who only wants to settle a dinner bill. I decided that the calculator should run locally in the browser instead. There is no account and no bill-data upload.
That creates constraints. A person cannot return tomorrow and recover an earlier calculation. There is no dashboard where an unclear result can be explained later. The current screen has to do the work. It needs to make the bill amount, tax, tip basis, total, and each person's share understandable before the group pays.
I found that this was less about adding a privacy notice and more about removing places where the product could hide complexity. If the calculation is temporary, the result needs to be legible now. If somebody changes the tip basis, the change needs to be obvious. If one diner pays a different share, the total still has to add up.
I do not think local-only is a universal rule. It is a poor fit for products where history, collaboration, or handoffs are the reason people use the product. For a one-off restaurant calculation, it felt like the more honest default.
I am Leon, the maker of Calculator Toolkit. I would like feedback from other developers: when you remove accounts or saved state from a small tool, which parts of the interface become harder to get right?
Disclosure: This article was drafted with AI and reviewed by Leon.
Top comments (0)