DollTop Commerce & POS Platform
LiveA commerce platform, not just a storefront
My role
Designed and built all three applications end to end, including the offline sync strategy for the POS.
Frontend
Backend
Desktop
Overview
DollTop is a retail commerce platform built for a real business, made up of three coordinated applications: a customer-facing storefront, a central API that is the single source of truth for the business, and a desktop point-of-sale application cashiers use in-store — including when the internet connection drops.
The problem
A retail business needed to sell online and in person from the same catalog and inventory, without operations stopping when the in-store connection is unreliable, and without duplicating product, pricing, or customer data across separate systems.
Context
Built for a live retail business. The storefront is in production at dolltop-lb.com and the POS is used for day-to-day in-store sales.
Requirements
Functional
- Public storefront for browsing and ordering products online.
- Cashier terminal for in-store sales, online order fulfillment, and wholesale orders.
- Shared catalog, inventory, customer, coupon, and loyalty-points data across storefront and POS.
- Staff administration with role-based operations for sales, inventory, and reporting.
- Printed receipts at checkout on ESC/POS-compatible printers.
Non-functional
- The POS must keep working when the store's internet connection is unstable or temporarily unavailable.
- No sale should be lost to a dropped connection — orders must queue and retry.
- The backend must remain the single, consistent source of truth once terminals reconnect.
- Terminal credentials and local data must be stored securely on the POS device.
System architecture
The Express API is the single source of truth for catalog, inventory, orders, customers, coupons, loyalty points, and authentication. Both the Next.js storefront and the Tauri POS are clients of that API. The POS additionally keeps a local SQLite cache so cashiers can keep selling — building draft carts and queuing orders — while offline, then synchronizes once connectivity returns.
Customers
Store staff
Next.js Storefront
Public site — dolltop-lb.com
Tauri Desktop POS
Local SQLite cache + offline order queue
Express API
Single source of truth
PostgreSQL · Prisma ORM
Catalog · Orders · Inventory · Customers · Loyalty
Storefront (Next.js)
Customer-facing site for browsing the catalog and placing online orders.
API (Express + PostgreSQL/Prisma)
Central service owning catalog, inventory, orders, customers, coupons, loyalty points, authentication, and role-based operations.
Desktop POS (React + Tauri)
Cashier terminal for in-store sales, online/wholesale order fulfillment, inventory, reporting, and staff administration, with offline-capable local storage.
Backend & data
Data flow
- Storefront and POS both read and write through the Express API — there is one canonical dataset, not separate copies per app.
- The POS caches reference data (catalog, pricing, customers) locally in SQLite and builds draft carts against that cache.
- When the POS is offline, completed sales are queued locally and retried automatically once the connection returns, with the API remaining the source of truth after sync.
Backend design
- Express API exposing operational endpoints for sales, orders, products, customers, coupons, inventory, reporting, and receipt settings.
- PostgreSQL as the primary datastore, modeled and queried through Prisma ORM.
- Input validation with Zod on write endpoints, plus upload handling for product assets.
Database design
- PostgreSQL schema (via Prisma) modeling catalog, inventory, orders, customers, coupons, loyalty points, and staff/roles as the shared source of truth for both client apps.
Authentication & authorization
JWT-based authentication for staff sessions, plus a separate terminal-key mechanism so POS devices can authenticate independently of a logged-in cashier session, with role-based access controlling which operations a staff member can perform.
Integrations
- ESC/POS-compatible receipt printing from the desktop POS.
Decisions & trade-offs
Decision
One Express/PostgreSQL API shared by both client apps, instead of separate backends per app.
Why
Keeps catalog, inventory, and customer data consistent in one place instead of syncing two independent systems.
Decision
Tauri (Rust shell + React UI) for the POS instead of a web-only terminal.
Why
Needed an installable desktop app with local SQLite storage and offline behavior a browser tab can't reliably provide.
Decision
A local SQLite cache with a retry queue on the POS, instead of requiring a constant connection.
Why
In-store checkout can't stop because the internet drops; queuing and retrying preserves sales without losing data.
Trade-offs
- Offline-first POS adds real complexity — a local cache, a sync path, retry logic — compared to a thin client that always talks live to the API; justified here because a lost sale is the costlier failure mode.
- A single shared backend is simpler to keep consistent, but makes the API a dependency both the storefront and the POS's sync step rely on.
Technical challenges
Keeping the POS usable when the store's internet connection drops mid-shift.
Cached reference data locally in SQLite, let cashiers build draft carts and complete sales offline, and queued those orders for automatic retry once connectivity returned.
Letting a POS terminal authenticate independently of a specific cashier's login.
Added a terminal-key mechanism alongside JWT user auth, so the device itself can be trusted for local operations while role-based access still governs staff actions.
Deployment & operations
Deployment
- Storefront deployed and live in production at dolltop-lb.com.
- Desktop POS distributed as an installable Tauri application to in-store terminals.
Security
- JWT authentication plus terminal-key device authentication.
- Role-based access control on staff operations.
- Server-side input validation with Zod on write endpoints.
- Secure local storage of terminal credentials on the POS device.
Performance
- Local SQLite cache on the POS avoids network round-trips for reads during in-store checkout.
Scalability
- Centralizing catalog, inventory, and order data in one PostgreSQL-backed API keeps the storefront and POS consistent as more terminals or sales channels are added.
Results
The storefront is live in production, and the POS is used for day-to-day in-store sales, including online and wholesale order fulfillment, inventory, and reporting.