App for a dental clinic in the UK: costs and compliance

Most practice owners who come to us have already been sold something. A patient portal bolted onto their practice management software, a booking widget that does not talk to the diary, an SMS reminder service billed per message. None of it feels like the app they had in mind, and none of it has moved the number they actually care about, which is how many booked chairs go empty each week. An app for a dental clinic in the UK costs roughly £15,000 to £70,000 depending on how much of the practice it touches, and the money is the easy part to understand. The harder questions are what happens to patient data, whether the thing integrates with the system your reception team already lives in, and whether the recovered appointments cover the invoice. This guide works through all three.

What does an app for a dental clinic in the UK cost?

A patient app for a single UK dental practice typically costs £15,000 to £30,000 for a focused first version covering booking, reminders, and patient records, and £40,000 to £70,000 once you add treatment plans, payments, plan membership, and integration with your practice management software. Budget separately for running costs of a few hundred pounds a month and for annual maintenance.

Those are our own ranges from building this kind of product, and they assume custom work rather than a rebranded template. They sit inside the wider picture we set out in how much an app costs to build in the UK in 2026. The pattern holds across every sector we work in: price tracks the number of distinct jobs the software has to do, not the number of screens it has. An app for a dental clinic in the UK tends to cost more than a comparable retail app for one reason, which is that it handles health data and therefore carries obligations a shopping app does not.

Here is how the range breaks down.

Running costs are smaller and permanent. Hosting and back-end services for a single-practice app usually land between £80 and £300 a month depending on patient volume and how much you store. The Apple Developer Program and Google Play developer account are annual and per-company rather than per-app, and both publish current fees on their own pages. Notification volume is billed per message by most providers, which matters more for a recall-heavy practice than people expect, and we broke down that arithmetic in what it costs to add push notifications. If you take deposits or plan payments in the app, card processing is a percentage plus a fixed fee per transaction, and the current rates live on the provider’s own pricing page rather than in a blog post, because they change.

Then there is maintenance, the line every practice forgets. iOS and Android each ship a major release every year. An app nobody updates starts breaking within about eighteen months, and a broken booking flow in a clinic is not a cosmetic problem, it is a phone line that rings all morning.

What a dental practice app actually does

Strip the brochure language away and a clinic app does five jobs. Knowing which of the five you genuinely need is the difference between a £20,000 build and a £60,000 one.

It fills the diary without a phone call. Patients book, reschedule, and cancel themselves, at eleven at night when they remember they are overdue. This is the whole commercial argument, because a cancellation that arrives four days early gets refilled and a no-show does not.

It runs recall properly. Dentistry is a recall business. Six month check-ups, hygienist intervals, orthodontic reviews, implant maintenance. A practice that chases recall by hand chases it inconsistently. An app that knows each patient’s interval and messages them automatically is doing the single highest value thing software can do for a practice.

It collects the paperwork before the patient arrives. Medical history, consent, GDPR preferences, updated contact details. Filled in at home on a phone rather than on a clipboard in the waiting room, and landing in the record already typed rather than needing a nurse to transcribe it.

It shows the patient their treatment plan. Private treatment is a considered purchase, often into the thousands of pounds. Patients who can reread the plan, see the staged costs, and share it with a partner at home convert better than patients who heard it once in a chair while numb.

It takes money. Deposits on high value appointments, plan membership by direct debit, balance payments. A deposit is the most reliable no-show reducer in the industry, and it only works if paying is trivially easy.

If your honest answer is that you need the first two and nothing else, say so early and build only those. The most expensive practice apps we have seen were expensive because nobody was willing to cut anything.

Patient data is the part that changes the build

This is where a dental app stops resembling a retail one. Dental records are health data, which UK data protection law treats as a special category with tighter conditions than an email address or a delivery postcode. That has practical consequences for the software, not just for your policy documents.

In practice it means the build has to account for a handful of things from day one rather than as a retrofit. Data has to be encrypted in transit and at rest. Access has to be role based, so a receptionist and an associate dentist see different things, and every access to a record has to be logged. Retention has to be deliberate, because clinical records have a defined lifecycle and an app that quietly keeps everything forever is a liability. Patients need a working route to see what you hold and to ask for it to be corrected or erased where erasure applies. And if any part of your stack sits outside the UK, the transfer needs a lawful basis rather than a shrug.

None of that is exotic engineering. It is roughly ten to fifteen per cent on top of a comparable non-clinical build, and it is far cheaper to design in than to bolt on after an incident. The Information Commissioner’s Office publishes the current UK guidance on special category data and on health sector processing, and it is worth your practice manager reading the relevant pages directly rather than trusting a vendor’s summary of them. We covered the general principles for consumer products in GDPR for a UK consumer app, and the clinical version is the same skeleton with stricter muscles.

Two further points that catch practices out.

If you deliver NHS care, procurement asks more of you. NHS England maintains the Digital Technology Assessment Criteria, a baseline that digital tools are assessed against for clinical safety, data protection, technical security, interoperability, and usability. Whether it applies to your specific app depends on how it is used and who is commissioning it, so check before you scope rather than after. If you are wholly private, this is usually not your problem, but knowing that early changes the budget conversation.

