Laundry Heroes
A bilingual on-demand laundry ecosystem for Saudi Arabia: one customer app, one admin dashboard that runs and manages it, and one website — connected by the same Laravel backend, brand, ordering, payment, and live-tracking flow.
- Role
- Technical lead · DevSparks team delivery
- Services
- Flutter app (iOS + Android) · Brand-led UI/UX design · Laravel + MySQL backend API · Admin dashboard managing the app (React 19) · Marketing website (Next.js) · Moyasar payments & Authentica Messaging · Segment + Mixpanel analytics · Google Maps & push notifications · Mobile release preparation
- Stack
- Flutter · Laravel · MySQL · React 19 · Next.js 16 · Redux Toolkit · Moyasar · Authentica · Segment · Mixpanel · Firebase FCM · Google Maps API
- Client
- Laundry Heroes
- Industry
- On-demand Services
- Timeline
- 16 weeks · 2025
01 / Business context
The Problem to Solve
Laundry Heroes was coordinating customer orders through phone calls and WhatsApp, without one connected flow for pricing, tracking, and operational visibility. The product needed to bring the customer experience and the team’s daily work into one bilingual system for Saudi Arabia.
Laundry Heroes is an on-demand laundry ecosystem for Saudi Arabia, covering clothes, carpet, and duvet care with pickup and delivery. The project connected a bilingual consumer app, an admin dashboard, and a brand website through one Laravel API, one MySQL database, and one shared identity, so the customer journey and the team’s daily workflow could be planned as one product. The dashboard is where the app is actually run: the team manages the services, pricing, offers, drivers, orders, and customer accounts that the app presents, without waiting on a developer or a store release.
02 / From Scope to Launch
How the Work Moved
The work became clearer through decisions, working increments, and feedback—not a long wait for a final reveal.
07 Steps
Step 01
We began with discovery and service mapping, tracing the full laundry journey from order to pickup, wash, and delivery for both customers and staff, and defined three products that share one backend and one brand.
Step 02
We designed a playful superhero identity in pink and cyan, built Arabic-first with full RTL flows, so the product stands out in a category of plain utility apps.
Step 03
We modelled orders, pricing, drivers, and invoices in MySQL and exposed them through a single Laravel API, then layered the external services the operation depends on: Moyasar for payments, Authentica for OTP and order messaging, and Firebase for push notifications.
Step 04
We scoped the dashboard as the control surface for the app itself, not a reporting screen beside it: the service catalogue, per-item pricing, coverage areas, offers, drivers, order states, and customer accounts that the app renders are all administered from there.
Step 05
We built all three surfaces in parallel against that API: the Flutter app with the one-tap order flow and live tracking, the React admin dashboard with maps, analytics, and invoicing, and the bilingual Next.js site.
Step 06
We instrumented the customer funnel through Segment into Mixpanel, so ordering behaviour from the app, dashboard, and website reports into one place instead of three separate views.
Step 07
We prepared the mobile release, onboarded the operations team onto the dashboard, and tuned the flows using early orders in Saudi Arabia.
03 / Decisions that shaped the product
Key Product Decisions
One Flutter codebase for iOS and Android
- Business context
- The consumer experience needed to support iOS and Android while the app, dashboard, and website were developed in parallel within a 16-week engagement.
- Decision
- We built a single Flutter codebase targeting iOS and Android, with full Arabic RTL and English support.
- Why
- One shared mobile codebase kept the two platform experiences aligned while the dashboard, website, and backend were being built in parallel.
Arabic-first design rather than a translation pass
- Business context
- A bilingual app for the Saudi market can either be designed English-first and translated later, or designed around Arabic from the start.
- Decision
- We designed the app Arabic-first with full RTL flows, shipping Arabic and English together.
- Why
- For customers in Saudi Arabia seeing per-item SAR pricing and step-by-step order tracking, RTL had to be native to the layouts rather than retrofitted after the fact.
Three surfaces on one shared backend and brand
- Business context
- The consumer app, ops dashboard, and marketing site could each have been scoped and built as separate systems.
- Decision
- We defined three products sharing one Laravel API over MySQL and one hero brand system, and built them in parallel.
- Why
- A relational system of record keeps orders, drivers, pricing, and invoices consistent between the app and the control room, and one API surface means a pricing or status rule is written once rather than re-implemented per client.
The dashboard as the app's admin panel, not a report viewer
- Business context
- A laundry service changes constantly — prices per item, new services, coverage areas, offers, drivers joining and leaving. If those live in code or in the database only, every ordinary business change becomes a developer ticket and, for anything the app renders, a new store release.
- Decision
- We built the React dashboard as the administration surface for the mobile app itself, with the service catalogue, per-item SAR pricing, offers, coverage areas, drivers, order states, customer accounts, notifications, and role-based staff access all managed from it through the same Laravel API the app consumes.
- Why
- The team owns the day-to-day product without us in the loop: a price change, a new service, or a paused coverage area takes effect in the customer app immediately, and the operations staff work in one place instead of splitting between a control room and a support channel.
Moyasar for payments rather than a global-first gateway
- Business context
- Customers in Saudi Arabia expect mada and Apple Pay at checkout, and the operation needed settlement and refunds handled inside the same order record.
- Decision
- We integrated Moyasar as the payment gateway, with the Laravel API owning payment state and reconciling it to the order through webhooks.
- Why
- A locally established gateway covers the payment methods this market actually uses, and keeping payment state on the backend means a refund or a failed charge is visible in the dashboard next to the order it belongs to.
One tracking layer instead of per-surface analytics
- Business context
- The app, dashboard, and marketing site could each have been wired directly to their own analytics tool, leaving three definitions of the same funnel.
- Decision
- We sent events through Segment as a single tracking layer and used Mixpanel as the product analytics destination, alongside Authentica for OTP and order messaging.
- Why
- One event schema across the three surfaces keeps the ordering funnel comparable, and routing through Segment means adding or replacing a downstream tool later is a configuration change rather than a re-instrumentation project.
04 / The product in use
What Was Built
Real interfaces across the customer and operational experience.
05 / How it was built
Engineering Decisions
Flutter consumer app from a single codebase for iOS and Android, with full Arabic RTL and a one-tap order flow covering wash, iron, and dry-clean services for clothes, carpets, and duvets.
Live step-by-step order tracking from pickup to delivery on a live map, replacing 'where is my laundry?' phone calls.
React 19 admin dashboard that manages the mobile app end to end: service catalogue and per-item SAR pricing, offers, coverage areas, customer accounts, driver records and assignment, order states, and push notification sends — all through the same Laravel API the app consumes, so a change is live in the app without a new release.
Daily operations in the same dashboard: a drag-and-drop order board, driver tracking on Google Maps, ApexCharts analytics, one-click PDF invoicing, and role-based access separating admin from operations staff.
Bilingual Next.js marketing site carrying the pink-and-cyan hero brand to the web.
Laravel API over MySQL as the shared system of record for orders, services and per-item pricing, drivers, and invoices, consumed by all three surfaces and built in parallel during a 16-week engagement.
Moyasar payments integrated through the Laravel API, with webhook handling so payment, refund, and settlement state stays attached to the order it belongs to.
Authentica for phone-number OTP sign-in and order-status SMS, with Firebase Cloud Messaging carrying in-app push for pickup and delivery updates.
Segment as one client-side and server-side tracking layer across app, dashboard, and website, with Mixpanel as the product analytics destination for the ordering funnel.
06 / What changed
Delivered Outcome
The consumer app shipped to both the App Store and Google Play from one codebase, holds a 4.9/5 App Store rating, and opens on a one-tap order flow.
Three connected surfaces shipped in 16 weeks: the consumer app, admin dashboard, and marketing website, in Arabic and English.
The delivered dashboard gives the Laundry Heroes team one place to manage the app itself — services, per-item pricing, offers, coverage, customers, drivers, orders, and payment state.
Routine business changes such as a new service or a price update reach customers from the dashboard, without a development cycle or an app store release.
In-app payment through Moyasar replaced settling each order by cash or transfer at the door.
Customer ordering, payment, and operational management now sit inside one shared product ecosystem instead of separate channels.
“One team delivered our app on both stores, the dashboard we run the laundry from, and the website — same brand, same quality, everywhere.”
Facing a similar product challenge?
Bring the problem, the current state, and the outcome you need. We can turn that context into a clear product direction and a workable path to launch.