Scenario · Health, wellness & education

Building a booking app for a physio clinic: what to build, what to buy, and what it cost

Clinic booking app development, honestly: a Melbourne physio clinic kept its practice software, built only what it lacked, and here is the cost of each piece.

By Akash Bansal, founding engineerUpdated 4 November 20267 min read

Illustrative scenario. The founder in this story is a composite, not a real client. The process, costs and decisions are drawn from builds I have done; names and business details are invented to show how a build like this typically goes.

The most useful thing I can tell most clinic owners who ask about "clinic booking app development" is this: don't build the appointment booker. It is a solved problem, sold by the month. What is often worth building is the part of the business that practice software was never designed for.

This is the story of how that decision usually goes, told through a composite founder. My evidence is a real build: for Breathe n' Being, a yoga and meditation studio, I built the public site, class, workshop and retreat booking with Razorpay payments, and a free wellness-assessment quiz that works as the funnel, across three apps (site, admin and API). A studio is not a clinic, and I will say where the difference matters.

The founder and the starting point

Call her Sophie. She is a physiotherapist who owns two clinics in Melbourne with seven physios between them. Her 1:1 appointments run on Cliniko and work fine. What does not work is everything else she has added over the years: Clinical Pilates classes, a six-week return-to-running program, and a knee-rehab group. Those run on a mix of a Google Form, bank transfers and a spreadsheet of who has how many classes left.

Her first brief asked for "our own app to replace Cliniko, with classes". That brief is where most clinic projects go wrong.

Do you need a custom clinic booking app at all?

For 1:1 appointments, no. Practice management software is the "Calendly for clinics" category, and it is good at its job. Cliniko lists $45 a month for one practitioner, $95 for two to five and $145 for six to eight, with SMS reminders at 10¢ each. Sophie pays about $145 a month for booking, reminders, clinical notes and invoicing for seven physios. A custom replacement would cost more than ten years of that subscription before it matched the features, and she would own the compliance burden of clinical notes too.

So the scoping conversation flipped the brief: keep Cliniko as the clinical record and the 1:1 booker, and build only what it lacks. The dental practice automation story makes the same split with AI: buy the phone answering, build only the back-office gap.

• Buy: 1:1 appointment booking, reminders, clinical notes, invoicing and health-fund claims. All in the practice software.
• Build: class and program booking with capacity, packs and waitlists; payment for packs; and a short assessment that routes a new patient to the right pathway.

If your clinic only does 1:1 appointments, stop reading here and spend the money on something else. You don't need me or anyone like me.

Who built it, and why

Sophie looked at a local agency (quote above $50,000, including a native app she did not need) and at Pilates-studio software, which handled classes but would have meant a second patient database that did not talk to Cliniko. She chose a founding-engineer build: one senior engineer accountable for the design, code, hosting and launch, on a fixed quote after scoping. On my builds the client owns the code, the repository and the cloud and payment accounts from day one, sees a working demo every week, and gets written design docs and a handover.

The deciding reason was integration. Cliniko has a public API (Cliniko API docs), so the new system could link class bookings to existing patients instead of creating a second, conflicting record.

What got cut from v1

The build, week by week

1. Week 1: scope, data model, privacy. Which data lives in Cliniko, which in the new system, and which never gets collected. The design doc listed every field the assessment asks for and why it is needed.
2. Week 2: site and class schedule. Public pages for each program and a schedule with capacity per session.
3. Week 3: booking and packs. Book a session, use a pack credit, cancel inside the policy window and get the credit back.
4. Week 4: payments. Card checkout for packs; Stripe charges 1.65% + A$0.30 for domestic cards in Australia (Stripe AU). Breathe n' Being uses Razorpay; the pattern is the same.
5. Week 5: assessment funnel. Five questions, then a recommended pathway with a "book this" button. 1:1 recommendations deep-link into Cliniko's online booking; class recommendations go to the new schedule.
6. Week 6: admin and launch. Rosters, attendance, waitlist promotion, pack balances, refunds.

The health privacy part you can't skip

A booking system for a clinic holds health information, and that changes the rules. In Australia, the OAIC says the Privacy Act covers any business that is a health service provider, regardless of turnover (OAIC). The Notifiable Data Breaches scheme applies too. In the US, the equivalent conversation is HIPAA; in the UK and EU, it is UK GDPR and GDPR special-category data.

In practice, for Sophie's build that meant:

• The assessment collects the minimum: area of pain, how long, activity goal. No free-text symptom descriptions.
• Clear consent on the assessment before the first question, and a privacy notice written for patients, not lawyers.
• Data hosted in an Australian cloud region, which keeps the cross-border disclosure question simple.
• Clinical notes stay in Cliniko only. The new system never sees them.
• Admin access by named account with a log of who viewed what.

This is where a clinic differs from the studio build. At Breathe n' Being, the wellness quiz is a marketing funnel. At a physio clinic, the same pattern collects health information, so it needs a lighter touch and a stricter design. I'm an engineer, not a lawyer: have the privacy notice checked by someone qualified in your jurisdiction.

What the build and running costs look like

The build is a fixed quote after scoping. My MVP builds start at $15,000; for this scope my rough estimate is $15,000–$22,000, depending mostly on how many pack and cancellation rules there are and how deep the practice-software integration goes. You can put your own booking rules and integrations into the app cost calculator for a rough range. Running costs, assuming about 400 class bookings and 120 pack purchases at A$180 a month:

The point of the table is the first row. The cheapest line in this project is the software Sophie almost replaced.

What went wrong

• Two sources of truth crept in anyway. Patients sometimes booked a class under a slightly different email from the one in Cliniko. The fix was matching on mobile number plus date of birth at first booking, with a manual merge screen in admin for the rest.
• Pack expiry was a policy question. Do unused credits expire? After how long? Can they be shared with a partner? Sophie had never written it down, and the code could not be finished until she did.
• The first assessment was too long. The draft had twelve questions. Physios wanted all of them; patients would not answer them. Five questions with one decision each was the version that shipped.
• Waitlist promotion needed a deadline. Auto-promoting someone at 6 a.m. for a 7 a.m. class helped nobody. Promotion now stops a few hours before the session.

What launch looked like

Sophie switched the Clinical Pilates classes first, at one clinic, and kept the spreadsheet running in parallel for two weeks. The return-to-running program moved over next, then the second clinic. The assessment went live last, linked from the clinic's Google Business profile and from the physios' email signatures. The number to watch was how many assessment completions turned into a booking within a week, because that is what tells you whether the funnel earns its keep.

Checklist if you run a clinic or studio

1. List what your practice software already does. Don't rebuild any of it.
2. Find the gap: classes, packs, programs, intake, or a funnel. That is the build.
3. Check the practice software has an API before you choose a builder.
4. Decide which system is the source of truth for patients, and never duplicate clinical notes.
5. Write the pack, cancellation and waitlist policy before the first line of code.
6. Treat intake answers as health information: minimum fields, consent, known storage region.
7. Start with a mobile-friendly website. Go native only for something patients use daily.
8. Own the domain, the repository, the hosting account and the payment account yourself.

For a wider view of what goes into an MVP budget, see the 2026 MVP cost breakdown and how long an MVP really takes. If you have a gap your practice software can't fill, this is the kind of focused build I do; here is how I work and what it costs.