Separate the website from the booking engine
The public website explains and sells the experience. The booking engine manages the reservation. They can be part of one product, but they do not have to be. A tailored website connected to an existing product can improve presentation while keeping a working operational system.
Test the handover between them on mobile. Check that the customer understands the selected experience, dates and next step when moving into the booking flow. A change of visual style may be acceptable; lost context or an unexpected total is more serious.
| Question | Existing product | Bespoke application |
|---|---|---|
| How quickly can it be used? | Often sooner if configuration and data fit. | Requires design, implementation and testing. |
| Who decides the roadmap? | The product supplier serves many customers. | You prioritise work and fund the changes. |
| How flexible are the rules? | Limited to supported features and extensions. | Can reflect your rules, subject to scope and budget. |
| Who maintains it? | Supplier handles the product; your configuration still needs an owner. | Maintenance and operational support need explicit arrangements. |
| What happens when you leave? | Check exports and termination terms. | Check code, accounts, documentation and transfer arrangements. |
Demonstrate the hard booking, not the easy one
Write down your most awkward ordinary case. It might be a group changing dates, two products sharing the same capacity or a reservation with a deposit and a later balance. Ask each option to demonstrate that case, including what staff must do afterwards.
- Can it represent the resource being sold without pretending it is something else?
- What happens to capacity while a payment is incomplete?
- How are changes, cancellations and refunds represented?
- Can staff correct a record without losing the history?
- Can the information needed by other systems be exported or accessed reliably?
Compare total cost with the workaround included
For an existing product, include subscriptions, relevant usage charges, configuration and staff time spent on workarounds. For a bespoke application, include discovery, development, testing, hosting, support and future changes. Use the same planning period and realistic usage assumptions.
Do not count a manual task as eliminated until the replacement handles exceptions too. Equally, do not assume custom software has no recurring costs simply because the business owns the code. The application budgeting guide helps make those costs visible.
Look for a middle route
Sometimes the core booking rules fit a product while one report, approval step or customer communication does not. A supported integration or small internal tool may be enough. Check that the product exposes the necessary information and that the connection can recover from errors.
If the missing behaviour is central to availability or money, investigate carefully before adding another layer around the product. Our booking reliability guide covers payment and reservation states that need coordinated handling.
Write down the decision
Record the rules that each option supports, the remaining manual work, the costs and the reason for the choice. This is more useful than a feature-count comparison. If the bespoke route is justified, that record becomes part of the brief for booking system development. If an existing product wins, invest in implementation, staff training and a clear public website instead.
Discuss the booking rules that do not fit
Bring the current software and a real scenario it struggles with. We can discuss whether the website, an integration or the booking system itself needs to change.