A multi-tenant salon platform that controls the hardware, offline if it has to

Salons run on ageing desktop software, fragile timer hardware and paper compliance records. We designed a cloud platform where any device can be a till, with an optional in-salon node that keeps trading and controlling equipment when the internet doesn't.

Locality
UK
Disciplines
Product engineering, Systems integration
Stack
  • Django
  • PostgreSQL
  • React + TypeScript
  • WebSockets
  • Serial / pyserial
  • Stripe

At a glance

  • 362

    build steps with invariants and verify checks

  • 115

    recorded design decisions

  • 12

    build phases

  • 1,000

    tenants the design is built to carry

The challenge

Many salon owners aren't IT people, and they shouldn't have to be. The software they have today assumes one PC behind the counter, the timer hardware is fragile, and the consent and skin-type records live on paper.

The platform had to work for a salon with nothing but a tablet, and for one with a dozen beds, a fingerprint reader and a cash drawer, without ever putting the equipment at risk.

Architecture

Multi-tenant salon platform architectureArchitecture diagram with 8 components. Customer portal to Cloud control plane. Cloud control plane to Stripe. Cloud control plane to In-salon node (sync). Tills and tablets to In-salon node. In-salon node to Bed gatekeeper (bed commands). Bed gatekeeper to Bed timers. In-salon node to Peripherals.syncbed commandsCustomer portalCloud control planeTenants, billing, syncStripeCloud onlyIn-salon nodeFull API, trades offlineTills and tabletsPWA over the LANBed gatekeeperState machine per bedBed timersSerialPeripheralsPrinter, drawer, scanner

Swipe to explore the diagram

The node is optional. Where it exists, it owns the hardware through a single gatekeeper and keeps the salon trading whether or not the cloud is reachable.

What we built

Three surfaces, one codebase

  • A cloud control plane for tenants, permissions, billing, cross-store balances and the customer portal
  • An optional in-salon node with its own database, the full API, and control of printers, drawers, scanners and fingerprint readers
  • Thin clients: any phone, tablet or laptop can be a till

Equipment control

  • A deterministic state machine per bed in a single gatekeeper process that owns the serial ports
  • A command queue as the only seam between the API and the hardware
  • Fault attribution that says plainly whether a problem is the timer hardware or the platform

The business around it

  • Point of sale, pricing and promotions; compliance records with consent and fingerprint sign-off; bookings and a walk-in queue
  • Import and cutover from the incumbent system
  • Tenant provisioning, tenant-scoped restore and consent-gated support sessions

Engineering decisions

Fail closed, but never stop a session

Any ambiguity that could switch a bed on is refused. Equally, automation never stops a session a person started, because a bed cutting out mid-tan is its own safety problem.

Protocols from the primary source

Hardware protocols are implemented from the manufacturers' protocol documents, not from summaries, and bed control carries the highest test bar in the platform.

No standing access to tenant data

Support sessions need the salon's consent. The platform operator can't simply browse a customer's records.

The node is a choice

Cloud-only salons are first-class. Each capability the node brings is the owner's decision.

Outcome

The platform is specified to build-step level, with 362 steps carrying their own invariants and verify checks, a register of 115 design decisions, a design system with tokens and components, and bench hardware set up for protocol work.