Your indemnity and your registration still apply to software. If the app influences clinical decisions, gathers medical histories, or triages symptoms, it is part of your clinical process and should be treated as such in your governance. Anything that starts giving patients advice rather than information is a different regulatory conversation entirely, and one to have with your defence organisation before a developer writes a line of code.

The integration question decides whether any of it works

Every practice already runs practice management software. The diary, the charting, the recalls, the accounts. If your new app does not talk to it, you have not bought an app, you have bought a second diary and a permanent reconciliation job for your reception team.

There are three realistic integration positions, and they cost very different amounts.

A published API. Some practice management vendors offer documented integration, sometimes on a partner tier with a fee. This is the good case. Booking availability, patient records, and appointment writes flow both ways, and the build cost sits at the lower end of the ranges above.

A partial or restricted API. Read access but not write, or booking but not clinical data. Workable, but it constrains what the app can do and usually means some flow stays manual. Scope honestly around what the API genuinely supports, and get the vendor to confirm it in writing before you commission anything.

No integration path at all. Some systems simply do not open up, or open up only through a reseller arrangement. In that case your options are a separate patient-facing layer that syncs on a schedule, a data export and import routine that someone has to run, or changing practice management software. All three are real decisions with real costs, and the third is a bigger project than the app.

Ask this question first, before design, before quotes. We put it near the top of our app project scoping checklist for exactly this reason. A quote produced without an answer to it is a guess.

The payback maths, on your own numbers

Do not take an industry average from a vendor deck. Use your own figures, because practices vary enormously and the answer is usually obvious once you write it down.

Take a practice with a £45,000 build and these numbers.

• Failed and short-notice cancelled appointments: 25 a week.
• Average value of a lost appointment slot: £60 for a check-up, considerably more for private treatment. Use your own blended figure, and say £70.
• Weekly value currently walking out of the door: 25 multiplied by £70, which is £1,750.
• If the app recovers a quarter of those slots through self-service rescheduling, deposits, and automated reminders, that is £437 a week, or roughly £22,700 a year.
• Payback on a £45,000 build: about two years, before you count anything else the app does.

Now add the second effect, which is usually larger and almost always ignored. Reception time. If automated booking, recall, and pre-visit forms remove ten hours a week of phone and admin work across the team, that is most of a part-time salary you either save or redeploy into treatment coordination, which generates revenue rather than absorbing it. Put your own hourly cost in and the payback period typically drops below eighteen months.

Then the third effect, hardest to model and often the biggest. Private treatment conversion. If the app makes treatment plans reviewable at home and payment easy, and it moves conversion on a £2,500 plan by even a couple of percentage points across a year, the numbers stop being close.

Run it with your figures. If two of the three effects do not clear the invoice, the honest answer is that you are not ready, and no developer worth hiring will tell you otherwise.

When an app is the wrong spend for a practice

We turn work down for these reasons regularly, so they are worth saying plainly. An app for a dental clinic in the UK is a good investment under specific conditions, and the conditions below are the ones that make it a bad one.

Your practice management vendor already ships a decent patient app and you have not tried it. Turn it on, use it for three months, and find out what it cannot do. Then commission the gap, not the whole thing.

You have one site, a full diary, and a waiting list. An app that fills appointments is worth little to a practice that cannot fit anyone else in. Spend on capacity or on pricing instead.

The real problem is your front desk process. Software makes a good process faster and a bad process faster at breaking. If recall is unreliable because nobody owns it, an app will not create an owner.

You want it because a competitor has one. That is the reason we hear most often and the one that predicts abandoned projects best. A patient chooses a dentist on trust, convenience, and price. An app helps with the middle one and only if it works.

Your budget is £8,000. Be direct with yourself. At that level you are buying a template or a subscription product, and there are perfectly reasonable ones. Buying a quarter of a custom build gets you a quarter of a custom build, which is nothing.

What to do next

If you are commissioning an app for a dental clinic in the UK, work in this order and you will spend a lot less.

First, get the integration answer from your practice management vendor in writing. What is exposed, on what terms, at what cost. Everything downstream depends on it.

Second, write down your own no-show rate, your own blended slot value, and your own reception admin hours. An afternoon with the diary and a spreadsheet will tell you more than any vendor demonstration.

Third, decide which two of the five jobs above matter most this year, and scope only those. Booking and recall is the usual answer, and it is the right one more often than practices expect. Treatment plans and payments can follow once the first version has proved itself with your patients.

Fourth, brief it properly. A vague brief produces quotes that cannot be compared, and we wrote how to write a brief for a UK app developer precisely because most of them arrive missing the things that determine price.

If you have those four things and want a second opinion on the numbers before you commit, send us a project brief. We will tell you if we think an app is the wrong spend for your practice, which is advice we give more often than the alternative. If you are weighing a similar decision in a different sector, the same arithmetic runs through mobile apps for restaurants in the UK, where the payback question is structured almost identically and the conclusions are not.