Building a custom booking platform

A custom online booking platform is worth building when your availability, payment or integration rules do not fit existing software: bookings that tie up several resources at once, deposits and cancellation terms specific to your trade, business customers with several users, or a must-have link with your invoicing. For simple fixed-length appointments, an off-the-shelf tool does the job well. This guide helps you decide, then covers what needs careful design: the availability model, payments, cancellations and calendar sync.

Booking platform or marketplace: pick the right project

A booking platform sells the time or resources of one business: your practice, your rooms, your equipment, your training sessions, your workshops. You are the seller, the money lands in your account, and the software runs your own operations.

A marketplace lets customers book third-party providers and pays each of them out: split payments, seller verification, moderation, platform regulation. It is a different and heavier project, covered in how to build a two-sided marketplace and priced in how much it costs to build a marketplace. A franchise network or a company with several sites usually stays in the first category: one merchant account, many calendars.

When off-the-shelf is enough, and when it is not

Scheduling and booking tools are plentiful and often very good. Custom development only makes sense if one of the signals below applies and it affects your revenue or your operations.

If none of these apply, buy a tool and revisit the question when its limits cost you more than a build would. If several apply, booking is probably the core of a broader custom business application, which is where a custom build earns its keep.

The core: the availability model

Everything starts with a question that looks simple: "is this slot free?". The answer depends on several concepts you need to name before writing code.

• Resources: people, rooms, equipment, seats. A booking can use several, each with its own calendar.
• Opening rules: working hours, holidays, one-off closures, per resource and per site.
• Durations and buffers: set-up, cleaning or travel time between two bookings, often forgotten in version one.
• Capacity: a group class takes several participants, a meeting room one group.
• Lead times: earliest and latest booking time, and the cancellation cut-off.
• Time zones, as soon as a customer or a resource is not in yours.

One technical point is non-negotiable: two customers must never be able to book the same slot. Checking availability and saving the booking happen in a single atomic operation on the server, and a slot that is being paid for is held for a few minutes, then released if payment fails. Users never see it, and it is what separates a reliable system from a form that sends an email.

Deposits, prepayment and card holds

Taking money at booking time reduces no-shows, but the way you do it has legal and technical consequences.

Deposits and prepayment. Whether a deposit can be kept when a customer cancels, and how much of it, is governed by consumer law and by your own terms, and the rules differ from one country to another. The software should state clearly what the payment is (deposit, full prepayment, fee), repeat it in the confirmation and on the receipt, and apply the matching refund rules automatically. Have your terms reviewed by a lawyer in each market you serve.

Card holds. The alternative is to authorise an amount without charging it, then capture it if the customer does not show up. There is an important technical limit. According to Stripe's documentation, an online card authorisation is generally valid for seven days. For a booking three weeks out, the hold expires before the appointment. The answer is to save the card with strong customer authentication and charge it later if the cancellation terms allow. That requires the customer's explicit consent at booking, and a fallback journey if their bank asks for authentication again when you charge.

Cancellations, no-shows and cooling-off periods

Cancellation rules are what customers read most closely, and what teams apply least consistently by hand. The software should own them entirely: free cancellation window, any penalty, rescheduling, automatic refunds, releasing the slot and offering it to the waiting list.

In the EU, consumers normally have 14 days to cancel a distance contract, but not for everything. The European Commission's Your Europe guide lists exceptions including hotel bookings, car rental and catering for specific dates, and tickets for events. Many other services booked online remain covered, so check how yours is classified, and display the right information before payment.

Against no-shows, the simplest lever is automatic reminders by email or text message, with a one-click link to cancel or reschedule. A customer who can cancel easily frees a slot; one who cannot just does not turn up.

Syncing calendars without double bookings

Your team lives in Google Calendar or Outlook, and the platform has to work with that. There are two approaches, with very different reliability.

• Subscribing to an iCalendar feed, the standard calendar format (RFC 5545). It is easy to set up, but it is read-only and its refresh rate depends on the app that displays it, so it does not protect you against double bookings.
• API sync with Google Calendar or Microsoft 365. It takes more work, and it is the only way to get reliable availability. It has its quirks: Google Calendar push notifications only say that something changed, without the details, and notification channels expire with no automatic renewal. The platform must re-read the calendar on every notification and renew channels before they lapse.

Either way, pick a single source of truth for availability: the platform. External calendars feed it (a personal appointment blocks the slot) and mirror it (a booking appears in the staff member's calendar), but conflicts are settled in one place.

The rest of the scope

Around the booking engine, a custom platform usually includes:

• A customer area: past and upcoming bookings, receipts, invoices and documents. It can grow into a full client portal.
• A back office: a schedule per resource, bookings taken by phone, blocked periods, occupancy statistics.
• Invoicing: receipts for consumers, invoices for businesses, following the e-invoicing rules that apply where you operate.
• Data protection: collect only what the service needs, and purge what is no longer useful.

As for format, a responsive web app that can be installed as a PWA covers the vast majority of booking needs; a native app is mainly justified for advanced features in the field.

What drives the cost

A booking platform has no list price either, but its cost drivers are predictable. In rough order of weight:

• The availability model: one resource per booking is simple; several resources, buffers and capacities multiply the cases to design and test.
• Payments: a full prepayment is straightforward; deposits, saved cards, partial refunds and penalties each add journeys and edge cases.
• Calendar sync: a read-only feed costs little; reliable two-way API sync with Google Calendar and Microsoft 365, renewals included, is a real workstream.
• Integrations: invoicing, operational software or access control, each with its own API and failure modes.
• The back office: phone bookings, blocked periods and reporting often weigh as much as the customer-facing flow.

Running costs follow: hosting, card processing fees, email and text message delivery, and maintenance as third-party APIs evolve.

A four-step method

1. Write the rules down: resources, durations, buffers, payment, cancellation. One page is enough, with real examples from your current schedule.
2. See the journey on a prototype: booking on the customer side, the schedule on the team side, cancellation cases.
3. Launch on a narrow scope: one site, one service category, then widen.
4. Measure occupancy, no-shows and team time saved before adding features.

Where to start

The most useful step is to test your real rules against a visible journey before any development. That is what the prototype is for: LPR Studio presents it for free in a video call within 5 working days, with the booking flow, the team schedule and cancellation cases built on your own data. It then becomes the basis for a fixed price or a subscription, and it is also a good way to confirm that an off-the-shelf tool would be enough.