Do we need iOS and Android, or is the web enough?

It depends on what your customers do and how often. An app they open weekly belongs on their phone, on both stores, and the same codebase runs on the web at your domain, so nobody is left out. Something they use twice a year is better on the web alone, and we will say so. Where the app runs has the full list: the web, iOS, Android, and desktop apps for macOS, Windows and Linux.

Who owns the app and the app-store listing?

You do. The App Store and Google Play listings sit in your own developer accounts, so the app is yours to move, update or hand to another developer, and the code, the accounts and the assigned intellectual property are yours from the first week.

What does an app cost to run?

About £800 a year for a version one plus the store fees above, with nothing per member and nothing routed through us. The itemised list is in the running-costs guide.

Can the app take payments?

Yes, through the payments provider you already use or the one the blueprint chooses, with the money going to your account and the receipt sent by the app. Nothing is routed through us. Member pricing, saved cards and refunds are part of the booking flow rather than a separate system, and the accounts package reads the same numbers.

Can it connect to our till or our booking system?

Yes, and directly rather than through a chain of automation steps. The app reads and writes the till, the payments provider and the accounts package through their own APIs, so a sale in the app is a sale in the till.

Can you replace our booking platform or our ordering platform?

Yes. The members, the bookings and the history are extracted, the new app runs alongside the old one on real bookings, members move across in groups with the old app still working, and every membership keeps running through the switch.

Will our members actually use it?

Only if it replaces the phone call and the platform rather than sitting next to them. Apps fail on adoption, not on features: a second login, a booking flow with one tap too many, notifications that arrive on a schedule instead of when something changed. So version one is scoped around the thing your members do most, the staff view is in version one, and the old way is retired on a date. If members route around the app, the build is wrong, and that is a design constraint rather than a marketing problem.

What moves the price of an app?

Five things, and the stores as a sixth for a phone app. All of them show up in the first conversation. User roles: members, staff, and whether each location manages its own. Integrations: payments, the till, the accounts package. Data: whether members and history have to come across from an old platform. Complexity: memberships, packs, waiting lists, the rules around each. Compliance: payment data, retention and accessibility. And the stores: an iOS or Android app carries a review and a fee that a web app does not.

Do you build with no-code app builders?

Not for a product you intend to own. They are quick to start and the pattern we see is a stall a few months in, when the app needs a real database, real sign-in or a payment flow the builder cannot express. If you already have one of those and it has stalled, the Lovable guide is written for exactly that conversation: fix it, build on it, or start again, and what you own in each case.

Service

App development. Built bespoke. Owned outright.

Bespoke app development is the design and build of the app your customers or members use to book, order, pay and check in, with the staff view behind it. Clientflow builds them for established UK businesses, on iOS, Android and the web, priced from a blueprint, with the code and the store listings in your name.

See how it works Apply for a blueprint call

A pixel-art shopfront with a striped awning, a glass door and one large window.

What is bespoke app development?

Built bespoke, an app is not a template with your logo on it. It is your product, on iOS, Android and the web from one codebase, with the staff view behind it, and the code, the store listings and the customer list are yours.

Aspect	Is	Is not
Shape	Your product, one codebase, on iOS, Android and the web	A white-label template with your logo
Access	Members sign in once; staff have their own view	A login the platform controls
Fit	Built around how your customers actually book, order or pay	Your business bent around a platform’s features
Control	Yours: the code, the listings, the customer list	A subscription priced per member or per location

The sign is a platform fee that grows with your success, or an app your customers stopped opening. Version one is scoped around the thing they do most, done properly.

What a member sees

One release, the thing your customers do most, done properly. This is what it looks like on their phone, and behind the counter.

Booking and paying in two taps, not a phone call

A member picks a class and a slot, then pays with the card they saved, at the member price. The booking lands in their calendar and on the staff view at the same moment, and the receipt sends itself.

The pass in their pocket

Membership and check-in in one place. The pass shows whether the membership is active, checks the member in at the desk, and says when it renews, so nobody is keying names into a spreadsheet.

Notifications that fire when something changes

A class moved, a booking confirmed, a receipt. Each one is sent because something happened to that member’s booking, not on a marketing schedule, so the app is never the one people mute.

The view behind the counter

Today’s classes and their capacity, who has checked in, and what needs a decision. Staff see the same records the member sees, from their side, so the desk runs from one screen.

Wired into the till, the payments and the accounts

What the app talks to

Each system keeps its own records. The app reads and writes them directly, so a sale in the app is a sale in the till.

PaymentsConnectedYour provider, through its own API.
The tillConnectedA sale in the app is a sale in the till.
AccountingConnectedXero or Sage, through its own API.
The old platformRetiredMembers imported once, then switched off.

A member app earns its place by removing double entry, so payments go through the provider you already use, sales land in the till, and the accounts package reads the same numbers. The old platform’s data is imported once, and the platform is switched off. Which systems, and in which direction, is settled in the blueprint, the written scope every build starts with, because that is what moves the price.

Where the app runs

On the web at your domain, on iOS through the App Store and on Android through Google Play, published from developer accounts in your name, and as a desktop app where the work happens at a desk. The blueprint decides which of those version one needs.

WebAny modern browser
macOSNative desktop app
WindowsNative desktop app
LinuxNative desktop app
iOSPublished on the App Store
AndroidPublished on Google Play

What we build first, and what we leave out

In version one

Sign-in for members, and one staff role with its own view.
One core thing to book, order or pay for, with its status and its history.
Payments through the provider you already use, with receipts.
Notifications that fire on a change: a booking confirmed, a class moved, an order ready.
The staff view: today’s bookings or orders, and who has checked in.
Published on the App Store and Google Play from your own developer accounts, and on the web at your domain.

