The question
A clinic reads that we built a booking platform for a multi-site clinic network and asks, reasonably: is that what you would build for us, and is it more than we need? The answer is that the network project and a single-clinic website are different things built by the same hands with the same principles, and the smaller one is the right one for most clinics. Here is what the platform was, what carries over, and what does not.
What the network platform was
A group with many locations and a large practitioner team needed one system for patients to find the nearest clinic, choose a practitioner by discipline and availability across sites, book into the group's practice management system, manage their appointments, and be reminded, with the group's brand and reporting across all sites. Off-the-shelf booking pages could not do cross-site search and matching the way the group wanted, so a custom front end was built on top of their practice system's API: a Next.js application with its own availability search, practitioner matching, patient accounts and analytics, integrated with the practice system for the diary itself.
It was a software project: months of work, a team, ongoing engineering. It was right for an organisation of that size with those requirements.
What a single clinic gets that came from it
The principles. Booking one tap from every page. The choice of practitioner and location made on the page, not in the widget. Speed on a phone as a hard requirement. Condition pages in the patient's words. Tracking from the first day. Health data kept out of general forms. These were learned and refined on the network work and they are in every clinic site.
The integration knowledge. We know how Cliniko, Jane, Nookal and their peers expose availability, what their deep-link parameters do, where their embeds break in in-app browsers, and how their intake and reminder features should be configured. That came from building against these systems at scale.
The content model. Practitioners, conditions, services and locations as related records, so a change in one place propagates everywhere. The network needed it to stay coherent across dozens of sites; a single clinic benefits from the same structure at a fraction of the size.
The performance discipline. The network platform had to be fast under load and on poor connections. The habits (image handling, script budgets, edge caching) apply directly to a clinic site.
What a single clinic does not get, on purpose
A custom booking engine. The network needed one because of cross-site matching at scale. A single clinic, or a clinic with two or three sites, does not. Its practice management system's own online booking, configured well and deep-linked from the site, does everything needed, at no additional software cost, with reminders and intake included, maintained by the system vendor. Building a custom engine for a single clinic would be more expensive, more fragile and worse.
Patient accounts on the website. The practice system provides the patient portal. Duplicating it is cost without benefit.
Cross-site availability search. Two or three locations are handled by a page per location and location pre-selection in the booking link. The search interface is unnecessary until there are many sites.
An engineering retainer. The network platform needs ongoing development. A clinic website needs a care plan: updates, backups, monitoring, the monthly booking test and small changes.
The price. The network project was priced as software. A clinic website is a fixed-price build in the mid four figures, because it is a website integrated with a system that already exists, not a system.
When a clinic does need the bigger version
- Many sites (roughly eight or more) where patients genuinely need to search availability across locations.
- A group brand where the booking experience is a differentiator and the practice system's portal cannot deliver it.
- Requirements the practice system cannot meet after configuration: complex matching rules, multi-practitioner appointments, integration with other systems at booking time.
- An organisation with the budget and the team to own software.
If two or more apply, the conversation is about a platform, and we will say so. For everyone else, the platform would be the wrong answer, and we would rather build the right one.
How to tell which you are
Answer three questions: how many locations, whether your practice system's online booking does what patients need once configured, and whether you want to own software or a website. One to three sites, a capable system and a preference for a website: the clinic website at a fixed price. Many sites, a system that falls short after configuration, and a team to own it: a platform conversation.
Where this sits
The network project taught us what makes clinic booking work; the clinic website is that knowledge applied at the right scale. You get the principles, the integration expertise and the content model. You do not get software you would have to maintain, because you do not need it.