What a custom booking system costs: our one real example
LuxuryTrainTickets.com, one of our own businesses, cost around £100k excluding VAT to build as a custom booking system. This is one real project and serves as an example of the complexity involved in such a build. We publish no price bands or starting prices for booking systems, so you should not scale this figure up or down to estimate your own project costs.
A custom booking system is software built around how you sell, including your products, dates, prices, suppliers and payment rules. This allows customers to book and pay on your own website while your team runs the business from one CMS. The LuxuryTrainTickets.com project used composable commerce, which means building an online shop from separate best-in-class parts instead of one all-in-one platform. This approach allows you to replace or extend one part without rebuilding the rest of the system. Because this booking system is built from separate parts, how custom it gets is the point. You can read our guide to composable commerce for the full explanation of this concept.
The cost of a booking system depends on three main factors: the number of suppliers you manage, how complex your pricing is and what the system connects to. For a marketing manager, complexity often arises from managing different cabin types, deposits, balances, and multiple currencies. A custom build must account for these specific rules to ensure the checkout logic works correctly. The number of supplier feeds and the various tools you need to connect to, such as a CRM or accounting software, also drive the technical requirements and the final price.
We start bespoke builds with a first release that does the essential job and then add more in stages. This means a build does not have to arrive all at once. For the LuxuryTrainTickets.com project, the first site took 2 weeks to build, and subsequent updates over the years took another 12 weeks. This shows how a first release grows in stages through iterative development. Every stage of a project is dated in the written proposal so that the roadmap is clear from the start.
What that money pays for: each part of the build and its job
The money pays for connecting specialist tools into one booking flow, with a separate tool for each job.
- Webflow: pages, CMS and SEO
- Foxy: cart, checkout, deposits and balances
- Stripe: card payments, each currency to its own account
- Cloudflare: background tasks that monitor supplier pages for updates
- Mailchimp: guest and campaign emails
Webflow provides the front end, including pages, the CMS (the system your team uses to edit the site's content) and SEO. While Webflow has good ecommerce for general stores, it is not built for complex bookings, add-ons, deposits and multi-currency. This is why we use Foxy to handle the cart, checkout, deposits and balances. Foxy can connect to any checkout while Webflow connects only to Stripe or PayPal, which makes multi-currency easier and allows more payment methods.
Foxy supports many product types, including bookings, event tickets, memberships, services and subscriptions. It also provides gateways and alternatives, with its fees separate from the processor. Technical connections are available through webhooks, an API and connections to Make, Zapier and Pipedream. These features allow the system to work with various tools. A marketing manager can use these to manage different types of sales through a single interface.
The checkout can be customised with a logo, CSS, JavaScript, HTML and raw template access. Foxy is a PCI DSS compliant Level 1 service provider, listed on the Visa and Mastercard global registries, where card details are submitted through Foxy's infrastructure. This level of customisation means the booking process can match your brand identity. Using a secure, compliant infrastructure handles the technical requirements of processing sensitive data.
Foxy handles tax with manual or automatically calculated rates and connects to Avalara, TaxJar and Thomson Reuters. This allows for the management of different tax rules across different regions. Having these tools in place helps a business manage the financial requirements of international sales.
On the LuxuryTrainTickets.com case study, the customer follows a specific path through the system. A guest selects a cabin, such as a Twin Cabin, Cabin Suite or Grand Suite, and chooses a departure date pulled from the CMS. They can then add extras like champagne, flowers or a carbon offset. Finally, they pay in full or leave a deposit through Foxy and Stripe. This structured flow allows for a clear customer journey from selection to payment.
Such a system connects to CRMs, accounting, payments, supplier feeds and your databases. Each connection is more work to build and test.
Why multi-currency and self-serve deposits add to the build
Multi-currency and deposits add to the build because each one needs its own checkout rules, payment setup and accounting treatment. A marketing manager must plan for how different currencies interact with the database and the customer journey. For example, LuxuryTrainTickets.com, one of our own businesses, lists over 50 Venice Simplon-Orient-Express trips. Each trip shows three different cabin prices in pounds, dollars and euros from one CMS. When an operator has not shared a price, the system shows POA instead of a guess.
Foxy allows customers to check out in their preferred currency. To manage this, the store creates a template set and a payment set for each currency. Each set includes its own payment methods and credentials. This setup allows each region to settle through a local merchant account. Managing these multiple sets requires specific technical logic in the checkout flow.
Transaction fees vary depending on the card used. For an illustration of Stripe's UK standard pricing with no setup or monthly fees, consider a £10,000 booking:
- Standard UK card: 1.5% + 20p, £150.20
- Premium UK card: 2.8% + 20p, £280.20
- EEA card: 2.5% + 20p, £250.20
- International card: 3.15% + 20p, £315.20
If currency conversion is required, a 2% charge applies. On that £10,000 booking, the conversion adds £200. These costs must be accounted for when defining pricing rules and tax logic.
Deposits add another layer of complexity to the build. On a Big Rocket booking system, full payments, deposits and balances can be set per product. A customer can choose to pay a deposit now and settle the rest later. When they select a deposit, the total amount updates immediately at the booking step. This requires the system to handle different payment types within a single transaction flow.
A later stage for many businesses is the introduction of customer portals. These allow customers to manage bookings, pay balances and download documents themselves. A portal can also let users update details, change a booking or add to an order. Unlike some software that charges per seat, custom portals have no per-user fees.
Accounting for these payments requires strict adherence to tax rules. HMRC defines a deposit as a proportion of the selling price paid before you supply. The tax point, which is the date you account for VAT, is the earlier of receiving the deposit or issuing a VAT invoice. If a customer pays a remaining balance early, it creates a further tax point. In this case, the VAT on that balance goes on the return for that period.
Rules regarding forfeitable deposits also apply. VAT is declared when you receive the deposit or issue a VAT invoice, whichever happens first. If the deposit is kept, VAT remains due on the money received. Because these rules change based on when money moves, you should check with your accountant before deciding how to build the payment logic.
Security is another critical factor. Since 14 September 2019, Strong Customer Authentication rules have applied to electronic payments. This is a check that the person making an online payment is permitted to do so, unless an exemption applies. Because of this, both deposits and balances must pass these security checks during the checkout process.
How gift vouchers and UK rules change the scope
Gift vouchers add scope because the system must sell them, track what is left on each one and let a customer spend them against a booking. In the LuxuryTrainTickets.com project, the single checkout handles dated journeys, extras and gift vouchers together. This requires specific logic to manage different product types in one flow.
- Types: universal and train-specific
- Amounts: £100 to £100,000
- When the journey costs more: the difference is paid when booking
- When the journey costs less: the remainder stays as credit
- Validity: 24 months from issue, non-refundable
- Delivery and security: email delivery and the check on redemption
Each of these points is a rule that someone has to decide and build into the software. A marketing manager must define these parameters before development begins. For example, deciding if a voucher is universal or specific to one train route changes how the checkout handles the selection. Setting an amount range also dictates how the database and payment logic are structured. If a journey costs more than the voucher, the system must allow for a top-up payment during the booking process. If the journey costs less, the logic must handle the remaining balance as credit for a future booking. The system also needs to manage expiry dates and security checks, such as verifying the recipient's name or the original purchaser's identity upon redemption. Every one of these requirements is a specific rule for the build.
Foxy can accept digital gift cards and track balances. This functionality allows a store to manage the remaining value on a card as it is used across different transactions. The way these vouchers are categorised impacts how VAT is handled.
HMRC distinguishes between single-purpose and multi-purpose vouchers. A single-purpose voucher is one where both the VAT liability and the place of supply of the underlying goods or services are known when it is issued. In this case, VAT is paid at issue and at each paid transfer, not on redemption. A multi-purpose voucher is any voucher that is not single-purpose. For these, VAT is payable only when the voucher is redeemed, on the last price paid for the voucher or, if that is unknown, its face value. Because the type of voucher changes when VAT is due, your accountant should decide on the rules before the build starts.
Other regulations apply once you begin taking bookings. These include:
- Cancellation rights: Regulation 28(1)(h) of the Consumer Contracts Regulations 2013 takes accommodation, transport of goods, vehicle rental, catering and services related to leisure activities out of the cancellation rules where the contract provides for a specific date or period of performance.
- Package holidays: Regulation 19(1) of the Package Travel and Linked Travel Arrangements Regulations 2018 requires a UK-established package organiser to provide effective security covering the reasonably foreseeable costs, if it becomes insolvent, of refunding travellers for services not performed and, where carriage is included, repatriating them.
- Cookies: The ICO states that a website must tell people it sets cookies, explain what they do and get consent. However, consent is unlikely to be needed for cookies that remember what a user adds to their basket or takes to checkout, because they are essential to the service the user asked for.
- Customer data: The ICO states a business can rely on the 'contract' lawful basis to process someone's personal data when it needs that data to deliver a service they have contracted for, including processing payment details, or to do something they asked for before a contract. This does not cover reusing customer data for the business's own purposes. The contract lawful basis does not apply if you could reasonably do what the customer wants with less data or in a less intrusive way.
These rules belong in the project brief because they shape how the checkout wording is written, what data is stored and how money is held. They define the technical requirements for the entire system. You should take legal advice regarding your own business.
What sets your price, and when software is the better buy
Five things set your price, and if you take easy bookings from one provider, booking software is usually the better buy.
- Suppliers and inventory feeds: Tell your developer how many different suppliers you manage and how their data needs to be brought into your system.
- Pricing and date rules: Explain the complexity of your pricing, such as managing different cabin types, deposits, balances, and multiple currencies.
- Payments: Detail how you want to handle customer transactions, including the need for partial payments or specific payment methods.
- Links to other systems: List every tool you need to connect to, such as your CRM, accounting software, or email marketing platforms.
- Moving from a legacy site: Describe what content, data, or search engine rankings you need to move from your current website to the new system.
Webflow allows us to add booking pages, a cart, and a checkout to an existing site. This means your business can keep its current design, content, and search engine rankings while gaining new functionality.
- Cost to start: Software has a low cost to start through monthly subscriptions, whereas a custom system requires a larger one-off build cost.
- Ongoing fees: Software usually involves monthly costs plus fees per booking, while a custom system has hosting and ongoing support costs.
- Fit: Software requires you to adapt to the tool's model, but a custom system is created specifically for your unique products and rules.
- Booking on your website: Software bookings often happen on a hosted page or an embedded widget, while custom systems use native, on-brand pages.
- Integrations: Software integrations are limited to what the vendor allows, but a custom system can connect to anything with an API.
- Your data: Software data sits on the vendor's platform, while a custom system keeps your data in systems you own.
Off-the-shelf booking tools are best for businesses that handle easy bookings from a single provider. Custom systems suit companies managing multiple suppliers, complex pricing structures, or high-value orders.
We build custom booking systems for tour and travel companies, experience and activity providers, agents selling other suppliers' inventory, and events and hospitality venues. A bespoke build is also for businesses whose current platform cannot meet their needs, those paying for several tools that do not work together, businesses where the workflow is their competitive edge, or those who want to own their code and data.
You should look elsewhere for a bespoke build if a standard Webflow site is sufficient, if you want the cheapest possible build, or if no one will own the product after it launches. In those cases, a cheaper option is fine.
Building custom booking pages allows your business to be found in search engine results and AI answers. We built LuxuryTrainTickets.com, one of our own businesses, with structured data on every pricing and journey page, FAQ markup on every train overview page, author pages, and an llms.txt file to assist with this. This technical setup helps search engines and AI models understand your product details.
A business might invest in a custom build to solve specific operational challenges. For example, LuxuryTrainTickets.com was built as a custom system to handle its specific requirements. After launch, we can maintain the bespoke system or hand it over to your own developers with full documentation. In both cases, hosting and support continue.
We scope every project before providing a quote. A first call and a short discovery period lead to a written proposal that outlines the work. If an off-the-shelf tool would be sufficient for your needs, we will tell you, even if it means a smaller project.
If your bookings involve several suppliers, complex pricing, or high-value orders, bring those details to us and look at how we build custom booking systems.
Sources
Researched and fact-checked with the help of AI tools and Ahrefs data.