Deliberately in the second phase

Memberships and renewals, once the booking flow has run for a month.
Waiting lists and class packs, once you know which classes fill.
Loyalty and offers, once you know what members actually book.
Reporting for the owner: occupancy, revenue by class, who has lapsed.
A second location, once the first runs itself.
Messaging in the app, which competes with the phone until the app is the habit.

Version one is one thing done properly, in production, used by your members and your staff. It is not a demo, not a prototype and not the finished app. Scoping it narrow is what keeps the price fixed and the date real, and everything in the second phase is cheaper to build once people have used the first.

How much does it cost to develop an app in the UK?

Clientflow builds bespoke apps from £10,000. A member app with booking, payments and a staff dashboard usually sits in our second band, £25,000 to £50,000, because it carries two kinds of user and a connection into payments and the till. A focused version one with a single flow can sit in the first band, up to £25,000. A version one then costs about £800 a year to run, plus the store fees, with nothing per member.

Builds from: £10,000
A member app, second band: £25k to £50k
To run, about: £800a year
Per member: Nothing

The store fees are $99 a year for the Apple Developer Program3 and $25 once for Google Play4, paid by you from accounts in your name. Five things move the price: user roles, integrations, data, complexity and compliance, and members and history coming across from an old platform count under data. The stores are a sixth for a phone app: a review and a fee that a web app does not carry. The bands are on the pricing page, what moves a build between them is in the cost guide, and the running costs, itemised, are in the running-costs guide.

How long does an app take to build?

A version one takes weeks rather than quarters: one to two weeks of blueprint, then three to eight of build. ONYX, the member and studio app on our work section, was scoped at six weeks to a version one. App-store review is the one date neither of us controls, and it is named as such rather than promised.

1Free
Blueprint callDay one
Twenty minutes with the people who would scope the build, to work out what version one should contain, or whether to build at all.
2Scoped
BlueprintWeeks 1 to 2
The flows, the users, the integrations and the risks written down, with a clickable prototype on a phone, so the build is agreed before it starts.
3Built
BuildWeeks 3 to 8
Designed and built, AI-assisted for speed and senior-reviewed, wired into the payments, the till and the accounts you already run.
4Owned
Launch and handoverHandover
Submitted to the stores from your accounts, the web version live at your domain, code and documentation transferred, your team trained, and a warranty after launch.

Who owns the app, the listings and the customer list?

You do, from the first week.

Yours from the first week

Arranged before the build starts, not negotiated at the end.

The codeA repository in your name from the first week.Yours
The accountsHosting and database opened in your name, in the region you choose.Yours
The listingsApp Store and Google Play, in your own developer accounts.Yours
The intellectual propertyAssigned to you under the agreement.Assigned
At handoverYou hold every account outright, including the ability to remove us.Yours

That is worth checking with every supplier you speak to, because UK copyright law does not hand it over by default. The author of a work is its first owner1, the rule that gives an employer its staff’s work does not cover a contractor, and an assignment is only effective in writing, signed by the assignor2. Paying the invoice is not what transfers the copyright, and a listing in a supplier’s developer account is not yours to move.

Moving off the platform, or the app that stopped fitting

ExtractionCan you export every member, booking and payment record today, in a format another system can load, without opening a support ticket?
2Parallel runningThe new app runs alongside the old one on real bookings, so the comparison is observed rather than argued.
3Staged cutoverMembers move across in groups, told once, with the old app still working until the new one is the habit.
4HistoryMemberships, bookings and receipts come across with their dates.

Apps get replaced for two reasons: the booking or ordering platform stopped fitting, or nobody can maintain the earlier build. Either way the work is the same shape. Extract the members, the bookings and the history, run the new app alongside the old one, move members across in groups, and keep every membership running through the switch.

Should you build an app or use a platform?

Use a platform when the way your customers book or order is genuinely standard and its fees are bearable at your volume. Build bespoke when the experience is the thing that makes your business different, when per-member or per-location pricing compounds, or when the customer list and the code need to be yours. Most businesses need one, not both.

Factor	Platform	Build
Time to go live	Days	Weeks
Up-front cost	Low	Fixed, from a blueprint
Ongoing cost	Per member or per location, forever	Usage, about £800 a year, plus the store fees
Fit to your process	You adapt	It adapts
Ownership	Licensed	Yours, listings included

The own-or-rent guide works the three-year arithmetic through for a team of twenty on rented tools; the same method applies to a platform fee that grows with your members.

When we will tell you not to build

Some calls end with us recommending a platform and sending no invoice, and we would rather that than the alternative: a build that does not pay for itself is a bad reference and a worse relationship. That is why the blueprint call is free.

Your customers would not install it. If they deal with you twice a year, a good website beats an app nobody opens, and we will say so.
A platform fits. If a booking or ordering platform does the job and its fees are bearable at your volume, the platform wins.
You want an app because a competitor has one. That is a reason to look, not a reason to build.
Or one of the three reasons that apply to any build: the process is still changing every month, nobody inside the business owns it, or the budget is under £10,000.

Questions people ask about building an app

Sources

Every citation above was read from the page cited, on the date shown.

1Copyright, Designs and Patents Act 1988, section 11, legislation.gov.uk. Seen 5 September 2026.
2Copyright, Designs and Patents Act 1988, section 90, legislation.gov.uk. Seen 5 September 2026.
3Apple Developer, Program enrolment. Seen 4 September 2026.
4Google Play Console help, registering for a developer account. Seen 4 September 2026.

Go deeper

The guides behind the numbers on this page, each with its sources and the date they were read.