---
title: "Bespoke app development UK: built and owned outright"
description: "Bespoke apps for established UK businesses: booking, payments and a staff view on iOS, Android and the web. From £10,000, one fixed price from a blueprint."
canonical: https://www.clientflow.ai/app-development
verified: 2026-09-05
language: en-GB
---

# 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.

**Summary:** A bespoke app is the product your customers or members use to book, order, pay and check in, with the staff view behind it. Built bespoke, it is not a template with your logo on it: it runs on iOS, Android and the web from one codebase, reads and writes the till, the payments provider and the accounts package you already run, and the code, the listings and the customer list are yours. Clientflow builds them from £10,000, priced from a blueprint before anything is committed. Sometimes the right answer is a platform, and we will say so on the call.

## Contents

1. [What is bespoke app development?](https://www.clientflow.ai/app-development#what-it-is)
2. [Booking and paying in two taps, not a phone call](https://www.clientflow.ai/app-development#booking)
3. [The pass in their pocket](https://www.clientflow.ai/app-development#pass)
4. [Notifications that fire when something changes](https://www.clientflow.ai/app-development#notifications)
5. [The view behind the counter](https://www.clientflow.ai/app-development#staff)
6. [Wired into the till, the payments and the accounts](https://www.clientflow.ai/app-development#integration)
7. [Where the app runs](https://www.clientflow.ai/app-development#platforms)
8. [What we build first, and what we leave out](https://www.clientflow.ai/app-development#first-release)
9. [How much does it cost to develop an app in the UK?](https://www.clientflow.ai/app-development#cost)
10. [How long does an app take to build?](https://www.clientflow.ai/app-development#how-long)
11. [Who owns the app, the listings and the customer list?](https://www.clientflow.ai/app-development#ownership)
12. [Moving off the platform, or the app that stopped fitting](https://www.clientflow.ai/app-development#replacing-an-app)
13. [Should you build an app or use a platform?](https://www.clientflow.ai/app-development#build-or-buy)
14. [When we will tell you not to build](https://www.clientflow.ai/app-development#when-not-to-build)
15. [Questions people ask about building an app](https://www.clientflow.ai/app-development#questions)

## 1. 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.

## 2. 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.

## 3. 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.

## 4. 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.

## 5. 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.

## 6. Wired into the till, the payments and the accounts

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.

## 7. 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.

## 8. What we build first, and what we leave out

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.

### In version one

1. Sign-in for members, and one staff role with its own view.
2. One core thing to book, order or pay for, with its status and its history.
3. Payments through the provider you already use, with receipts.
4. Notifications that fire on a change: a booking confirmed, a class moved, an order ready.
5. The staff view: today’s bookings or orders, and who has checked in.
6. 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

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

## 9. 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.

The store fees are $99 a year for the Apple Developer Program[^3] and $25 once for Google Play[^4], 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](https://www.clientflow.ai/pricing#bands), what moves a build between them is in the [cost guide](https://www.clientflow.ai/guides/bespoke-software-development-cost-uk), and the running costs, itemised, are in the [running-costs guide](https://www.clientflow.ai/guides/running-costs).

## 10. 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](https://www.clientflow.ai/#work), 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.

1. **Blueprint call** · Free · Day 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.

2. **Blueprint** · Scoped · Weeks 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.

3. **Build** · Built · Weeks 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.

4. **Launch and handover** · Owned · Handover

   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.


## 11. Who owns the app, the listings and the customer list?

You do, from the first week.

- **The code**: A repository in your name from the first week.
- **The accounts**: Hosting and database opened in your name, in the region you choose.
- **The listings**: App Store and Google Play, in your own developer accounts.
- **The intellectual property**: Assigned to you under the agreement.
- **At handover**: You hold every account outright, including the ability to remove us.

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 owner[^1], 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 assignor[^2]. Paying the invoice is not what transfers the copyright, and a listing in a supplier’s developer account is not yours to move.

## 12. Moving off the platform, or the app that stopped fitting

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.

- **Extraction**: Can you export every member, booking and payment record today, in a format another system can load, without opening a support ticket? With a platform it is the first thing to check, and sometimes it is the finding.
- **Parallel running**: The new app runs alongside the old one on real bookings, so the comparison is observed rather than argued.
- **Staged cutover**: Members move across in groups, told once, with the old app still working until the new one is the habit. The rollback is always one group wide.
- **History**: Memberships, bookings and receipts come across with their dates. A migration that resets a member’s history creates a problem you did not have.

## 13. 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](https://www.clientflow.ai/guides/build-or-buy-software-uk) 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.

## 14. 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.

1. 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.
2. A platform fits. If a booking or ordering platform does the job and its fees are bearable at your volume, the platform wins.
3. You want an app because a competitor has one. That is a reason to look, not a reason to build.
4. 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.

## 15. Questions people ask about building an app

### 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](#platforms) 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](https://www.clientflow.ai/guides/running-costs).

### 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](https://www.clientflow.ai/guides/stuck-with-a-lovable-build) is written for exactly that conversation: fix it, build on it, or start again, and what you own in each case.

## Sources

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

[^1]: [Copyright, Designs and Patents Act 1988, section 11, legislation.gov.uk](https://www.legislation.gov.uk/ukpga/1988/48/section/11). Seen 5 September 2026.
[^2]: [Copyright, Designs and Patents Act 1988, section 90, legislation.gov.uk](https://www.legislation.gov.uk/ukpga/1988/48/section/90). Seen 5 September 2026.
[^3]: [Apple Developer, Program enrolment](https://developer.apple.com/support/purchase-activation/). 99 US dollars a year, charged in local currency. Seen 4 September 2026.
[^4]: [Google Play Console help, registering for a developer account](https://support.google.com/googleplay/android-developer/answer/6112435). A one-time $25 registration fee. Seen 4 September 2026.

## Go deeper

- [What bespoke software actually costs in the UK](https://www.clientflow.ai/guides/bespoke-software-development-cost-uk): The bands, the five things that move the price, and when not to build. Markdown: https://www.clientflow.ai/guides/bespoke-software-development-cost-uk.md
- [What the software you own actually costs to run](https://www.clientflow.ai/guides/running-costs): About £800 a year at list prices, nothing per seat, and where the 15 to 25% rule came from. Markdown: https://www.clientflow.ai/guides/running-costs.md