POS App Development Case Study: How We Built a Role-Based System for a Multi-Location Salon Group

Replacing Disconnected Systems with One Unified Platform

This POS app development case study covers a multi-location salon group that was running three disconnected systems: appointments in a paper book, sales through a standalone till, and staff hours in a spreadsheet — a separate copy of each, per location. We replaced all three with a single Flutter-built retail app where an owner, a supervisor, and a cashier see three genuinely different products, with permissions enforced at the data layer rather than the interface, and transactions that keep working through a network outage.

Three Systems That Were Never Designed to Talk to Each Other

Each salon kept its own paper appointment book, its own till, and its own weekly staff-hours spreadsheet. That setup holds up fine until someone needs an answer that spans locations — which services are actually profitable, which staff member is busiest and where, whether this week is ahead of last week. Every one of those questions meant manually reconciling three separate sources of truth, so in practice they went unasked. The client wanted one mobile app for the whole operation — the real brief was in what "one app" needed to mean.

Same App, Three Different Operating Realities

An owner needs visibility across every location at once. A supervisor needs full control of their own salon and zero visibility into any other. A cashier needs to move through a sale quickly and must never be able to reach payroll data.

The common shortcut — one interface with controls hidden per role — looks fine in a demo and fails in production: the data still reaches the device, the permission logic lives in the UI layer where a future refactor can quietly break it, and every new feature is a fresh chance to leak one location's numbers onto another's screen.

Two more constraints shaped the build: bookings made through the group's website had to reach the app with no manual re-entry, and the app had to keep taking payments through a network outage — a POS that stops selling on a busy Saturday because the router rebooted has not been given a solution, it has been given a liability.

Four Load-Bearing Decisions

Enforce Roles in the Data Layer, Not the Interface

Tech Stack & Architectural Choices

Build Facts & Delivery Results

The app shipped to both the App Store and Google Play. Owners see cross-location performance on one screen, supervisors run their own site independently, and cashiers complete a transaction in fewer steps with fewer opportunities to get it wrong.

Build facts, verified against the delivered app. No outcome numbers are published unless they were actually measured.

What You Can Check Yourself

Architecting Systems That Stay Correct Over Time

Multi-tenant apps — one product serving users who need genuinely different views of the same data — are harder than they look, and the difficulty is never in the screens. It's in deciding where permission logic lives. Put it in the interface and you have a demo. Put it in the data layer and you have a system that stays correct as other people extend it, and can be handed to a new developer without becoming a security review. This is the same approach we bring to hospitality, retail, field services, or any multi-location build.

Frequently Asked Questions