DeckPOS — One System for the Whole Place
Client: DeckPOS (Founder) — in development
In-development multi-tenant commerce platform where an independent business runs as an isolated tenant and enables only the modules it needs — register, storefront, campground reservations, rentals, golf, hospitality, events — over one catalog and one ledger.
Context & Objective
A campground with a store, a golf course with a grill, a rental outfit with a website: each ends up paying for four systems that disagree about what an item costs and what was sold. DeckPOS puts the till, the bookings, the rentals and the website on the same catalog and the same books.
Outcome
In active development with roughly fifty feature modules built, a first tenant onboarding in Hohenwald, Tennessee. Canonical user journeys run in CI against a real Supabase project and real Stripe test-mode payments — if a required test secret is missing the job fails and names it, because a skip is never a pass.
Key Highlights
- Module composition per tenant — POS, e-commerce, campground, rentals, golf, hospitality, events, loyalty, gift cards and more
- Tenant isolation enforced by RLS, written in the same migration that creates each table
- Campsite availability held as one row per site per night, so a double-booking is a constraint violation rather than a race
- Money as integer cents and tax as basis points, end to end — no floats anywhere near a total
- Order and booking totals computed server-side from line data; a client never sends a price
- Stripe Terminal for in-person and Payment Element online, with QuickBooks Online export off the same ledger
- Queue-backed jobs (pgmq) for receipts, accounting sync, refunds and booking-hold sweeps