Case Study
How a Garment-Care Service Runs Every Order, from Booking to Delivery, on One Platform.
A doorstep garment-care service needed customers, service partners, drivers, and its operations team to work from the same order. We built the mobile apps and operating platform connecting bookings, collection, service, return delivery, payments, and reporting.
- Mobile apps for customers, providers, drivers, and cleaning partners
- 4
- Operations dashboard for accounts, payouts, and reporting
- 1
- Service workflows: ironing and dry cleaning, from booking to delivery
- 2
The Challenge
The Work Continues after the Customer Books.
The business needed an operating system for the whole service, with a useful view for each person involved.
The Business Context
The business coordinates ironing and dry-cleaning services across customers, independent service partners, and drivers. Each booking includes more than the work on the garments: it needs a collection window, an available partner, transport in both directions, customer updates, and a record of what each participant has earned.
A booking screen alone could not run that operation. The system needed to know who had accepted the work, where the order was in its journey, which handoff came next, and when a payment or earning should be recorded. Ironing and dry cleaning also needed distinct service rules within a shared operating model.
- An available service partner and an available driver are different requirements. Collection and return delivery need their own assignments.
- Every handoff needs a clear status and confirmation so the next person knows when to act.
- Customer charges, partner earnings, tips, and payout records need to follow the same order.
- Operations staff need a way to review documents, resolve assignment issues, and see the activity behind the totals.
What We Delivered
We built four mobile apps for customers, ironing providers, drivers, and dry-cleaning partners, connected to shared backend services and an operations dashboard. The scope includes booking, availability-based matching, onboarding and training, collection and delivery confirmation, customer payments, participant earnings, payout preparation, notifications, and operational reporting. A supporting website provides service information and partner discovery.
The Solution
What the Service Needed, and What We Built.
01 / 04
One booking needs three people
- Service partnerOpen
- Collection driverOpen
- Return driverOpen
What the Service Needed
One Booking Needs Several People, Each Available at the Right Time
A service partner and a driver are different requirements, and collection and return delivery each need their own driver.
One booking needs three people
- Service partnerAccepted
- Collection driverAccepted
- Return driverAccepted
Documents verifiedTraining completeOn shiftClose enough
What We Built
Work Offered Only to People Ready to Take It
The system checks readiness, shift, distance, and daily limit, then each person accepts the job in their own app.
How We Built It
Four Mobile AppsReact NativeFor customers, ironing providers, drivers, and dry-cleaning partners
Matching by ReadinessNode.jsDocuments, training, shift, and daily limit are checked before work is offered
Location and DistanceGoogle MapsHow far a person is from the customer informs each assignment
Order data is held in MySQL, with Redis coordinating background work.
02 / 04
- Booked
- Collected
- Received
- Ready
- Delivered
Whose turn is it now? What the Service Needed
Every Handoff Needs to Be Clear
The order passes from customer to driver to service partner and back. Each person needs to know when it is their turn to act.
- Booked
- Collected
- Received
- Ready
- Delivered
Confirmation codeItem countDelivery photo What We Built
The Handoffs Are Part of the Order
Collection, receipt, item count, readiness, and delivery are each recorded. In-person handoffs use a confirmation code, and contactless returns need a photo.
How We Built It
- 01
One Order StatusEvery app reads and updates the same order journey
Updates When the Work ChangesFirebasePush notifications, with email and text messages, tell the next person
Proof of DeliveryAmazon S3The driver’s photo is stored against the order before it can close
Backend services run on Amazon EKS and are reached through Amazon API Gateway.
03 / 04
Which order does each amount belong to? What the Service Needed
The Money Has to Follow the Same Order
Customer charges, partner earnings, driver earnings, tips, and payouts all come from one order, and need to stay with it.
One order
- Customer payment
- Service partner earning
- Driver earnings
- Tips shared
What We Built
Payments and Earnings Recorded with the Work
The customer’s payment is captured within the booking and collection workflow. Amounts owed to partners and drivers, including tips, are recorded against the order.
How We Built It
Customer PaymentsStripeAuthorization, capture, and refunds are handled against the order
- 02
Earnings AllocatedEach order is split between the service partner, both drivers, and the platform
- 03
Payouts PreparedStaff prepare and finalize payout records for a chosen period
Earnings and payouts are their own records, so partners and staff see the same figures.
04 / 04
Which orders still have nobody assigned?
Whose documents need review?
What is owed for this period?
What the Service Needed
The Operations Team Needs to See the Whole Service
Staff review documents, resolve assignment problems, and need to see the activity behind the totals.
Operations dashboard
- Orders and assignments
- Documents to review
- Earnings and payouts
- Reports and exports
What We Built
One Dashboard for the Team Running It
Orders, accounts, document review, earnings, and payouts sit together, with reports that export to PDF and spreadsheet.
How We Built It
Operations DashboardReactOrders, accounts, document review, earnings, and payouts
- 02
Onboarding Brought InPartners submit documents and complete training in the app, and staff review them
Monitoring and AlertsGrafanaPrometheus and Grafana help the technical team investigate issues
Runs on AWS. Infrastructure is written as code in Terraform, and services are deployed with Helm.
The Order’s Journey, from Booking to Delivery
The Coordination Challenge
- One Customer Booking
A Driver Collects
A Service Partner Does the Work
A Driver Returns It
Several people handle the same order. The platform has to connect their availability, responsibilities, confirmations, and earnings.
The Connected Workflow
01 · Customer
Book the Service
Items, address, collection and delivery windows, and payment
02 · Driver
Match and Collect
Eligible partners, driver acceptance, and collection confirmation
- 03
Service Partner
Complete the Service
Receipt, item-count confirmation, and ready-for-return status
04 · Driver and Operations
Return and Record
Delivery confirmation, earnings, payout records, and reports
Operations staff can review the order and its assignments through the dashboard.
Technologies Used
React Native
Customer & Partner Mobile Apps
React
Operations Dashboard
Node.js
Order & Notification Microservices
MySQL
Data Storage for Microservices
Redis
Caching & Background Coordination
AWS Cloud
Cloud Infrastructure
Amazon S3
Documents Storage
GitHub
Version Control
Terraform
Infrastructure as Code
Helm
Microservice Deployment on EKS
Amazon EKS
Containerized Microservices
Amazon CloudFront
Content Delivery
Amazon API Gateway
Microservice API Access
Prometheus
System Monitoring & Alerting
Grafana
Monitoring Dashboards & Alerts
Stripe
Customer Payment Processing
Firebase
Mobile Push Notifications
Google Maps
Location & Journey Distance
How the System Was Built
- 01
Give Each Person the View Their Work Needs
Customers select a service, book collection and return windows, manage payment methods, and follow their orders. Partners manage their work and earnings. Drivers see collection and delivery jobs. Operations staff have a dashboard for the whole service.
Technical Detail: Give Each Person the View Their Work Needs
The backend uses a microservices architecture built with Node.js, Express, and TypeScript. Four React Native apps and the React operations dashboard access role-specific APIs, with business operations and notification delivery handled by separate backend services. Ironing and dry cleaning have distinct order models and status flows. The supporting website provides service information and cleaning-partner discovery.
- 02
Match Work to Availability and Readiness
The system considers whether a provider is ready to accept work, whether their shift covers the booking, how far they are from the customer, and whether their daily limit has been reached. Drivers have separate collection and delivery assignments.
Technical Detail: Match Work to Availability and Readiness
Provider eligibility checks include account setup, verified documents, background-check status, training completion, and shift availability. Matching uses location and distance checks; the driver flow also accounts for journey distance. Google Maps supports distance calculations, with results cached in Redis.
- 03
Make the Handoffs Part of the Order
The workflow records collection, receipt by the service partner, confirmation of the item count, readiness for return, and final delivery. In-person handoffs use confirmation codes. Contactless return delivery requires a proof-of-delivery photo before the order can be completed.
Technical Detail: Make the Handoffs Part of the Order
Backend checks tie each action to the assigned participant and the required order status. For contactless delivery, the driver uploads an order-linked photo through an S3 presigned URL. The service validates the upload and requires the proof reference before completion. Order logs preserve the transition history.
- 04
Keep Payments and Earnings with the Work
Customer payment authorization and capture sit within the booking and collection workflow. The platform records the amounts owed to service partners and drivers, including their share of tips. Staff can prepare and finalize payout records for a selected period.
Technical Detail: Keep Payments and Earnings with the Work
Stripe handles customer payment intents, capture, and refunds. Order calculations allocate provider, collection-driver, delivery-driver, and platform amounts. Separate earnings and payout records support partner views and administrative payout batches. Staff select the period, review the payout summary, and confirm finalization in the dashboard.
- 05
Bring Partner Onboarding into Operations
Providers and drivers submit their profiles and required documents through the apps. Operations staff review document status. Provider training includes lessons, questions, and recorded completion, linking readiness to the ability to accept work.
Technical Detail: Bring Partner Onboarding into Operations
The application includes document upload and verification workflows, background-check integration, and role-specific account controls. Provider lessons and answers are stored, and the eligibility checks use training-completion status. Versioned profile and document models retain changes.
- 06
Send Updates When the Work Changes
Order events trigger customer and partner updates. Scheduled reminders cover collection, delivery, work that is not ready, and documents approaching expiry. The operations team also receives notifications about unmatched orders.
Technical Detail: Send Updates When the Work Changes
The notification microservice consumes AWS SQS messages from the business services for email, SMS, and mobile push. Queue-based communication separates notification delivery from the order workflow. AWS SES, SNS, and Firebase Cloud Messaging provide the delivery channels. Scheduled jobs use Redis coordination, and event messages carry the order context needed by each recipient.
- 07
Give the Team a View beyond Individual Orders
The dashboard brings together orders, account records, document review, partner earnings, and payout preparation. Reports cover sales, revenue, order activity, provider work, and tax-related records, with PDF and spreadsheet exports.
Technical Detail: Give the Team a View beyond Individual Orders
The React dashboard reads operational data through administrative APIs exposed by the backend services. Reporting brings those records together for the operations team. Reporting includes monthly provider activity, quarterly tax summaries, and driver tax reports. A shared report component exports PDF and Excel files. The dashboard uses cached aggregates for its summary views.
- 08
Support the Service with Monitoring and Alerts
The cloud setup supports the apps and shared services, with monitoring dashboards and alerts to help the technical team investigate issues. Infrastructure definitions keep the environment configuration recorded alongside the application work.
Technical Detail: Support the Service with Monitoring and Alerts
GitHub holds the version-controlled code and infrastructure definitions. Terraform defines the cloud infrastructure, while Helm packages and configures microservice deployments on EKS. Amazon EKS runs the containerized backend services, Amazon API Gateway provides API access and routing, and Amazon CloudFront handles content delivery. Amazon S3 stores uploaded documents and delivery photos. Prometheus and Grafana provide monitoring, dashboards, and alerts across the services and their infrastructure.
The Results
An Operating Platform for the Whole Order.
What Was Delivered
The implementation connects booking, service work, transport, payment records, and partner earnings through shared order workflows. Each participant has an app suited to their responsibilities, while the operations team can review the order, manage accounts, prepare payouts, and investigate handoffs from one dashboard.
Operational Visibility
The same platform provides order history, delivery evidence, participant notes, earnings records, and reports. That gives operations and finance a record to work from when a customer asks about an order or a partner asks about a payout.
This account describes capabilities evidenced in the reviewed project and the infrastructure confirmed by the project owner. Order volumes, time savings, delivery-performance results, and financial outcomes have not been supplied.
What Changed for the People Doing the Work
- Customers
- Book the service, choose collection and return windows, manage payment methods, and follow the order’s progress from their app.
- Service Partners
- Manage availability, accept work, confirm receipt and readiness, and see earnings and payout history.
- Drivers
- See assigned jobs, move through the collection and delivery steps, confirm handoffs, and upload delivery evidence where required.
- Operations & Support
- Review orders and participant records, manage document checks, clear assignments when intervention is needed, and keep notes with the relevant account or order.
- Finance
- Review order-linked earnings, prepare payout batches, and export operational and tax-related reports from the dashboard.
What This Project Reinforced
Design the Handoff, Not Just the Screen
The useful unit of work is the whole order journey. Each screen needs to make the next responsibility and required confirmation clear.
Availability Is More than a Location
Being nearby is only one part of a match. Readiness, shifts, capacity, and the timing of the booking also belong in the decision.
Keep the Financial Record Close to the Work
Payment and earnings events belong alongside the service milestones that explain them. That context is useful to partners, support staff, and finance.
Give Operations a Way to Intervene
Automation handles the normal sequence. The people running the service still need order history, assignment controls, and the context to handle an exception.