A Two-Sided Laundry
Marketplace, One App
A user-and-vendor on-demand laundry app for the Indian market, with full booking, dispatch, and payout flows on both sides of the transaction.
"Two-sided marketplaces fail when the two sides feel like two different products. Dr. Clothes was designed as one app with two doors, so the customer and the vendor live inside the same operational reality."
Role
Product Designer
Client
Dr. Clothes
Market
India
Status
Designed & handed off
One App, Two Roles
Login As chooses the door. Everything downstream diverges from there.
01 — The Context
Laundry is one of the most reliable on-demand categories in urban India. Working professionals in flats without washing machines, students in shared housing, dual-income households with no time for a wash-and-press cycle. The demand is constant and the unit economics are clean.
The supply side is a fragmented landscape of neighbourhood dhobis, small laundromats, and dry-cleaning shops. The category has been "solved" several times. Most attempts run a customer app and operate the supply side through phone calls, WhatsApp groups, and a spreadsheet. That works at twenty vendors. It breaks at two hundred.
The demand
Constant. Working professionals, students, dual-income households.
The supply
Fragmented. Neighbourhood dhobis and small laundromats, a few blocks each.
The gap
Customer apps exist. Vendor operations still run on WhatsApp.
Dr. Clothes came to us with a clearer thesis. Build a single mobile platform with two roles. Customers book, track, and pay through one surface. Vendors accept, manage, dispatch, and get paid through the other. Same app. Same brand. Same operational reality on both sides of every order.
02 — The Bet
One app. One design system.
Two doors at the front.
— 01
One app, role-gated
The default move in two-sided marketplace design is two separate apps — one for customers, one for vendors. It's the path of least resistance for engineering and the path of greatest divergence for the product. We bet on a single app with a role gate at the front door. Both sides share the same design system, component library, notification model, and support surface. A new feature ships once and lands correctly on both sides.
— 02
Dashboards built around real priorities
The second bet was on what to surface to each role. Customers care about laundry arriving back on time. Vendors care about cash flow and order velocity. We built the dashboards around those priorities specifically, rather than mirroring features across roles for symmetry. The vendor portal opens to revenue and order counts — the two numbers a vendor checks every morning.
03 — My Role
Product Designer
Customer App
Home, service catalog, booking funnel, scheduling, payment, order tracking, history, and profile.
Vendor Portal
Dashboard, order pipeline (Pending / Confirmed / Processing), order detail with customer contact, delivery assignment, services and pricing management, transactions and withdrawal.
Role-Gated Onboarding
The two-screen illustrated intro and the Login As gate that routes customers and vendors into their respective app contexts from the same install.
Shared Design System
The component library that holds both roles together — buttons, cards, modals, status pills, tabs, form components. One system, two contexts.
Payment Integration
Worked alongside engineering on the UPI, Paytm, and card gateway integration and the line-itemised cart and receipt model.
Live Order Status
The shared state model that drives both the customer's "Laundry in Progress" surface and the vendor's order pipeline simultaneously.
"Customers care about laundry arriving on time. Vendors care about cash flow and order velocity. We built the dashboards around those priorities specifically, instead of mirroring features across roles for symmetry."
04 — The Build
The Architectural Decision
The role gate at onboarding
A new install runs through a two-screen illustrated intro — fast laundry service, on-time delivery — and lands on a single decision: Login As User or Vendor. The choice routes the user into one of two app contexts that share the visual language but diverge in navigation and content.
Sign-up uses OTP for users (low friction, India-native) and a longer registration flow for vendors (name, email, mobile, password, with KYC and shop verification handled separately). The gate is the entire product architecture in one screen.
The home screen surfaces six service categories as a primary grid. A special offers carousel sits above for promotional pricing. A "Laundry in Progress" status card with a progress ring surfaces the active order directly on the home screen. A trust block — Best Experience, Fabric Care Washing, Location Delivery, Brand Trust Priority — closes the screen. Indian users hand their clothes to strangers; the app has to do the trust work that a familiar neighbourhood dhobi does naturally.
Six service categories, active order status, promo carousel, and trust signals.
Select items and quantity, choose pickup time and address, apply promo code.
Line-itemised cart, discount, and tax. UPI default, Paytm and card fallback.
Payment supports Visa, UPI, and Paytm — UPI is the default because it is what Indian users actually use. The cart surfaces line-itemised totals, discounts, and tax with the final amount called out prominently. No hidden charges, no surprise at checkout.
The vendor portal opens to a dashboard with four order tiles (Total Orders, Accepted Orders, Pending Pickup, Ready Pickup) and four status counters (Delivered, Cancelled, Returned, Failed). Revenue surfaces sit below — Total Earned, Paid Amount, Pending Amount — visible at a glance. This is the screen a vendor opens every morning to see what they made yesterday and what is on the work board today.
Four order tiles, four status counters, revenue summary at a glance.
Pipeline view — Pending, Confirmed, Processing — with customer contact on every order.
Transaction history and a one-tap withdraw flow. Money out, fast.
The withdraw flow is intentionally simple. Vendors care about how fast money moves out of the platform, not how many fields they can fill in. Services and pricing live in their own surface — vendors can add or remove services and set per-item prices, giving the platform supply-side flexibility for both single-service operators and full-service laundries.
05 — The Shared Design System
Both apps share a single design system. A new feature ships once and lands correctly on both sides.
Colour
Aqua-green primary · Orange and teal accents · Unified across both roles
Typography
Same type scale and weight hierarchy for customer and vendor surfaces
Components
Buttons, cards, modals, status pills, form fields, tab bars — all shared
Iconography
Restrained and trade-friendly — readable at small sizes on mobile
Component sheet — shared across both roles
Primary Button
Status Pill
Status Pill
Status Pill
06 — Tech & Stack
07 — What It Unlocked
Dr. Clothes is the project where we built the playbook for two-sided mobile marketplaces.
The decision to ship one app with two roles rather than two separate apps saved meaningful engineering time, reduced design system fragmentation, and produced a product that reads as a single platform to anyone interacting with it.
Vendor dashboard pattern
Four operational tiles, four status counters, revenue visible at the top. It has become a reference layout whenever a marketplace partner needs an operations surface.
Role-gated onboarding
Login As, with role-specific sign-up flows downstream, is now a default pattern for any subsequent two-sided product we take on.
Supply-side respect
The hard part is not the customer flow. The hard part is the supply side. Vendor adoption lives or dies on whether the operations surface respects their actual workflow — a paper notebook and a WhatsApp group.
"Two-sided marketplaces fail when the two sides feel like two different products. Dr. Clothes was designed as one app with two doors."
"Vendor adoption lives or dies on whether the operations surface respects their actual workflow. In Indian local businesses, that workflow is a paper notebook and a WhatsApp group. The app has to feel like an upgrade to that, not a replacement of it."
"Customers care about laundry arriving on time. Vendors care about cash flow and order velocity. We built the dashboards around those priorities specifically, instead of mirroring features across roles for symmetry."
Start a Project
Building a two-sided marketplace?
We know what the supply side actually needs. Let's talk.
Start a Conversation