TallyhubGH

What it is

TallyhubGH is the operating system for a trading business, live at tallyhubgh.com. A shop, a wholesaler or a chain of warehouses signs up, loads its catalogue, and gets a till that works on a counter, a stockroom that knows what is actually on the shelf, and a reporting layer that explains where the margin went.

It runs as three products against one data model: the dashboard (the logged-in application), the platform site (marketing, authentication, onboarding, docs and sales booking), and the admin panel (tenant operations, impersonation, plan management). Companion apps cover barcode scanning and customer-facing views.

The hard parts

Most retail software is a CRUD app with a payment button. The difficulty in TallyhubGH sits in four places.

Selling offline. Power and connectivity are not guaranteed where this software is used. A till that refuses a sale because a request timed out is worse than no till. So the local database is the source of truth: sales are append-only rows with client-generated UUIDs, written locally first and replayed to the server through an idempotent queue. Every record carries a pending | synced | failed status and a device id, so a retry can never double-charge and a reconciliation pass can always explain a divergence.

Warehouse scoping. A price, a stock level, a credit limit and a session all belong to a location, not to a tenant. That scoping is enforced in the query layer rather than the interface, because a filter that lives in a component is a filter that will eventually be forgotten. Switching warehouse re-scopes the entire application, including the open POS session.

Two screens, one sale. The cashier drives a dense keyboard-first terminal while the customer watches a clean read-only display update in real time. Same route, two roles: state travels over BroadcastChannel when both screens share a browser profile, and over a WebSocket relay with rooms keyed by tenant and warehouse when they do not.

Money paths deserve invariants. Refunds, voids, held sales, credit settlements and receipt reprints all mutate ledgers that someone will audit. They are gated behind manager PINs, written with audit trails, and modelled so that a partial failure leaves a recoverable state rather than a wrong number.

Architecture

The application is a Nuxt 3 SPA over a Nitro server, with Prisma against PostgreSQL in hosted mode and SQLite through the Tauri SQL plugin on the desktop. A platform utilities layer abstracts the difference, so feature code never asks which runtime it is in.

• State — Pinia stores per domain, with 220 composables carrying the shared reactive logic: sessions, warehouse scope, cart maths, sync status, printing.
• Realtime — Nitro plus crossws for notifications and the customer display, with a publisher/subscriber relay so a display can be a separate process or device.
• Auth — JWT sessions, bcrypt credentials, WebAuthn passkeys, manager PIN gates, idle lock screens, and an audited impersonation exchange for platform support.
• Documents — invoices, receipts and label templates rendered for both browser printing and hardware receipt printers.
• Billing — plan entitlements evaluated server-side, with a blocked-state screen rather than a half-working app when a subscription lapses.

On-device intelligence

TallyhubGH answers questions like “which products lost margin last month?” without sending business data anywhere. A quantized model loads into a web worker through WebLLM, translates the question into a constrained query against a described schema, validates it before execution, and renders the answer as a chart or a summary card. No per-query API cost, no data leaving the device, and it still works offline — which is the whole point.

Desktop and PWA

The same source ships as an installable PWA with a service worker and offline fallback, and as a Tauri 2 desktop binary for macOS, Windows and Linux with deep-link handling, a draggable native surface, custom URL schemes to launch from the web app, and local SQLite storage. Icon generation, signing and per-target builds are wired into the repository scripts.

Details worth mentioning

• 32 themes, switchable at runtime and persisted in a cookie so SSR renders the right one on first paint.
• Barcode scanning through @zxing/library, sharing a decoder with the scanner app.
• Skeleton states for every dense view — a table that reflows twice looks broken.
• Guided tours and quick-action palettes, because operators are trained in minutes.
• Documented sync reconciliation plan, offline algorithm and dual-screen protocol kept in the repository next to the code they describe.