D-Record

D-Record started as a manual order-tracking spreadsheet for a local dairy delivery operation. The first architectural decision was to move the authoritative data model into PostgreSQL with Supabase Row Level Security so that access policies could be declared at the database layer rather than enforced piecemeal in the application.

Each role (customer, rider, admin) has a distinct RLS policy set. Customers can only read and write their own orders. Riders can read orders assigned to them. Admins have unrestricted access. This means even if application-level auth is bypassed, the database rejects unauthorized queries at the connection level.

Order scheduling is handled by a Supabase Edge Function that runs on a cron trigger each morning. It queries all pending orders, groups them by delivery zone, and creates rider assignments. Customers receive push notifications through the Web Push API when their order status changes. Notification payloads are generated server-side and pushed to the browser via a service worker, keeping no persistent WebSocket connection open.

PDF invoice generation uses a server-side PDF library called from an Edge Function. The invoice data is fetched from PostgreSQL, formatted into a PDF buffer, and returned as a binary response. This avoids client-side PDF generation, which is unreliable across mobile browsers.