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 in v1
A light booking layer — most salon traffic walks in, so appointments assist the day instead of running it.
Staff check in and out at the front desk — feeds payroll and incentives with zero re-entry.
Open and close the day in one action — the cash drawer and reports snap to the shift.
PWA — add to home screen on the front-desk Android and the owner’s phone. No app store between us and a fix.
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 ever had — twelve weeks, not twelve years.