A booking system for three clinics: no-code or not?

The situation

A small health group ran three locations on a mix of phone calls, a paper diary, and one shared spreadsheet that no one trusted. They asked whether a custom-built system was the only serious option, or whether no-code app development could carry the load.

Our first job is not to sell a build. It is to work out whether the build makes sense at all. So we ran a fit check before quoting anything.

What we checked first

The questions that decide fit are rarely about features. They are about load, data, and who edits the thing once we leave. For a booking system across three sites, we looked at concurrent edits, double-booking risk, and how staff actually move through a day.

• Peak concurrency: a few dozen bookings an hour, not thousands per second.
• Data sensitivity: appointment data needs care, but this is not a real-time medical device.
• Who owns it after launch: non-technical staff who need to change opening hours without calling anyone.

Why no-code held up here

None of those constraints pushed past what a no-code MVP handles well. We could build a Bubble back end with proper roles, a clean booking flow, and an admin view the front desk could edit themselves. That last point mattered most: the client wanted to own the system, not rent our time forever.

This is the kind of internal-tool work where no-code is genuinely the right call, not a compromise. The build came in around the internal-tools range and shipped in under five weeks.

Where it would have been a no

If the group had wanted live clinician video, offline-first tablets in low-signal rooms, or integration with a regulated records system, we would have said so plainly. That is a custom development conversation, and pretending otherwise would have cost them later. Honesty about the ceiling is the whole point of a fit check.