Universal E-Receipt Maker & POS

Many receipt and POS tools are SaaS-first and become dependent on continuous internet access or vendor-hosted data. This product was designed for users who want an application they can install and operate locally, while still retaining optional connected services when useful. A core architectural requirement was that the Receipt Maker remain fully functional without POS, while POS may depend on the Receipt Domain but never the reverse.

• Deliver a standalone Receipt Maker that never depends on POS
• Make POS optional and enforce the dependency direction POS → Receipt Domain
• Keep core business operation local and usable without internet access
• Preserve immutable historical receipts while allowing templates to evolve
• Support user-controlled business branding and multiple receipt formats
• Use decimal-safe money calculations and transactional numbering/idempotency
• Keep Email, SMS and WhatsApp delivery optional rather than required
• Support offline commercial licensing without a permanent licensing server dependency
• Package the product as a downloadable desktop application

• Reconstructing the project away from the initial Firebase/SaaS assumptions without discarding conforming receipt-domain work
• Maintaining strict Receipt Maker independence from POS
• Combining editable/versioned templates with immutable issued receipt history
• Making sale, receipt, payment, numbering, audit and inventory transitions atomic
• Supporting commercial licensing without requiring an always-online validation service
• Keeping provider secrets out of the distributed desktop application
• Preparing cross-platform Tauri packaging while validating a real macOS Intel artifact

The implementation followed a controlled local-first reconstruction. Components were retained only where they conformed to the documented architecture; incompatible Firebase/SaaS assumptions, fake delivery behavior and invented product branding were removed. Tauri provides the downloadable desktop shell, Rust provides native services and offline license verification, SQLite is the authoritative local store, and Supabase/PostgreSQL is isolated to optional connected-service entitlements, usage and provider relay functions.

• Standalone local-first Receipt Maker
• Optional POS on the canonical Receipt Domain
• Quick and itemized receipt issuance
• 10 starter templates with local versioning/designer workflows
• Thermal 58/80/112 mm, A4/A5/Letter and custom receipt layouts
• Configurable customer/business logo, colors, theme, navigation and density
• Immutable receipt snapshots with SHA-256 content integrity
• Decimal-safe financial engine
• Atomic numbering and idempotent issuance
• Local customers, catalog and optional inventory
• Owner/Admin/Manager/Cashier/Receipt Clerk/Auditor RBAC
• Offline Ed25519 licensing
• Native PDF save and print
• Atomic POS refunds/voids with inventory reversal
• Optional Email/SMS/WhatsApp connected delivery

• PBKDF2-based local password/PIN verification
• Role-based access enforced at UI and application-service boundaries
• SHA-256 receipt snapshot integrity
• SQLite triggers protecting issued receipts, payments, sales, stock movements, refunds and audit history
• Idempotent receipt issuance and POS checkout
• Atomic local transactions for numbering, financial history and inventory
• Ed25519 signed offline licenses; private signing key never ships with the application
• Provider secrets excluded from the desktop client
• Supabase connected delivery protected by JWT authentication, RLS, per-account entitlements and rate limits

Core receipt/POS work executes against local SQLite and therefore does not incur network latency or depend on cloud availability. Vite code splitting separates UI, connected-services, document-generation and desktop-runtime dependencies. Atomic SQLite transactions keep numbering, receipt history, payments and inventory consistent under retries and reversal workflows.

The approved interface uses a premium configurable shell with customizable business logo, display name, tagline, colors, light/dark/system theme, navigation treatment, density and corner style. Users can issue quick or itemized receipts, select/version templates, operate POS when licensed, save PDFs natively, print locally and opt into connected delivery without changing the core offline workflow.

Development

Local ownership and offline reliability were treated as architectural constraints rather than optional deployment settings. The resulting system separates durable local financial workflows from additive connected services: the customer can lose internet access without losing receipt issuance, POS operation, history, templates, customers, catalog, PDF or print capabilities.