Cleaning services business — from paper schedule to mobile-app dispatch

The business worked. It just didn't scale.

Bookings landed in three different WhatsApp groups. The day's schedule lived on a sheet of paper taped to the office wall. A shared spreadsheet tried to track who had recurring jobs and which cleaner was assigned, but it drifted out of sync within an hour of any change.

The visible symptoms were the usual ones for a services business that outgrew its tools. Two cleaners sent to the same address. Recurring customers forgotten when a dispatcher took the day off. Reviews never collected because nobody followed up. Payments chased over text messages a week after the job. Customers calling the office to find out when their cleaner would arrive, because there was no other way to know.

The owners had tried off-the-shelf field-service software twice. Both attempts died because the products were generic and the team wouldn't adopt them. The brief to us was specific: build the system this business actually needs, in the shape this business actually works, and make it boring to use.

We shipped native iOS and Android customer apps, a web admin for the back-office, and a shared backend that owns the domain.

The customer app is the front door. Clients book a one-off or a recurring cleaning, pick the property, pick the slot, and pay. They see arrival time as it firms up, message their cleaner inside the app, rate the service after, and manage saved payment methods and addresses. Recurring bookings are a first-class object, not a flag on a one-off — that distinction drove the rest of the data model.

The web admin is where dispatchers and managers spend the day. A bookings calendar, a staff roster, route assignment, customer history, and the financial reports the owners actually open on Monday morning. We built it as the cleaner-friendly replacement for the wall schedule, not a tour of every database table.

The backend owns the database. The scheduling engine handles recurring rules, holiday skips, cleaner availability, and conflict detection. Push notifications go out for both platforms, fronted by background workers so the web requests stay snappy. Payments and invoicing run through a payment provider — card on file, deposits where the business needs them, refunds with an audit trail.

The cleaner-side interface lives inside the same mobile app, gated by role. A cleaner opens the app and sees today's jobs in order, with address, access notes, and a check-off for completed work. No second app to install, no separate login flow, no parallel codebase to maintain. That decision saved roughly a month of work and removed an entire surface area of bugs.

Everything is in one application with one database. We picked that over a microservice split because the team is one engineering group and the domain is one business. A split would have bought nothing and cost the owners a runbook.

• Bookings are taken in the app. The office phone stopped being the booking channel.
• The paper schedule came off the wall. Dispatch runs from the admin calendar.
• Recurring customers are now a tracked object, not a memory. Skips and holidays are handled.
• Cleaners check in and complete work from their phones. Managers see status in real time.
• Reviews close the loop automatically after each completed job, instead of never.
• Payments are charged on completion. Chasing customers over text messages stopped.
• The owners get weekly numbers from the admin instead of from a spreadsheet they had to rebuild.

What we cut

We didn't build a third-party marketplace integration. The business doesn't sell through aggregators and adding one would have meant a second authentication model and a second payout reconciliation flow for no current return.

We didn't ship full in-app chat with thread history, attachments, and presence. Customers and cleaners exchange short coordination messages tied to a booking; that's it. A real messaging product is a different product.

We didn't build a route optimiser. The dispatcher knows the city better than any solver we'd ship in four months. The admin shows distance and travel time between stops and lets the human make the call. We left a clean seam to add optimisation later if the volume justifies it.

We didn't build a loyalty programme, a referral engine, or a marketing CRM. Those are real features. They're not this engagement.

Every cut is documented. The owners know what isn't there and why.

Hand-over

The client owns everything.

The Apple developer account and the Google Play developer account are in the client's name. The code is in the client's repositories. The database, the application, the web admin, and the background workers run on the client's infrastructure under the client's billing. The payment provider account is the client's; we never touched their money.

We wrote the runbooks the on-call needs: how to roll back a release, how to rotate the push notification certificates before they expire, how to restore from a backup, how to handle a stuck background job, how to push a new build to the App Store and Play Store test tracks. We left a short list of known sharp edges so the next engineer doesn't trip on them.

End-of-sprint demos every two weeks gave the owners eyes on the build the whole way through. By hand-over there were no surprises. They've been running the business on the system since, and they don't need us in the loop to do it.