Product-AI
LaundryHub POS
LaundryHub replaces the paper register at the counter of an Indian laundry. It has to take an order faster than a pen can, print a garment tag on a stubborn thermal printer, and give the owner numbers they will still believe after they have questioned them.
- Client
- Laundry Hub
- Role
- Solo product designer & builder
- Year
- 2026
Overview
India has roughly five thousand two hundred crore rupees of laundry work a year running through shops with no software at all. LaundryHub is an operations app for the person behind that counter: one screen that takes the order, prints the tag, tracks the garment, collects the money and tells the owner what the day actually earned.
The product is white-label. The platform is called LaundryHub every screen a customer ever sees carries the shop's own name, the shop's own logo, and a brand colour the app pulls out of that logo. A receipt from VClean says VClean. That constraint shaped a surprising amount of the visual system.
I designed and built it end to end: the research, the information architecture, the flows, the design system, the prototype and the production Flutter app. It has been running a real laundry in Hyderabad since 2026, and everything described here as shipped has been used by that shop.
Take an order in under 45 seconds
Weigh or count, price, tag, take the money, print. Repeat while three people wait.
Know where every garment is
Five stages, one board, and an automatic message to the customer when it is ready
Numbers that survive being questioned
What came in, what leaked out, who gave the discount, without a calculator.
A shop can be live in an afternoon
Sign up, import a price list, pair a printer. No installation visit, no hardware to buy.
The Challenge
The competition was not another app. It was a paper register that costs nothing, never crashes, and everyone in the shop already knows how to use. Two different people suffer for it, in two completely different ways.
A register is genuinely good at some things: it is instant, it works in a power cut, and it does not care that the person holding the pen has soap on their hands. Anything replacing it has to be at least as fast at the counter before any of the benefits further down the line matter at all.
What it is bad at only becomes visible later, and it is expensive. These are the problems the product was built against every one of them shows up again in section 10 with the thing I built for it.
What the counter staff is up against
- Bills written by hand while the next person waits, then a slip torn off that gets lost or misread.
- No way to record a bill except typing on a phone with damp fingers, fighting a soft keyboard.
- Garments identified by memory. A shirt comes back from the plant with no tag and nobody can say whose it is.
- Money that never matches the bill: round numbers handed over, change waved away, two people paying for one order.
- A mistake at the counter has no way back and the customer has already been told.
- The app is in English. The person using it often does not read English.
What the owner is up against
- No view of what is washing, ready or overdue without physically standing there.
- Around forty to fifty thousand rupees a year walks out of the counter and cannot be pinpointed. Not unsuspected unprovable.
- Revenue estimated. Tax scrambled together at month end. Discounts given at the till surface nowhere.
- More than two hours a day on manual accounting: around six hundred hours a year producing numbers they still do not fully trust.
- Regular customers forgotten, because the register has no memory.
- Every staff member can see everything, including the takings.
Users & Context
Four kinds of people, one shared device, and a physical environment that decides more about the interface than any preference does.
| ROLE | WHAT THEY ARE DOING | WHAT THE DESIGN OWES THEM |
|---|---|---|
| Owner | Often not in the shop. Wants to know what today earned and whether anything is going wrong without ringing the counter. | Everything, including the money. The only role that can see aggregate revenue, cash flow, or reports at all. |
| Manager | Runs the floor, sets prices, publishes discounts, handles complaints. | Full operational control and no revenue totals. They manage the shop they do not audit the owner's takings. |
| Counter staff | Takes orders, weighs, tags, collects money, prints. Under time pressure, standing, hands wet. | Speed and safety. They can apply a discount the owner published, never invent one. They never see stock costs or revenue. |
| Platform admin | Approves new shops, answers support tickets, handles billing across every tenant. | A separate console, and deliberately no window into any tenant's money. |
What the shop imposes before a single pixel is drawn
Wet hands, standing up
The person using this has just handled damp clothes. Small targets and a soft keyboard that fights a bottom sheet are not viable. Nothing important is smaller than 48 dp.
One phone, one counter
An inexpensive Android phone, shared by whoever is on shift. Not a tablet, not a till. Everything is designed for a thumb on a phone, and the desktop build letterboxes into the same column rather than pretending to be a desktop app.
A queue, always
Every extra tap has a person standing behind it. The order of the steps follows the physical order of the work: clothes first, customer last, because the clothes are already on the counter.
A thermal printer that fights back
Fifty-eight millimetre paper, no cutter, a lossy Bluetooth link, and a label printer that jams if the paper size is wrong. It cannot be treated as an output device. It is a design constraint with opinions.
Twelve languages
The owner may read English. The person at the counter often does not. Each language is listed in its own script, and any role can change it from their own profile.
Money that never matches the bill
Customers hand over a round number. Change gets waved away. Two people pay for one order. None of these are edge cases here; they are the normal case.
Research & Insights
Three sources: one shop I could stand inside, the incumbents' own users complaining in public, and a market that is ninety-five per cent unorganised.
Working alongside one real counter
VClean in Sangareddy became the whole research programme, and later the first live tenant. Watching intake, tagging and handover in person produced most of the non-obvious requirements: the half-kilo weighing habit, the fact that piece counts are estimated from weight and then corrected by eye, the way a bag is the unit people actually think in, and how often the amount collected is not the amount on the bill.
The rest came from the owner's own complaints once the app was live, which turned out to be a better research instrument than anything I could have run beforehand. A screenshot from the shop floor is a usability finding with a timestamp on it.
The owner's real question is not "what did I earn"
It is "is anything leaking". Revenue is easy and reassuring. What they could not get from a register was the size of the gap: cancelled orders, counter discounts, refunds. That became the spine of the reports work.
A discount and a coupon are not the same event
A coupon is a campaign the owner published. A counter discount is a cashier deciding at the till. Only the second one is a trust question, and until the app separated them it was invisible.
Printing is not a feature, it is the product
If the tag does not print reliably, staff go back to paper ticketing and every other digital benefit collapses with it. The printer earned more design time than any screen.
The counter cannot be trusted with a text field
Not because of the people, but because of the situation. Anything free-form under time pressure becomes a data problem later: unmatched customers, invented discounts, unreadable notes.
What owners find hard in the other apps and what this does instead
| THE DIFFICULTY OWNERS REPORT | WHAT THIS PRODUCT DOES INSTEAD |
|---|---|
| Price-list changes are painful, and support exists only as a ticket queue | The owner edits their own catalogue in the app, imports a whole price list from a spreadsheet, and reaches a human on WhatsApp. |
| No consumables management reported of the Indian incumbent, which claims more than fifteen hundred locations | Inventory ships, and is deliberately visible only to owner and manager, because stock levels are a cost surface. |
| Software that assumes a till, a terminal and a back office | Runs on the Android phone already in the shop. A Bluetooth printer is optional and never required to take an order. |
| English-only interfaces, in shops where the counter does not read English | Twelve languages, each listed in its own script, changeable by counter staff from their own profile without asking the owner. |
| Compliance built for somewhere else | Per-tenant GST rate, GST-compliant invoices, and one-tap GSTR-1 and Tally exports from the Reports screen. |
| Switching cost is the incumbent's real moat | A designed seven-day human-led switch: price list and customers imported on day one, the old system left running as a backup until the owner decides. Designed and prototyped; not currently shipped. |
Problem Definition
That tension is the whole design problem. Almost every decision in this project is a trade between the speed the counter needs and the legibility the owner needs, and the counter wins every time it is a genuine conflict, because a system the counter abandons produces no data at all.
How might we make recording an order faster than writing it down, for someone with wet hands and a queue?
How might we treat short, over and split payment as designed outcomes instead of errors?
How might we make money leaving the shop visible and attributable without accusing anybody?
How might we let an owner see the shop's money without exposing it to everyone who works there?
How might we report numbers an owner will still believe after they have questioned them?
User Journey
The shop's day has a shape, and the app was designed to sit inside that shape rather than to be opened on purpose.
Information Architecture
Four tabs, one counter button, and a drawer that changes shape depending on who is holding the phone.
The counter action is not a tab
Taking an order is used more than every tab combined. It sits in the middle of the bar as an unlabelled brand-coloured circle, opens full screen outside the shell, and disappears entirely for roles that may not use it.
Locked, not hidden
A tab a role cannot open still renders, with a lock and a plain sentence naming the role it belongs to. Hiding it makes the app look broken and different on every phone; locking it teaches the shop how the roles work.
Every row has a subtitle
No bare nouns in the drawer. "Printing & Tags" reads "printers, paper size, receipt template", because the person looking for it does not know what we called it.
Key User Flows
Getting a shop live
Email, then a code
No SMS at signup. An owner should not be blocked from trying the product because a message gateway is not configured yet.
Owner, store, tax, logo
Four steps, and the tax number is skippable. Asking for a GSTIN before the shop has taken an order is asking too early.
An honest hold screen
Approval is manual. Rather than hide that, the wait screen lists what is being checked and offers a direct line to a person.
Pre-flight check
Test print, test message, hardware readiness before the first customer, not during them.
Key UX Decisions
Customer Lookup “I know him as Shashi”
- One field searches by name or phone, with debounce.
- If no match, open Quick Add using the entered value; ask only for the missing name/phone.
- Phone is mandatory to link repeat visits and history.
- Quick Add remains available even if lookup fails.
Product Search “Which Shirt?”
- Search ignores category tabs and returns a flat, de-duplicated list.
- Show the parent category + price with each result.
- Allow the same product name across categories with different prices.
Voice Billing “Say the Bill”
- Support English, Hindi and Telugu voice input.
- Process entirely on-device using speech recognition + rule-based parsing.
- Use synonyms to map spoken terms to catalogue products.
- Unmatched items become actionable chips, never silently dropped.
- Always require confirmation before adding items.
- Keep it as a compact microphone action, not a large hero panel.
Payment Differences “₹552 Bill, ₹550 Received”
- One payment flow handles short, over, split and round-off payments.
- Short payment: require a reason and record the difference as a counter discount within the owner's cap.
- Overpayment: small change becomes round-off income; larger amounts require Return or Advance.
- Split payments use the same settlement logic as single payments.
- Deduplicate round-down options.
- Walk-ins cannot receive Advance, since there is no customer record.
Problems the owner has, once a day and at month end
Where did the money go?
- Show a money leakage card covering:
- Coupon discounts
- Manual counter discounts
- Refunds
- Cancelled orders
- Round-off
- Separate coupon discounts from manual discounts—only manual discounts represent cashier discretion.
- Sort by highest value first with a magnitude bar showing the same percentage displayed in the row.
- Let the ranking surface the largest sources of leakage, rather than hiding significant losses in a fixed order.
Discount Attribution “Who gave that discount?”
- Show a staff performance card with orders, collections, discounts, discounted orders and cancellations.
- Track order ownership and payment collection separately, since different staff may handle them.
- Most discounts came through coupons, so focus on which coupon was used and how often, rather than manual discounts.
- Flag unusual discount rates, not just total discount value, so high-volume staff aren't automatically flagged.
Receivables “₹1.06 lakh that wasn't owed”
- Count only delivered orders that remain unpaid as receivables.
- Orders that are placed, in-process or ready are treated as work in progress, not money owed.
- Keep receivables all-time, independent of dashboard date filters.
- Reverted deliveries automatically drop out of receivables.
Payment Differences “₹552 Bill, ₹550 Received”
- Refresh dashboard data when:
- A new notification arrives
- The app returns to the foreground
- Live order changes occur
- Coalesce frequent updates without dropping genuine changes.
- Keep existing numbers visible while refreshing—no disruptive loading spinner.
- Show an “As of” timestamp on the dashboard/widget so users know how fresh the numbers are.
Design System & UI
One accent colour, deliberately quiet semantics, warm paper instead of grey and every bit of it built to be overridden by a shop's own brand.
The pivot, and why it was not cosmetic
The first palette was electric indigo, pulled from the client's logo. When the product became a platform, the accent had to become the colour it wears when nobody has told it otherwise and it had to survive being replaced by any shop's own colour without the interface falling apart.
Quiet on purpose
The semantic colours are desaturated. A shop screen shouting in four saturated colours stops meaning anything, and this one has to carry a genuine warning an order about to breach its promise without competing with itself.
One exception to semantic colour
Dispatched takes the shop's own brand colour rather than a status colour. That is the moment the order is out in the world with their name on it, and the interface says so.
Money in tabular figures
Amounts use tabular numerals and animate on change, so a column of rupees lines up and does not shuffle as it loads. On a screen whose only job is being believed, type that dances is a credibility problem.
Section headers that are not decoration
Eleven-pixel all-caps with a brand dash in front. They exist because the home screen carries six unrelated things and the owner needs to skip five of them in a glance
Never pure black
The dark ground is a very dark warm grey. Pure black smears on the cheap OLED panels these phones ship with, and the app is used in a bright shop all day.
Usability Testing
Not a lab. One phone, one real shop, one rule: nothing goes live until it has been used on that device, in that shop.
This is a small-team method and it has an obvious weakness: a sample of one shop. What it buys in exchange is that every finding is real. Nothing on this list came from a review, a checklist or my own second read. All of it came from the app being used to run a business.
Findings that no amount of desk review produced
- "1 orders." The count was never pluralised. It had passed every review, because reviews read code and this only exists on a screen with a one in it.
- "14 cancels." Not a word the shop uses. It reads as jargon in a place where the owner is already suspicious of the number next to it.
- "The partner called it cluttered." The order screen had a row of status buttons and a separate timeline below, restating the same journey twice. It became one vertical stepper where the current step carries the next action.
- Two cards, one word, 6.8 times apart. An owner's screenshot triggered the largest rework in the project.
- "This blank strip is the gap I want gone." The paper feed after the last garment tag had been tuned for a different printer and overshot on the shop's actual one, wasting paper on every single order.
- "Paper rolls back totally." A gap-sensor label printer configured as continuous reverse-fed uncontrollably. That became a per-printer switch, saved against the printer's own address.
- The app was hoarding install files. The old update package lingered and showed up as cache in the phone's settings. Tenants complained, on phones where storage is genuinely scarce.
- "Can't load widget." The home-screen widget failed to add at all a layout the Android widget host does not permit. It compiled perfectly. Only adding it to a real home screen could have found it.
Iterations
Four things that came back from the shop, and what changed because of them.
Four rounds on a single screen
The reports screen was rebuilt four times, and the sequence is worth reading in order because each round exposed the next problem:
- Round one correct the numbers. Coupon discounts were separated from counter discounts, and the leakage view was born. The screen looked almost unchanged, which was itself a finding: the owner reported that nothing had happened.
- Round two agree what a word means. "Collected" was redefined as the payments ledger everywhere, and the chart rebuilt from those same rows. The tax basis was deliberately left alone and flagged.
- Round three fix the order of things. Nine cards at equal weight became three named groups: money, where it went, compliance. Two tiles were deleted outright, and a summary banner that restated the tiles directly above it was dropped.
- Round four stop the chart lying. A negative bucket had been drawing nothing at all, so a refund-heavy month showed a floating label over empty space. Bars now scale on magnitude and hang below a zero line in the error colour, so money going out looks like money going out.
Final Experience
The shipped app. Each screen captioned with the problem from section 10 that it exists to solve.
Impact / Outcomes
One shop is not a result set. So this section does two things: it says what happened to each problem, and it separates what is true from what the design is aiming at.
| SOLVED | Wet-hand entry, and the speed of the counter. Weight, count and payment are all enterable without a soft keyboard. The under-45-second target is a target, not a measurement. |
| SOLVED | Repeat customers lost as "walk-in". Name-or-number search plus quick-add; the phone number links the visit to its history. |
| SOLVED | Tag batches desyncing and double-printing. Batches of eight, one size command, clean failure instead of a blind resend, and a hard stop at the wrong label size. |
| SOLVED | Short, over and split payment. All three are designed outcomes with one settle path, a required reason, and an owner-set cap. |
| SOLVED | Counter discounts being invisible. Coupon and manual discount are now separate lines, sorted by size, and attributable to a person. |
| SOLVED | Aggregate revenue leaking to every role. Owner-only in the client and on the server, all the way out to the home-screen widget. |
| SOLVED | Numbers that contradicted each other. One definition of "collected", a chart drawn from the same rows, a re-based average ticket, and deltas that no longer assert good news. |
| PARTLY | The customer chasing their own order. The order-ready message and the public tracking link are built and fire automatically but only if the shop has configured its own WhatsApp provider, which a small laundry never will. The platform-level fallback is a pricing decision, not an engineering one, and it is not mine to make. |
| OPEN | Pickup, delivery and dispatch. Designed and prototyped, deliberately unbuilt: the shop that actually uses this does not run deliveries. |
My Contribution
Research & definition
Field observation at the counter, owner interviews, competitor teardown, market sizing, and the prioritisation model that decided what not to build.
IA & flows
The four-tab shell, the role and permission model, the point-of-sale wizard, the payment branches, the order pipeline and its undo, and the onboarding and activation gate.
Design system & UI
Colour, type, spacing, radius, elevation and motion tokens the component kit the white-label theming that lets a shop's own colour take over twelve localisations.
Prototype
Twenty screens at device size in light and dark, built as real interactive screens rather than artboards, used to settle scope and density arguments before build.
The shipped app
The production Flutter build, the printing layer for thermal receipt and label hardware, the reporting work, and the release discipline behind it.
Live support
Running the first tenant: triaging what came back from the shop floor, and turning owner screenshots into the iteration
Next Project