Problem


Field research
So “close shift” = “close day”. One action.
Modeled as pass-throughs — generic POS gets this wrong.
This boundary shaped the whole permissions model.
No inventory costing → show service profit, not a fake total.
Core flow — billing



Progressive disclosure — discounts, splits, and tips stay hidden until invoked.
Core flows — operations


Every number traces back to a bill — nothing is hand-entered, nothing to dispute.
Core flows — owner at a distance



Also shipped

Appointments — a light booking layer; most salon traffic walks in, so appointments assist the day instead of running it.

Attendance — staff check in and out at the front desk, feeding payroll and incentives with zero re-entry.

Expenses — every expense logged where the money moves, feeding straight into the cash drawer and reports.

Shifts — open and close the day in one action; the cash drawer and reports snap to the shift.
Design decisions
Mobile salon UX is a different shape. 12 dedicated components, logic shared underneath.
Built a “Confirm Day” ritual, watched it add friction, deleted it. Shipping the deletion mattered more.
Living roadmap + conventions + tokens let AI agents build without re-deriving context.
One codebase for a team of two. Installs on the front-desk Android; fixes ship the moment we deploy — no app-store cycle.

Outcome
A real salon runs its money through Limvo every day — billing, payroll, the cash drawer.
The honest part:we engineered for scale we hadn’t earned — the bottleneck was customers, not code. Next time: gate engineering behind demand, not ambition. Cheapest expensive lesson I’ve had, this early.