Building a Production-Grade POS Platform in Under 2 Weeks Using AI

Offline-First

Every operation must work without internet. Sync happens in the background when connectivity returns. Users should never see a loading spinner or error due to network state.

Eventual Consistency

Data syncs when possible, but local state is always authoritative for the current session. Conflicts are resolved automatically using timestamp-based ordering.

Local Retail Abstractions

The data model reflects how Pakistani shops actually operate: udhaar, partial payments, outlet-specific inventory, supplier relationships.

Role Separation

Owners see everything. Cashiers see only what they need. This isn't complex RBAC—it's two well-defined permission sets that match real shop hierarchies.

Extensible Data Model

The schema is designed to support future features (purchase orders, expense tracking, reporting) without migrations that break existing data.

Security by Default

Row-level security on every table. No data leaks between businesses. Every query is scoped to the authenticated user's business context.

Why Offline-First Was Mandatory

Pakistani retail internet is unreliable. A shop can't stop billing because the connection dropped. Every competitor that requires connectivity for basic operations fails in this market.

RxDB Implementation

RxDB provides a reactive, offline-capable database that syncs to remote backends. Data is stored in IndexedDB and survives browser restarts.

// Local database setup with RxDB
const db = await createRxDatabase({
  name: 'mydukan',
  storage: getRxStorageDexie(),
});

await db.addCollections({
  products: { schema: productSchema },
  sales: { schema: saleSchema },
  customers: { schema: customerSchema },
});

Local Writes First

Every sale is written to RxDB immediately. The UI updates instantly. Background sync handles server persistence.

// Sale creation - local first
async function createSale(saleData: Sale) {
  // Write to local DB immediately
  await db.sales.insert({
    ...saleData,
    id: generateUUID(),
    syncStatus: 'pending',
    createdAt: Date.now(),
  });
  
  // Queue for background sync
  syncQueue.push({ type: 'sale', data: saleData });
}

Failure-Tolerant Billing

If sync fails, data persists locally and retries automatically. Users are never blocked. The worst case is delayed server-side visibility—never data loss.

Separate Product Sync vs Sales Sync

Product catalog syncs down from server (owner controls inventory). Sales sync up from devices (cashiers generate transactions). This separation simplifies conflict handling.

Idempotent Operations

Every sync operation uses unique IDs. Re-syncing the same sale twice doesn't create duplicates. The server checks for existing records before insert.

Status-Based Syncing

Records have a syncStatus field: pending, synced, or failed. The sync engine processes pending records in batches, updates status on success, and retries failures with exponential backoff.

Why This Avoids Data Corruption

No optimistic locking, no merge conflicts. Sales are append-only. Products sync one-way. The data model eliminates the scenarios where conflicts could occur.

Partial Payments

Any sale can be partially paid. The UI shows remaining balance and accepts additional payments at any time.

Linking Payments to Sales

When a customer pays off credit, the payment links to specific outstanding sales. This maintains a complete audit trail.

Owner-Controlled Settlement

Only owners can mark credit as settled or write off bad debt. Cashiers can record payments but can't modify credit terms.

Auditability

Every payment is timestamped with the user who recorded it. Full history is preserved for dispute resolution.

Worker Roles

Two roles: owner and cashier. Owners have full access. Cashiers can create sales and view products but can't modify inventory, see reports, or access other outlets.

Outlet Assignment

Workers are assigned to specific outlets. A cashier at Outlet A can't see or affect Outlet B, even within the same business.

Why RLS Is Critical

Row-level security enforces these boundaries at the database level. Even if application code has bugs, the database won't return unauthorized data.

-- RLS policy for sales table
CREATE POLICY "Workers can only see sales from their outlet"
ON sales FOR SELECT
USING (
  outlet_id IN (
    SELECT outlet_id FROM workers 
    WHERE user_id = auth.uid()
  )
);

Supplier Management

Suppliers are tracked with contact info, payment terms, and product associations. This prepares for future purchase order functionality.

Linking Suppliers to Products

Products reference supplier IDs, not names. This enables queries like "show all products from Supplier X" and prevents data duplication.

Future Extensibility

The schema supports adding cost tracking, purchase orders, and supplier payments without restructuring existing tables.

Why Supabase

Managed PostgreSQL with built-in auth, real-time subscriptions, and RLS support. Eliminates infrastructure management overhead while providing enterprise-grade security.

PostgreSQL Over NoSQL

Relational data model matches the domain (businesses → outlets → sales → line items). SQL enables complex reporting queries. ACID guarantees prevent data corruption.

RLS Policies

Every table has row-level security. Users can only access data within their business context. This is enforced at the database level, not application code.

SQL RPCs for Dashboards

Complex aggregations (daily sales, top products, credit outstanding) run as server-side functions. This keeps business logic close to data and reduces client complexity.