01Context
What this was
BarOS packages hospitality operations patterns into software informed by running a high-volume bar. Teams can self-host and fork instead of stacking disconnected POS notes, spreadsheets, and loyalty tools.
02Problem
What was broken
Before
Guest loyalty often lives on paper; staff lack one operational view during service.
What had to change
Owners need fork-friendly software with clear data ownership.
- 01Customer history scattered across POS notes and informal lists
- 02Loyalty redemptions are hard to track in real time
- 03Campaigns and visit signals rarely connect to CRM records
03Solution
What I built
Next.js and TypeScript with Supabase for venue data, roles, and loyalty ledgers.
Guest PWA for points, tiers, and rewards redemption without a third-party loyalty app.
Back-of-house modules: customer profiles, visit signals, and hooks for promotions informed by real venue workflows.
04Decisions
Key implementation decisions
- 01
Guest-facing PWA loyalty
Members check points and rewards on their own devices - less bar-staff friction.
- 02
Venue CRM tied to visits
Operational data and loyalty events share one customer record.
- 03
Open-source extensibility
Bars, restaurants, and lounges can adapt modules without vendor roadmap risk.
05Impact
Operational impact
- Staff coordinate service with clearer customer context.
- Guests engage with loyalty digitally instead of punch cards.
- Owners control hosting and feature priorities.
06Results
Results
- Hospitality-shaped open-source venue OS.
- CRM + loyalty + guest portal in one repository.
- Scales from single bars to multi-venue groups.
07Stack
Technology stack
- Frontend
- Next.js, TypeScript, PWA
- Backend
- Supabase, PostgreSQL
- Domain
- Hospitality CRM, loyalty, guest portal
- Repo
- github.com/stoimera/BarOS