The club was paying a monthly subscription plus a percentage of every single booking to a platform that still did not quite fit how their camps ran. For anyone charging per child per day, a percentage of every booking is the part that scales against you. We built a replacement with no booking-platform commission on top of the card processing fees.
A bespoke booking and payment system that replaced a subscription platform charging a monthly fee plus a percentage of every booking. Same capability, no booking-platform commission on top of card processing fees, and the club owns it.
Parents book the days they need. The system prices and tracks capacity accordingly, rather than forcing whole-week blocks.
Card payments go straight to the club’s own payment processor account, with no booking platform fee on top of it.
A booking system for children collects medical notes, emergency contacts and dietary requirements. Where that data goes matters as much as how it is stored.
A bespoke system is only cheaper than a subscription if it does not need constant attention.
Most of the value in a system like this comes from the systems it talks to, and most of the risk does too. Each connection is scoped to the access it needs for the job.
The path a piece of work takes through the system, start to finish.
The booking form takes the specific days needed for each child. Availability is checked per day as the selection is made.
Pricing, pro-rating and discounts are calculated entirely on the server in whole pence. The browser is never trusted with a figure that affects what gets charged.
Checkout is handed to the payment processor. Card details never reach the club’s site, and the club receives the money into its own account rather than through a booking platform.
The booking is only confirmed when a signed webhook from the payment processor says the money moved. Repeated webhooks are handled safely, so a retry never creates a second booking.
Registers, capacity and the medical details for each child are available in the system to the people running the session, rather than being emailed around or copied into the payment provider’s records.
The problems that decided how this was built. They are the reason it works the way it does rather than the obvious way.
Custom software is only a saving if it does not generate a stream of support work. Plenty of bespoke builds cost more over three years than the SaaS they replaced.
The build carries an automated test suite over the parts that hurt when they break (pricing, capacity, payment confirmation) running on every change, plus a local environment that mirrors production and automated health checks that report problems before the club notices them.
A system with no booking-platform commission on top of card processing fees, built so the maintenance does not quietly replace the saving.
Payment providers retry webhooks. A naive booking system treats the retry as a second payment and double-books a place, or worse, tells a parent their child has two slots.
Confirmation handling was written to be idempotent from the start: the same event applied twice produces the same result as applying it once, and the booking state is derived from the verified payment rather than from the order of arriving messages.
A retried or replayed webhook produces the same booking state as the first one, so a network failure changes nothing.
We don’t publish screenshots, logos or client names for this work. Much of it runs inside a business and handles sensitive data, so we describe what was built rather than who it was built for. We’re happy to walk through the detail on a call.
Every build on this page started as a workflow that off-the-shelf software nearly handled. Tell us where the gap is and we’ll scope what it takes to close it.