A point-of-sale and member-management platform for a European retail group running forty stand-alone locations. Multi-role auth across staff, manager, and member; real-time inventory; charts that operators actually read; and a payments stack that handles the cash + card hybrid every member-led retail concept depends on.
Member-led retail is a hybrid model — the relationship to the customer is recurring (membership, tiers, loyalty) but the transaction at the counter is single-event (POS, cash, card). Off-the-shelf tools serve one side or the other; nothing serves both well. We built a single platform that handles member identity, tiered pricing, real-time inventory across forty locations, and the operator-grade reporting the group needed to run the back office. Cannabis-shop-clean front of house, ERP-grade back of house.
The group runs forty separate physical locations. Each location has staff at the counter, a manager doing operations, and a recurring base of members who pay a fee and receive tiered pricing or loyalty benefits. The unit economics depend on (a) members actually showing up, (b) inventory not running out at the location level, and (c) the manager being able to see what's happening operationally without phoning the head office.
The stack they inherited was four products taped together. A consumer-grade POS for the till. A spreadsheet for inventory. A custom CRM for membership. An accounting tool for the books. None of them talked to each other. A new member-tier policy required updating four systems by hand. A shift handover took the manager forty minutes of cross-referencing four windows. And inventory at the per-location level was reconstructed weekly from receipt data — which meant they routinely sold things they didn't have.
“Four taped-together systems. A new policy meant updating four products by hand. We replaced all four with one.”
The brief was specific. One platform, three roles, real-time inventory, member tiers as a first-class concept, and a payments layer that handled cash + card hybrid environments — because member-led retail concepts in this geography settle in both, and a card-only POS would have broken the model.
The till knows the member, the tier, and the live inventory state. The cashier doesn't have to.
The off-the-shelf candidates were either consumer POS (Square, Lightspeed) that lacked the membership concept entirely, or vertical ERP suites that demanded a six-figure annual contract and a three-month onboarding. Neither was the shape of the actual operation. They wanted a product that fit the *operational* reality — not the ERP-fantasy of one.
We were comfortable building it because the architecture is well-understood — multi-tenant data layer, role-scoped APIs, real-time inventory, payments — and the design surface (counter staff working a busy shift, manager doing operations, member checking a balance) is exactly where small-shop design quality wins over enterprise polish. Synara is a design + engineering studio that ships in both registers.
Three separate token types (staff, manager, member) handled by a single `useAuth()` hook on the client. Components ask which role they have; the auth layer figures out the rest. Adding a new role is one config change.
Every transaction at every till mutates the inventory state for that location. Managers see live counts; head office sees aggregate counts. Low-inventory alerts fire at the location level, not the company level, so reorders happen before the shelf is empty.
Tier definitions live in admin. Pricing, discounts, and loyalty calculations are derived from tier — not hard-coded. New tier? One database row. New benefit? One config object. No code change required.
Stripe handles the card rail. A cash module handles the manual rail with end-of-shift reconciliation built in. Both rails write to the same transaction log, and the daily Z-report ties out automatically.
ApexCharts dashboards for managers and head office — sales trends by location, member lifecycle, inventory velocity, tier-mix shift over time. The charts are calibrated for *operational* decisions, not investor decks.
A ~2,500-line `src/types/api.ts` ensures every API call, response shape, and client-side mutation is type-checked. Breaking changes are caught at build time, not by a frustrated cashier at the till.
Operator-grade charts. Calibrated for decisions, not for investor decks.
MethodologyOperational improvements are observed by the management team and confirmed through internal Z-report reconciliation. The 'one platform replaces four' claim is structural — the same data model powers POS, membership, inventory, and reporting.
We stopped phoning head office on every shift. Everything we used to need to ask is now on the dashboard. That single change paid for the build.
A member-facing companion app for tier status, balance, and reorder shortcuts. Cross-location member visibility — the same member can buy at any location and the system recognizes them. And a small marketplace layer for partner-brand inventory.
If your operation depends on a recurring membership relationship *and* a single-event transaction at the counter, the off-the-shelf tools won't fit either side cleanly. We can scope a unified POS + membership platform in 8–14 weeks.