A customer app for a cleaning company works best when it does not try to be the scheduling system.

What belongs in the back office and what belongs in the app?

The back office keeps anything a cleaner or a dispatcher relies on: the schedule itself, recurring routes, team assignments, pay, invoicing, access notes. A dedicated tool is better at this than anything you will build, and the people using it have already learned it.

The customer app holds the things a client wants and currently gets by texting you: when is my next clean, can we move it, who is coming, did it happen, here is a note about the dog. None of that needs to be rebuilt in your scheduling tool, and most of it is read-only.

If you are choosing a back office rather than keeping one, a trade-specific tool usually beats a general field service platform on price. ZenMaid starts at $19 a month for up to 40 appointments and is built for maid services rather than adapted to them, read on 8 October 2026. Our field service app page compares the general options if your work is broader than cleaning.

If you are starting from nothing rather than from an existing system, the order is worth getting right: set up the back office first and run it for a few weeks, then build the customer layer on what you have learned. Our page on building a cleaning business app covers the internal side, including what recurring routes demand that an ordinary calendar does not.

ZenMaid pricing, read 8 October 2026

What does the customer side actually need?

Less than people expect. A list of upcoming visits, the ability to request a change, a history of past cleans, and a way to leave a note for the team. That is a real product and it is four screens.

Two things are worth adding early because they remove phone calls rather than adding features. The first is a visit status that updates when the job is done, so nobody rings to ask. The second is a notes field that reaches the cleaner, because the information customers most want to pass on is small and specific: the gate code, the cat, the room to skip this week.

Resist putting payment in the first version. Taking money brings store rules, refunds and support, and most cleaning businesses already have an invoicing flow their customers accept. If you later decide the app should take payments, that is a decision with its own costs and it is better made once the rest is in use.

A useful test for any screen you are considering: does it replace a message somebody currently sends you. Upcoming visits replaces "when are you coming". History replaces "did you come on the 14th". A change request replaces a phone call during someone's working day. Screens that do not replace a message tend not to get opened.

ZenMaid, what the back office covers, read 8 October 2026

Does it need maps and live tracking?

Usually not, and the instinct to add it is where these projects grow. A cleaning visit is a scheduled appointment at a known address, not a delivery. Customers want to know roughly when, not to watch a dot move.

A time window and a status change cover almost all of it. If you do want a map, our guide on adding maps and location explains what that involves, and the honest summary is that it needs a real device to test and adds a permission prompt your customer has to accept.

The exception is same-day work where arrival times genuinely move. If that is your business, build the window first, see whether people still call, and add tracking only if they do.

There is a cheaper version of the same reassurance that costs nothing to build: send the window the evening before and the status the moment the job closes. Most of what customers want from tracking is the knowledge that they have not been forgotten, and a message at the right time delivers that without a map, a permission prompt or a device test.

What do the app stores require for an app like this?

Nothing unusual, but two rules are worth reading before you start. Apple's guideline 4.2 asks for features, content and UI beyond a repackaged website, and 4.2.2 rules out apps that are primarily a collection of links. A booking and history app clears both comfortably, because it does something on its own.

The one that catches people is accounts. Guideline 5.1.1(v) says that if your app supports account creation you must also offer account deletion within the app. A customer app for a cleaning business does need accounts, so build the deletion path in from the start rather than discovering it at review.

Guideline 4.2.6 matters too: an app made with a template or generation service is rejected unless the owner of the content submits it. So the cleaning company publishes under its own developer account, not the tool's. That is 99 USD a year for Apple, or 25 USD once for Google Play.

None of this is a reason to delay. The review itself is usually days rather than weeks for a straightforward app, and the requirements above are things you build once. What catches people out is discovering the account deletion rule after the app is finished, which is why it is worth reading guideline 5.1.1 before the first screen rather than after the last one.

Apple, App Review Guidelines, 4.2, 4.2.2, 4.2.6 and 5.1.1(v), read 8 October 2026