Customers want to book from their phone. Do you need an app for that?
Sometimes. If customers book a few times a year, a booking page that works properly on a phone does it for less. It also reaches everyone who searches, not only the people who installed something.
When an app is the answer, we design and build it for UK businesses on iOS and Android, from one React Native or Flutter codebase. Where the app earns it, we build in native Swift and Kotlin instead. Then we take it through Apple's and Google's review to launch.
Sound familiar?
Three situations where an app can look like the answer, and not all of them need one.
The patients who ask to book on their phone. Someone at the practice suggests an app. But if patients come in twice a year, an app they would open twice a year has little reason to stay on their phone. What they are asking for may be a booking page and a reminder text.
The customers who come back every week. A gym's class timetable, a café's loyalty stamps, the same order from the same shop. A saved account, loyalty and order history are what make an app worth opening again.
The team that works out of a van. Job sheets are filled in on paper, photographed and sent on WhatsApp, and someone in the office types them up again. The job needs the camera, the location and a form that still works where there is no signal.
How it works
- We test the idea before we price it. A 30-minute call, then within three working days a written scope — or, where we are plainly the wrong firm, a referral. The scope names the framework, with the reasoning behind it, and a target launch date.
- The data questions are settled in design. We decide which permissions the app asks for and when, what it collects, and whether anything tracks before consent, while the screens are designed for one-handed use. Both stores make you declare what the app does with data, so this cannot wait until the listing is written.
- It connects to what you already run. The app connects to your booking diary or CRM. If your system cannot be connected to, we say so and scope a different route rather than promise a connection that does not exist.
- You approve it on a phone, not in a meeting. Builds go onto your phone, used where the app will be — in the van, at the counter, between appointments. Sign-off is weeks of ordinary use, not a demo at the end of the build.
- We take it through store review. We write the listings, complete the privacy declarations, answer review feedback and resubmit until the app is live, then fix what launch turns up for 30 days.
What the starting price buys
A first version live on both stores, built around one core flow: the thing people would do on the app in a normal week. In a booking app that is booking a class or an appointment; elsewhere it may be reordering or logging a job. It is a production app, not a prototype — and not every feature you can imagine in version one.
Add when you need it: real offline use · push notifications · more screens and flows · more systems connected · a new back-end built for the app · fully native Swift and Kotlin builds · version-two features after launch. App Store Optimisation and paid-install campaigns are not part of the service.
Native, cross-platform, or no app at all?
The framework question matters least. The route is what costs money, and there are more than two.
| Route | Right when | Where it starts |
|---|---|---|
| No app: a booking page with confirmation and reminder texts | Customers book from their phone a few times a year | A booking calendar with texts, set up under CRM |
| A web app that installs to the home screen | People sign in to a portal, a dashboard or a quoting tool; it runs everywhere and changes need no store approval | From £4,500 excl. VAT for a focused tool, multi-user platforms with several integrations from £9,500 excl. VAT, on Web Applications |
| A cross-platform store app (React Native or Flutter) | At least two of these are true: people open it every week; it needs the camera, background location or real offline use; people are signed in; notifications are the mechanic, not the wish, such as a delivery that is out or a shift that is available; your own staff run their working day on it | From £12,000 excl. VAT |
| A native app (Swift for iOS, Kotlin for Android) | The app does something performance-critical or deeply platform-specific | Priced in the scope |
One codebase means the engineering is not paid for twice. What still doubles sits after the code: two sets of listings and declarations, two review queues, and two operating-system release calendars to keep up with.
What keeps you safe
The app is yours. The Apple and Google developer accounts are registered in your name from the start. An app published under someone else's account cannot be updated or moved without them.
Your customers' data has the same UK GDPR protection as on your website. Nothing tracks anyone before they consent, to the ICO's standard for websites, and each store's privacy declaration must match what the app does or the app is rejected.
Any review prompt carries no reward. If the app asks for reviews, it asks everyone, with nothing attached. Since 6 April 2025 it has been a banned practice in the UK to conceal incentivised reviews, so "five stars for 10% off" is an enforcement risk.
For aesthetic clinics, the store listing, an in-app treatment menu and notification wording sit under the same advertising rules as the website.
What it costs
From £12,000 excl. VAT for the first version on both stores. More screens, offline use, notifications, connected systems, a new back-end and native builds raise it. A Maintenance care plan from £250 a month excl. VAT then keeps it current with Apple's and Google's releases; the tier follows how much you depend on the app. For comparison, a website starts at £3,500 excl. VAT. Every service is on the pricing page.
When something else fits better
If the job is to be found — enquiries and bookings from search — an app is invisible to it. Nobody discovers a plumber, a clinic or a letting agent by browsing a store; what you want is a website that opens properly on a phone, and SEO. If what you have described is a logged-in area, a web app runs on every phone and changes without waiting for review. A dental practice whose patients visit a few times a year may do better with a booking-first website and automated recall. Still deciding? Start with the free audit of the site you already have. If your mobile website is what costs you enquiries, that is a cheaper problem, and the one to fix first.
None of this is legal advice. Get in touch with what people would do on the app in a normal week, or read how a project runs first.