Laci POS

Laci is a multi-tenant point-of-sale platform sold as a service to many merchants at once, built for the way small and mid-sized Indonesian businesses actually trade: patchy connections, a queue that cannot stop, and an owner who wants today's profit without exporting anything. It covers retail and F&B dine-in in one product, with each merchant able to run several outlets under a single account. The stack is TypeScript end to end — SvelteKit 2 with Svelte 5 on the front, Bun with ElysiaJS on the API, PostgreSQL 16 for storage, and Docker for the whole deployment — with the money, cart, and order logic living in one shared package so the cashier's screen and the server can never disagree on a number.

The cashier screen is offline-first by construction rather than by fallback. It is a prerendered, client-only route backed by IndexedDB, so a sale, its lines, its payments, and its outbox record all commit in a single local transaction and the screen reopens after a power cut with no network at all. Synchronisation runs on its own: pull uses a keyset cursor per table that rewinds slightly on every response so late-committing rows are never skipped, while push treats the client-minted sale id as the idempotency key, making a retried upload harmless. A transaction whose total does not match the server's recalculation is never rejected — the customer has already paid — it is stored for review instead. Receipt numbers carry a device number issued at registration, so two tills working offline in the same outlet can never print the same number.

Tenant isolation is enforced by the database, not by discipline. Every business table carries a tenant id under row-level security with FORCE enabled, and the API connects through a role that is neither superuser nor table owner and cannot bypass those policies, so a forgotten filter in application code leaks nothing. A build-time test fails the pipeline if any module outside a small allowlist reaches the connection pool directly, and role guards answer a clean 403 rather than leaking existence through a 404.

Money is handled as integers in minor units with no floating point anywhere on the price path, and the calculation order is fixed: line subtotal, line discount, transaction discount spread across lines by largest remainder, service charge, tax, and a single rounding at the very end. Tax is computed on the amount including service charge, matching Indonesian PB1 rules, so filings come out right. Stock is derived rather than stored: a movement ledger records every cause and a trigger-maintained level cache can be recomputed from it at any time.

The F&B side adds long-lived table orders that several devices may touch at once, kept consistent through an append-only event log folded into current state rather than a row that different devices overwrite. Kitchen displays sit deliberately outside the role ladder so a tablet in the prep area can never reach sales figures, prices, or reports. Vertical modules are gated per tenant, and the frontend loads them dynamically, so a retail merchant never downloads F&B code at all. In production the platform runs as a hardened container stack with replicated API and web services, a separate migration job, and an automated backup sidecar, routed behind a reverse proxy with no ports exposed to the host.