Booking is one of those problems that looks solved until you look at your own rules.
What bespoke actually means here
The word gets used loosely, so it is worth being precise. Most booking tools are configurable: you set your opening hours, your services and your prices, and the product does the rest. That is genuinely enough for a lot of businesses.
A bespoke booking system is what you need when your rules do not fit the fields on offer. Not because the tool is bad, but because it was built for the average of ten thousand businesses and you are not the average. The test is simple. If you are filling in the fields, configure. If you are working around them, build.
When a plugin stops being enough
| Your situation | Plugin | Bespoke |
|---|---|---|
| Fixed 30-minute slots, one person | Fine | Overkill |
| Variable appointment lengths by service | Awkward | Straightforward |
| Rooms or equipment that cannot double-book | Usually not supported | Core requirement |
| Different deposit rules by service | Rarely supported | Straightforward |
| Staff with individual availability and skills | Sometimes, badly | Straightforward |
| One booking consuming two resources at once | No | Straightforward |
| Your own app with notifications | No | Yes |
The rules that break off-the-shelf tools
In practice the same handful of requirements come up, and they are the ones that turn a configuration job into a build.
A booking that consumes more than one thing. A treatment that needs a therapist and a room. A van and a driver. A tutor and a classroom. Most tools model one calendar per person and cannot express a slot that is only available when two separate resources are both free.
Rules that depend on what came before. No bookings within four hours of the last one for that member of staff. A deep clean after certain treatments. A minimum gap for travel between sites. These are invisible to a tool that treats every slot as independent.
Prices and deposits that vary by more than the service. By customer type, by time of day, by whether it is a first visit. Once pricing has conditions, most booking products run out of room quickly.
Approval before a booking is confirmed. Common in schools, clinics and the public sector, where a request is a request until somebody with authority accepts it. Off-the-shelf tools generally treat booking and confirmation as the same event.
Somebody else's system holding the truth. If your practice management software, your CRM or your finance system already owns the customer record, the booking system has to fit around it rather than become a second version of it. That is an integration problem, and it is covered in more depth in integrating with existing systems.
What we build
- Self-service booking and rebookingSo your reception is not the bottleneck.
- Automated remindersThe cheapest intervention against no-shows.
- Deposits and paymentThe second cheapest, and usually the more effective one.
- Resource and staff availabilityRooms, equipment, and people with their own rules.
- Multi-resource slotsA booking that needs two things free at once, not one.
- Cancellation and waiting listsSo a cancelled slot refills itself.
- Approval workflows where you need themA request stays a request until somebody accepts it.
- An admin view of the diaryFor the people who run it day to day.
Who this tends to be for
Clinics and therapy practices, where the constraint is usually rooms and equipment rather than people. Salons and studios, where it is staff skills and treatment lengths. Venues and hire businesses, where one booking blocks an asset for a period rather than a slot. Schools and colleges, where parents and staff both book against the same resources and somebody has to approve it.
The common thread is not the sector. It is that the diary has rules a calendar cannot express.
Moving off what you have now
Most businesses asking for a bespoke booking system already have something, and the question is not whether to build but what happens to the bookings currently in the old tool.
Bookings themselves migrate cleanly, because a booking is a date, a customer, a service and a resource, and every tool exports that. What migrates badly is history that only makes sense inside the old system: internal identifiers, audit trails, soft-deleted records. Decide before the build which of that you actually need, because pulling all of it across is usually more work than the booking system itself.
What you own at the end
The code, the database and the accounts are yours, transferred when the build completes. You can host it where you like and take it to another developer. That matters more with booking systems than most software, because the diary is the business, and renting it from whoever built it is how businesses end up unable to leave. There is more on this in who owns the code.
Common questions
What makes a booking system bespoke rather than configured?
A configured system is an existing product with your logo and your opening hours in it. A bespoke booking system encodes rules the product does not have a field for: a treatment that needs two staff and a room, a deposit that changes by service, a slot that cannot be booked within four hours of the last one. If your rules fit the fields, configure. If you are working around the fields, build.
Why not use a booking plugin?
Use one if it fits. Plugins fail when your rules are specific: variable appointment lengths, resources that cannot be double-booked, staff with different availability, deposits that differ by service. That is when bespoke starts being cheaper than working around the tool.
Can it take deposits?
Yes, and for most businesses this is the single most effective thing against no-shows, more so than reminders.
Does it handle staff and resource availability?
Yes. Rooms, equipment, and people can each have their own rules, which is usually the exact thing off-the-shelf tools get wrong.
Can we move our existing bookings across?
Usually. Most tools export to CSV, and the bookings themselves migrate cleanly. What rarely migrates is history tied to the old system's internal ids. We agree before the build what has to come across and what can stay behind in a read-only export.
Do we own the system at the end?
Yes. The code, the database and the accounts are yours, transferred on completion. You are not renting it from us and you can take it to another developer.