Product · Security & Reliability
Designed for a business that runs on other people’s hands.
Rights enforced on the server, an audit log nobody can edit, and a closed day that stays closed — even for the admin.
Who may do what
- User Privileges per form, per action (add · edit · delete · print), per branch, with day limits since a date — enforced by the server on every save; a refusal is logged as DENIED.
- Roles for cashier, kitchen, manager, accountant, admin; the “+” quick-add appears only for admins.
- Two-factor sign-in (authenticator app) with recovery codes and 30-day trusted devices; escalating locks against password guessing.
- Closed-day lock — nothing on a closed day moves, not even for the admin; re-opening is itself recorded.
What the books guarantee
- Every voucher balances — held by the database, not just the screen.
- Linked-entry protection — a receipt cannot be deleted while the payment that answers it stands; a fund is received once, against the Pay it answers.
- Immutable audit log — server-written, before/after snapshots, cannot be edited even by the database superuser.
- Chart of Account — a head with a ledger cannot be deleted; heads move with Moving Head, logged.
Isolation between businesses
- Row-level security in PostgreSQL: every business’s rows are invisible to every other, enforced by the database itself.
- The server runs as a plain database role — no superuser at runtime; migrations use a separate privileged connection.
- Per-request tenant gate — the business comes from the session, never from the URL; a page cannot write another business’s data.
Nothing lost, nothing stale
- Version-checked saves — two open screens never overwrite each other’s shift.
- Offline queue — orders rung up on a bad line are kept and sent when it returns; a slow line is named on screen.
- Auto-refresh after a release — every open browser reloads itself onto the new build.
- Backups and a data census before and after every deployment.
Engineering
Tested before it ships.
244automated test suites
10,000+checks before every release
Staging → Productionvalidated, with a data census on both sides
- 244 automated test suites (over 10,000 checks) and a security gate run before every deployment.
- Staging environment mirrors production; releases go staging → validated → production with a data census on both sides.
- Auto-refresh of every open browser after a release.
- Backups and a data census before and after every deployment.
- Hosted on a dedicated server: Node.js 20, PostgreSQL 16, nginx, pm2; HTTPS at dotsms.net.
Ask the hard questions in the demo.
Bring your accountant. We will show the audit log, the privileges screen and a closed day.