Londrin
On demand laundry pickup and delivery
Frontend Engineer + Project Manager | March 2026 to present | React Native Expo, Next.js, YouTrack, Tailwind, REST API, state management
On demand laundry pickup and delivery.
KRISPAY reaches people willing to walk into a branch. The company wanted a different group, people with no time to do laundry at all, so it needed a new product that takes orders from anywhere, not another version of the self-service system.
One order involves three sides (customer, courier, and branch) and each can get stuck on its own. The courier arrives before the customer is ready, the branch finds the load heavier than the estimate so the price changes, or the wash is done but no courier is free to deliver. The system has to keep one order status in sync across all three.
An order can get stuck at different points depending on who acts next. So I built the status flow as a fixed set of steps, instead of one vague "processing" state that hides where the order really stopped: waiting to be accepted, picked up, weighed and checked, washing and drying, ready, out for delivery, done. That meant locking the delivery address once the order is placed, because letting it change halfway would change the delivery fee and the branch we already picked. The trade off: a customer who types the wrong address has to cancel and order again. I took that over letting an order run on a price that no longer holds.
The real weight is only known once the branch puts the load on the scale, but the customer already has a price in mind from the estimate. So I made the app ask the customer to approve before final payment when there is extra load, so they choose whether to wash it or not, instead of quietly charging the difference. The trade off: the order takes one more step and can sit waiting for a reply. I took that, because charging more than quoted without asking is the fastest way to earn a complaint in any service priced by weight.
Running our own couriers at launch made no sense when we could not predict order volume yet. So I went with GoSend for pickup and delivery instead of hiring drivers. That made the fee depend on how far the customer is from the branch, so I built automatic nearest branch detection instead of showing a list and letting people guess. The trade off: pickup times and prices depend on someone else, and the system needs accurate branch locations on every order. I took that, because covering a wide area from day one mattered more than owning delivery.
Branch owners needed to manage their own services, vouchers, and staff without asking head office every time. So I built the merchant panel as a separate Next.js dashboard instead of squeezing branch management into the mobile app. Owners work on a desk screen, customers on a phone, and the two do not fight over the same layout. The trade off: it needs careful access rules so one merchant's changes never show up in another's data.
- -A seven-step order flow that stays in sync across customer, courier, and branch
- -Three user roles in one system: customer, partner courier, and merchant
- -Works with Midtrans for payments and GoSend for pickup and delivery
- -Merchant owners manage their own services, vouchers, and staff from a Next.js dashboard
- -I planned the features and the product flow, and built the app side myself
I would look for cheaper delivery options than GoSend from the start, since delivery is the biggest cost in the price and the one I cannot bring down myself. I would also ask users what they actually need before deciding the features, instead of building on guesses and fixing it after launch.