BarberBase Engineering Case Study
BarberBase is a salon operations platform engineered by CodeNXT Lab to simplify queue management, appointments, staff workflows, and customer communication. This case study focuses on engineering decisions rather than product marketing.
The Problem
Traditional barbershops and salons operate under high execution noise. Front-desk operations frequently rely on manual queues and paper logs. This creates poor operational visibility for management, causes long customer waiting times, and limits coordination among staff. When queue states change, the lack of real-time synchronization causes scheduling conflicts and double-bookings.
Engineering Goals
We designed the software system around five technical constraints:
- 01 / Simple UI: Fast touch targets for salon staff operating on tablets.
- 02 / Realtime Updates: Sub-100ms state updates across all connected devices.
- 03 / Offline Tolerance: Handles temporary network dropouts without losing booking data.
- 04 / Fast Interactions: Page transitions and action updates execute in <100ms.
- 05 / Minimal Training: Self-explanatory interface requiring zero manual reading.
System Architecture
BarberBase is built on SvelteKit, Supabase, and PostgreSQL. Client states are managed locally, and
actions are synchronized in real time via Supabase Realtime channels.
**Database & State Synchronization:** We deploy PostgreSQL relational schemas. SvelteKit acts as the
application layer, running authentication and static rendering, while Supabase provides real-time
event streams. Role-Based Access Control (RBAC) is enforced at the database level using Row-Level Security
(RLS) rules, ensuring database queries automatically isolate tenant data.
Key Engineering Decisions
RPC-First Backend Communication: Instead of executing direct CRUD database mutations from SvelteKit, all write actions are dispatched via Supabase Remote Procedure Calls (RPC). This encapsulates transactional logic (such as checking slot occupancy) inside database functions, guaranteeing atomic transactions.
Realtime Subscriptions: Connected tablets subscribe to changes on the specific salon ID. Changes are streamed via WebSockets, allowing the screen to update in real time without polling.
No queue_position Column: Instead of maintaining a mutable integer column representing index sequence (which requires recalculating all indexes on every deletion or insertion), we order queues dynamically using a `created_at` timestamp. This eliminates race conditions during concurrency shifts.
Local Optimistic Updates: To ensure the UI changes in <50ms, the frontend state updates optimism-first. If the database mutation fails or is rejected by RLS rules, the interface automatically rolls back to the server-confirmed state.
Trade-offs
Building BarberBase required making operational compromises:
Supabase vs Custom Server: Supabase provided fast setup and real-time synchronization channels out-of-the-box. The limitation is that database functions must be written in PL/pgSQL, which is harder to unit-test and version-control compared to Go/TypeScript backends.
Realtime Complexity: Maintaining persistent WebSocket connections on tablets in salons with unstable Wi-Fi leads to connection drops. We had to build custom reconnection hooks and offline queue sync buffers to guarantee data consistency.
Offline Sync: Workloads are cached locally using IndexedDB. However, resolving conflicts (e.g. if two operators book the same slot while offline) relies on a "first write wins" server timestamp rule, which can occasionally override offline edits.
Lessons Learned
Simple Queues Outperform Scheduling
Salons frequently struggle with rigid calendar schedules due to variable service times. Building a dynamic queue list ordered by arrival timestamps proved much more resilient than fixed-time appointment slots.
Avoid Heavy Framework Abstractions
Relying on complex state management libraries bloated frontend bundles. Using Svelte 5 runes with native browser events simplified memory management on low-spec tablets.
Permission Isolation Is Critical
Allowing write access to global database views is unsafe. Encapsulating all security parameters inside PostgreSQL Row-Level Security (RLS) rules prevented cross-salon data leakage.
UX Over Features
Adding secondary features (like email campaigns) distracted operators. Prioritizing queue visibility and simple check-in interfaces improved operator retention.
Business Impact
The implementation of BarberBase delivered qualitative improvements across active salons:
- • Reduced operational confusion by eliminating paper booking logs.
- • Better staff coordination via real-time queue syncing on multiple tablets.
- • More predictable customer wait times through dynamic arrival-order tracking.
- • Clean, structured queue status records for shop management audits.
Technology Stack
| Layer | Technology | Role |
|---|---|---|
| Frontend | SvelteKit & TypeScript | Interface rendering, compilation, static pre-rendering. |
| Database | Supabase (PostgreSQL) | Relational storage, RPC functions, transaction control. |
| Realtime | Supabase Realtime | WebSocket synchronization streams for queue changes. |
| Styling | Tailwind CSS | Utility-first visual layouts and layout properties. |
Future Evolution
The architecture is structured to support incremental enhancements:
Advanced Analytics: Custom database views to analyze queue throughput by staff member and service type.
AI-Powered Wait Estimation: Integrating machine learning metrics to estimate queue wait times based on historical queue throughput.
Independent Customer Web App: Allowing customers to check queue states and join remotely via a mobile web layout.
Frequently Asked Questions
Why was Supabase selected?
Because it combines a robust PostgreSQL database with built-in WebSocket synchronization streams out-of-the-box. This allowed us to build the real-time queue syncing engine without hosting a separate socket server.
Why use realtime?
In busy salons, multiple operators update booking queues concurrently. Real-time WebSockets ensure that when an operator updates a client's status, the change reflects on all other tablets instantly, preventing scheduling conflicts.
Why avoid queue_position?
Maintaining a mutable integer `queue_position` column requires executing multiple query writes to update all remaining indexes on every insertion or deletion. Using a `created_at` timestamp allows us to order queues dynamically with a single query, preventing race conditions.
How are permissions handled?
Permissions are enforced at the database level using PostgreSQL Row-Level Security (RLS) rules. This ensures database queries automatically isolate data by salon ID, preventing cross-tenant leakage.
Can BarberBase work offline?
Yes. Transactions are saved locally in the browser using IndexedDB. When connection is restored, changes are synchronized back to Supabase.
Why is the UI intentionally simple?
Salon operators work in fast-paced environments and frequently use tablets with wet or gloved hands. The interface is designed with large touch targets, high contrast, and minimal steps to reduce usage friction.
Discuss your architecture before writing code.
Skip generic agency proposals. Schedule a systems call with our principal architect to review your database schemas and runtime boundaries.
Connect with the Principal Architect