Laundry POS + Ops — 40k+ loads processed across a multi-branch chain

The problem

A neighborhood laundry chain with multiple branches was running the entire operation on paper tickets. A load would come in, a handwritten receipt got torn off, and that receipt was the only tracking artifact until pickup.

Two failure modes were happening weekly:

• Lost tickets. Torn receipts + wet counter + busy day = a customer shows up with no ticket, and staff has to hunt through bins.
• Pricing disputes. Per-kilo pricing done on paper leaves room for arithmetic errors. Customers dispute totals; staff can't reconstruct the calculation.

Off-the-shelf retail POS tools weren't a fit. They're built for grocery / cafe workflows (add to cart → pay → done), not for the laundry lifecycle where a load has a multi-day journey (pickup → wash → dry → pack → out) with a customer callback at the end.

Constraints

• The workflow IS the product. The POS had to model the actual lifecycle, not force staff to invent workarounds. Pickup ≠ paid ≠ ready ≠ out. Each state matters and has different UI needs.
• Pricing that reflects reality. Per-kilo (regular wash), per-item (special garments, dry cleaning), and combo pricing (wash + fold + special care) — all on the same order.
• Offline-first. Neighborhood shops in Manila lose internet regularly. The POS had to keep taking orders when the connection drops, and sync when it's back.
• Cheap thermal printer support. Not a fancy $300 printer — the generic ₱2,500 ones from the local supplier. Meant supporting ESC/POS commands directly.
• Multi-branch reporting. The owner runs multiple locations and needs aggregate numbers from one dashboard.

What I shipped

• Ticket lifecycle with SMS pickup alerts. Every load moves through pickup → wash → dry → pack → ready. When a load flips to “ready,” the customer gets an SMS. No more “let me check if your clothes are done” phone calls.
• Weight-based, item-based, and combo pricing rules. Configurable per branch — manager can adjust the per-kilo rate for a promo week without a dev.
• Barcode / QR tag printing for every load. Each ticket prints a barcode tag that gets attached to the physical load. Scan to look up, scan to advance state, scan to close. No paper hunting.
• Multi-branch reporting: loads processed, revenue, staff performance (loads per hour, average ticket size).
• Offline-first. The POS holds all writes in a local queue when the network is down. When it comes back, the queue drains with conflict resolution (last-write-wins on ticket state, sum-of-writes on revenue).

The hard parts

ESC/POS printer support. Cheap thermal printers don't have modern SDKs — they speak ESC/POS, a byte-level protocol that predates the web. I built a small ESC/POS driver that talks to USB printers directly, generating receipts + barcode tags with proper cut commands and thermal-optimized layouts. Works with any printer the shop already has, not a specific model.

Offline-first for a POS is genuinely hard. Not just “cache the app shell” — the app must accept new orders, mutate ticket state, and print receipts while offline, then reconcile when the network returns. Built on a local IndexedDB queue with write-ahead logging. Server state wins on ticket lifecycle. Client state wins on new writes (a customer paid, regardless of what the server thinks).

SMS gateway costs. SMS in PH isn't free. Integrated with a local SMS provider (cheaper than Twilio here) and built dedup — the same customer doesn't get a “ready” SMS twice if a staff member accidentally re-flips the state.

Multi-branch data model. Every entity (staff, load, product, price rule) has to be scoped to a branch, but the owner needs cross-branch views. Row-level security in Postgres + branch-scoped queries at the ORM layer prevents accidental data leakage between branches.

Result

Multi-branch · 40k+ loads processed. Zero lost tickets since launch (measured against the 1–2 per week baseline before). Pricing disputes essentially eliminated — every receipt shows the calculation.

The owner runs the whole chain from a mobile dashboard. Staff onboard in about 30 minutes.

What I'd do differently

Should've invested earlier in staff-facing analytics. Right now, only the owner sees the numbers. Showing each staff member their own “loads processed today” is a small feature that builds real ownership. Adding it now, but should've been v1.

Takeaway

POS software is not a solved problem. Off-the-shelf retail POS tools are built for grocery + cafe workflows. Every other kind of shop (laundry, salon, tire shop, print shop) is running paper because nobody's built for their lifecycle. Vertical-specific POS is an underexplored space — especially in markets where labor is cheap enough that “the workflow is bad but people just deal with it” has been the equilibrium for decades.