A small privacy decision that changed my web calculator

Calculator Toolkit was created for a specific purpose: helping people calculate tips, taxes, and split bills with friends. Initially, the decision to not require an account was seen as a minor feature. However, it became evident that this choice significantly influenced the overall interface.

A feature allowing users to save their history would have been helpful. But introducing account sign-ins, recovery processes, and data retention would complicate things for those who simply want to settle a restaurant bill. By deciding to run the calculator locally within the browser, the developer eliminated the need for accounts and the upload of bill data. This decision brought about certain constraints.

One consequence is that users cannot return the next day to recover an earlier calculation. Another is the absence of a dashboard that can explain an unclear result later. Consequently, the current interface must handle all the work. It must present the bill amount, tax, tip basis, total, and each person's share in a clear and understandable manner before the group pays.

The developer found that this wasn't primarily about adding a privacy notice. Instead, it was about removing potential places where the product could hide complexity. For temporary calculations like a restaurant bill, it felt more honest to have the result legible now. If the tip basis changes, the developer needs to make the change obvious. If one diner pays a different share, the total still needs to add up.

While the developer believes local-only isn't a universal rule, it seemed like the more straightforward default for a one-off restaurant calculation. The developer, Leon, is seeking feedback from other developers. They want to know what challenges arise when removing accounts or saved state from a small tool.