How to Develop a Mobile App for Self-Service Laundry?
Coins and queues at the terminal — the main pain point for self-service laundry owners. The customer spends 5 minutes looking for change, another 2 choosing a program through a murky screen. With the app: scan the QR on the machine, choose a program, pay, get notified when ready. For the network owner — remote machine monitoring, load statistics, dynamic pricing without visiting the location. We have been developing mobile apps for self-service laundry for over 5 years — tested on 12+ networks, processed over 1 million wash cycles, and connected over 800 machines. The average cost per wash cycle is around $3–4, and the app pays for itself in 6–8 months by increasing machine load by 25%.
MQTT is the key protocol for communication with machines. It provides latency under 100 ms, 10 times faster than HTTP polling. Architecture: IoT module ↔ MQTT broker ↔ backend ↔ mobile app via WebSocket.
How MQTT Ensures Communication with Machines?
Washing machines in self-service are controlled via an IoT module, built-in or installed parallel: ESP32 or Raspberry Pi with GSM/Wi-Fi. The module connects to the machine's control board via relays (button emulation) or via UART/RS485 if the machine has a service interface. Most commercial machine manufacturers (Electrolux Professional, Miele Professional, Speed Queen) provide an API or at least a service protocol description — you need to request directly from the vendor. Cheap machines without a protocol are controlled via relays: the module sees a "cycle started" signal from a current sensor (SCT-013) and sends the state to the server.
MQTT with a broker (Mosquitto/HiveMQ) ensures a persistent connection without HTTP overhead. Each machine publishes its status to the topic laundry/{id}/status — the app subscribes and receives updates instantly. Connection loss is compensated by Last Will Testament. Protocol comparison:
| Protocol | Latency | Server Load | Module Power Consumption |
|---|---|---|---|
| MQTT | <100 ms | Low | Low |
| HTTP polling | 1-30 s | High | High |
| WebSocket | <50 ms | Medium | Medium |
// Android: subscribing to machine status via MQTT class LaundryMachineMonitor(private val machineId: String) { private val mqttClient: MqttAndroidClient = /* initialization */ fun subscribeToMachine(onUpdate: (MachineStatus) -> Unit) { mqttClient.subscribe("laundry/$machineId/status", 1) { _, message -> val json = String(message.payload) val status = Json.decodeFromString<MachineStatus>(json) onUpdate(status) } } fun startCycle(program: WashProgram, token: String) { val command = Json.encodeToString(StartCycleCommand(program, token)) mqttClient.publish("laundry/$machineId/command", command.toByteArray(), 1, false) } } @Serializable data class MachineStatus( val state: MachineState, // IDLE, RUNNING, DONE, ERROR val programName: String?, val remainingSeconds: Int?, val errorCode: String? ) How to Bypass App Store Commission When Paying for Laundry?
Key issue: Apple considers topping up an in-app wallet a "digital good" and requires IAP with a 30% commission. But if the wallet is used to pay for physical services (laundry is a physical service), you can use external acquiring directly. Scheme: top up balance → redirect to Safari/SafariViewController with a web payment page (YooKassa, Stripe, CloudPayments). Payment for a specific cycle — deduction from balance via API. Apple Guidelines 3.1.5(b) allows this for "real goods and services." On Android with Google Pay it's easier: PaymentsClient with a card or integration in WebView. Savings on commission — up to 30% per transaction.
Why Should Booking Be Paid?
The user wants to know if a machine is free before going to the laundromat. A map of locations with real-time machine availability indicators is the main function of the home screen. Filtering: "only with free machines," "with dryers."
Booking a machine for 10–15 minutes is a controversial function. Without booking: you arrive and all are occupied. With booking: many abandoned reservations. Compromise: paid booking (1 conditional unit deducted), credited toward the cycle. Our experience: implementing paid booking reduced empty reservations by 70%.
Push notification 5 minutes before cycle end and upon completion — via FCM/APNs. On the server side: a worker checks the remaining time based on machine data, schedules a push via FCM Schedule (Android) or APNs with apns-expiration.
Accumulating loyalty points per wash cycle — a simple retention mechanic. Every Nth cycle free. Implementation on the server, mobile app shows progress via API.
What's Included in the Project
- API documentation for IoT module and mobile app integration.
- Mobile app source code (iOS/Android) in Swift 5.9+ / Kotlin with Jetpack Compose.
- Server module in Node.js or Python with MQTT broker.
- Integration guide for any machines: API, UART/RS485, relays.
- Staff training on managing the network via CMS.
- Technical support for 3 months after release.
Process Workflow
| Stage | Duration | What We Do |
|---|---|---|
| Analytics | 1-2 weeks | Study machine fleet, choose protocol, audit current business processes |
| Design | 2-3 weeks | UX design (map, booking, payment), IoT network architecture |
| Development | 4-8 weeks | Module firmware, mobile code, server, admin panel |
| Testing | 2-3 weeks | Integration testing with real machines, MQTT load testing |
| Deployment | 1-2 weeks | Install modules in laundries, publish to App Store / Google Play |
Checklist for Machine Integration
- Determine connection type: does the machine have a service API or only relays?
- For API: request documentation from the manufacturer, check MQTT support.
- For relays: select current sensor SCT-013 and ESP32 module with Wi-Fi.
- Set up MQTT broker (Mosquitto) on the server.
- Test start and stop cycle commands manually.
- Integrate payment gateway (Stripe, YooKassa) for balance top-up.
- Set up push notifications via FCM/APNs.
- Test booking: set a timer for 10-15 minutes with fund hold.
Indicative Timelines
- MVP (one laundry, basic functionality): 6–8 weeks.
- Full solution with map of locations, loyalty program, and CMS: 4–5 months.
Cost is calculated individually — depends on the number of machines, integration complexity, and need for App Store approval. Our team's experience (10+ years in mobile development, Apple and Google certifications) reduces risks and timelines. Order development today and get a presentation with examples of completed projects. Contact us for a consultation — we will evaluate your project for free.