What the architecture becomes when you remove the server

A till with no server has no "login". But the till still needs to know who opened it: shift handover, refund permission, end-of-day count.

A cloud register answers these with sessions and an auth service. With one machine on the counter, the same questions are answered by the file system.

Three questions, three local answers

• Identity: a 4-8 digit PIN hashed with scrypt. No session, a lock: the screen closes after two idle minutes.
• Time: there is no server clock. If the machine clock is wrong, the end-of-day report is wrong. The clock is written into the closing record so it can be noticed later.
• Conflict: two tills cannot write the same file. That is not a gap but a single-terminal design. A second till requires redesigning the write path.

The hard part was not the database

SQLite was easy. The hard part was dropping the habit of asking the server: refreshing stock on open, taking the receipt number from the centre, identifying the user with a token. Each has a local equivalent, and none is quite the same.

Stock is a ledger, not a counter

The first version had a `stock` number. It drifted the first time someone cancelled a receipt. Now purchase, sale and correction are rows; on-hand is derived. Query cost went up, the reconciliation problem disappeared.

The cost, stated plainly

One terminal. Backup is the user's job (hence backup/restore in the roadmap). No remote support: when something breaks, it has to be explained over the phone. Offline is a commitment, not a convenience.