Customer apps for ordering, booking and updates

Will your customers actually install it?

An app only works if it stays on the customer's phone. That depends on how often they need you, not on how good the app is. A trade customer who orders every week, a driver following a repair at your garage or a member who books classes will keep it. Someone who buys from you once a year will not, and for them a fast mobile web page with email or text updates is the better answer.

Before committing, check the basics. If what you need is bookings, a loyalty card or a simple takeaway order, an off-the-shelf booking or loyalty tool is usually cheaper. We say so on the first call. A bespoke customer app earns its place when it has to show the customer's own data from your systems: their prices, their orders, their vehicle, their job.

Native app, web portal or both

A customer portal in the browser and an app on the phone can share the same back end, so the choice is not all or nothing. A well-built web app can also be added to the home screen, and since iOS and iPadOS 16.4 such home screen web apps can receive push notifications, which covers many simple cases without going through the app stores. If browser access is the main need, see our page on client portal development.

A native app on iOS and Android is the better fit when:

• Being in the App Store and Google Play matters to how customers find and trust you.
• The camera is central: scanning barcodes, photographing damage, reading documents.
• It must work with poor signal, or keep data on the phone between visits.
• Notifications are the main channel, and you want them to be as reliable as possible.
• It uses phone features such as wallet passes, biometrics or location.

What Apple expects before it publishes your app

Apple reviews every app before it appears in the App Store. Its guidelines say an app should include "features, content, and UI that elevate it beyond a repackaged website", and that apps should not be mainly marketing material or a collection of links. Wrapping your existing website in an app shell is a common reason for rejection.

There is good news on payments. Guideline 3.1.3(e) says that when an app sells physical goods or services consumed outside the app, it must use payment methods other than in-app purchase, such as Apple Pay or card entry. Ordering parts, paying for a repair or booking an appointment therefore goes through your usual card processor rather than Apple's in-app purchase system.

Notifications and the link to your systems

The notifications customers value are the ones triggered by something real: an order dispatched, a vehicle ready, a quote waiting for approval, an appointment tomorrow. Those come from your ERP, booking system or job management software, so the app is only as good as that connection. How it is built is covered in our ERP integration services.

Let customers choose what they receive, and keep service updates separate from promotions. Marketing messages have their own consent rules, so check those with your adviser before the first campaign.

What shapes the price, and how we would build it

The guide how much it costs to build an app gives market reference figures. The factors that weigh most are the integrations with your systems, payments, the number of customer journeys in the first version, and the admin screens your team needs behind the app.

A garage network could start with booking and repair status for one branch, then add quote approval and service reminders across all sites. Customers and staff test every working demo, one every two weeks, under one fixed price per project. The method is on our page about fixed price software development.