Live on Google Play, startup productLaundry pickup for Jaipur, on Android, iPhone and the web. I designed it with the founder and I'm building every part of it.
For the people using it
I lived it, first in Pune and now in Jaipur. The man who pressed our clothes closed his shop, and we were back to asking around for someone new. A quick-commerce app for laundry, where you book a pickup and your clothes come back clean, was nowhere to be found here.
For the founder
He needed customers on Android, iPhone and the web, an app for the laundries and an admin panel to run it all, quickly and on a startup budget. With cash on delivery and a launch offer, the money had to be impossible to cheat. That's where I came in: we worked out the product together, I designed every screen, and I'm building all of it.
The app had to feel premium while the costs stayed as low as possible.
Separate Android, iPhone and web apps would triple the time and cost for a team of one.
If the partner side was hard to use outdoors, with one hand and cash in the other, orders would stall.
In a city this size, one wrong bill or lost order spreads by word of mouth. The launch had to be right.
Kotlin Multiplatform shares the screens, rules and models, so a fix lands once.
The catalogue, prices, promos, service areas and notifications change from the admin portal, with no app update.
One-time codes go over WhatsApp's Cloud API at about ₹0.14, against roughly ₹6 for SMS.
Pricing, promos, the order state machine, OTP and settlements are tested.
Sign in
Codes come over WhatsApp: no password to forget, about 40× cheaper than SMS.
The code arrives where people already are and fills itself in on Android. It's stored as a salted hash with an expiry and an attempt limit, checked inside a transaction.
Home
A service-area check decides what you can order; the banner and services come from the admin portal.
Location is asked right after sign-in, with a screen that explains why first. Outside the launch area, people join a waiting list instead of hitting a dead end.
Pick clothes
The estimate is honest about being one. The real count is agreed at your door.
Steppers on every item and a running total at the bottom. It's an estimate on purpose: the partner counts with you at pickup and the bill updates there and then.
Pickup and bill
Totals come from a Cloud Function, never from the phone.
The app sends item ids and counts only. One Firestore transaction checks the price, the slot, the service area and the promo, and takes the order number, so a failed order can never use up a promo.
Order placed
Permissions are asked when they're needed: notifications only after the first order.
The order number, the pickup window and the cash amount, plus one line about what to do. Notifications are only asked for now, after the first order, never at launch.
Track
Only Cloud Functions can move an order; the app can't skip a step.
Each tap in the partner app stamps a time and reaches the customer and the admin board. No live GPS, just a clear, timed list and a button to call your partner.
Layer 1
Compose Multiplatform draws the same screens on Android, iPhone and the web, in Cloth Lab's own design system.
Layer 2
Every feature, view model and rule lives once, in shared Kotlin: data, domain and presentation layers, wired with Koin.
Layer 3
Firebase Cloud Functions price orders, check promos, move order stages and send the pushes. Deny-all Firestore rules mean nothing else can.
The founder runs Cloth Lab from the admin portal. Almost everything a customer sees comes from data, so a new banner, price or service area is live in one click.
Washing, drying and ironing can be added between Picked up and Ready.
A state machine in the Cloud Functions decides every move, and deny-all Firestore rules mean no app can write an order, a user or a settlement directly.
My own OTP flow on Meta's Cloud API: salted hashes, rate limits and attempt counts, with Android autofill. SMS verification costs about forty times more.
≈ 40× cheaper per sign-inThe catalogue, orders and addresses sit in Room with a connection banner, so a weak signal never blanks the app. Location is asked after sign-in with a reason, notifications after the first order.
The admin board treats the first snapshot as a baseline and ignores cached ones, so every genuinely new order rings once, and never twice. It's covered by tests.
The customer app and the partner app are live on Google Play, and the admin portal runs the business. The marketing launch in Jaipur comes next.
The whole product: customer apps, an app for your partners, an admin portal and the backend, designed and built by one person who answers for all of it.
An app that puts your service in people's pockets and gives you one screen to run the day: orders, partners, cash and offers.
Someone building one codebase for Android, iPhone and the web, who knows where to share code and where not to.
Product thinking, design and engineering in one, with the security and tests a real business needs.