Build or Buy a Class Booking System? What the Estimate Leaves Out
Sooner or later, every growing activity school hears the same idea. “We have a developer. Why don’t we build our own booking system?” Sometimes the developer suggests it. More often it comes from frustration with a tool that almost fits.
It is a fair question, and the honest answer starts with how badly software projects tend to be estimated. McKinsey, working with the BT Centre for Major Programme Management at Oxford, looked at more than 5,400 large IT projects and found they ran on average 45% over budget and 7% over schedule while delivering 56% less value than predicted. Bent Flyvbjerg and Alexander Budzier, studying 1,471 projects for Harvard Business Review, found the average overrun was a more modest 27% — but that one project in six was a “black swan”, overrunning by around 200% on cost and 70% on time.
Those are enterprise programmes, not booking forms, and nobody should pretend the percentages transfer straight to a two-person project. What transfers is the direction of the error. Estimates are wrong in one direction, and the miss comes from work that was not visible when the estimate was made.
Booking for recurring classes has an unusual amount of that invisible work. This is where it hides.
The version you can estimate
Here is what gets built first, nearly every time:
a list of classes with times and venues, a sign-up form for the child and the parent, a card payment, a confirmation email, and an admin table of who signed up.
Two to four weeks for a good developer. It works on launch day. Then term starts.
What the first term adds
Make-up sessions
A child misses Tuesday. The parent wants Thursday instead. Suddenly you need a record of which session was missed and whether it was cancelled in time, a limit on how many make-ups a booking earns, sometimes scaled to the length of the term, an expiry rule and a decision about what happens to unused make-ups when the term ends — carry over, expire, or keep. Then the scope: same class, same programme, any venue, or a chosen subset. Then seats for make-ups in classes that are already full for new sign-ups, a waiting list when nothing is free, protection against two parents grabbing the last seat in the same second, and an email at every step.
This one feature is routinely bigger than the whole first version. And it never settles, because the business keeps refining its policy.
Trial classes
Most activity businesses sell through trials. A trial has its own price, often free, its own capacity, and a follow-up that has to turn it into a regular booking on the right payment plan. You will also want the trial-to-enrolment rate, because that is the number the owner actually manages week to week.
Payment plans, not payments
Parents rarely pay once. They pay monthly, per term, in instalments, or by direct debit. Somebody joins three weeks late and expects a pro-rated price. Somebody’s card fails. Siblings get a discount. The second term invoices itself. Every one of these has to be correct, visible to both the parent and the office, and backed by an invoice the local accountant will accept.
Changes after booking
Children move classes. Families pause. An instructor falls ill and a session is cancelled — which should be credited, not quietly turned into a make-up. A booking gets copied into a second class for a sibling. Each of those changes has to keep the money, the make-ups and the attendance consistent with each other, which is the part that produces the bugs nobody can reproduce.
Many venues, many brands
Open a second venue, or franchise, and the data model has to carry per-venue pricing, staff who see only their own venue, and reporting across all of them at once.
What the estimate usually compares
| Area | First version | What the business needs after a year |
|---|---|---|
| Class catalogue & sign-up | ✔ | Filters, age groups, waiting lists, capacity per class and per make-up |
| Payments | One card payment | Payment plans, direct debit, pro-rating, failed payments, invoices |
| Trials | – | Trial pricing, capacity, follow-up, conversion tracking |
| Make-ups | – | Earning rules, limits, expiry, scope, extra capacity, waiting list |
| Parent account | – | Bookings, payments, make-ups, cancellations, documents |
| Staff tools | Admin table | Attendance, messaging, reports, permissions per venue |
The left column is the part that estimates well. The right column is the part that gets re-estimated every term, and it does not stop — which is the second thing the research is clear about. IEEE’s own summary of the literature puts it plainly: maintenance consumes 60 to 80 percent of total software costs over a system’s operational life. Individual studies spread wider than that, depending on the era and the kind of software. None of them suggest the first build is the expensive part.
When building it yourself makes sense
Three situations, and they are real ones:
Booking is your product. You are a platform company and the scheduling logic is your competitive edge. Then of course you own it.
Your model is genuinely unusual — not “slightly different from the demo”, but a structure no existing system’s rules come close to.
A team will maintain it, not a person. For years. Including the year after your current developer moves on.
If none of the three applies, the build is paying to rebuild something that does not differentiate you.
The middle path: build the experience, not the engine
Most teams do not actually want to own make-up rules. They want a booking flow that looks and feels like their brand, a parent area that belongs to their site, and data flowing into their own CRM or app. That is a different ask, and it does not require owning the engine underneath.
With a platform like Zooza — the surfaces are laid out in full on the developer hub:
- Widgets cover booking, trials, maps, timetables and the parent zone, and you style them to your brand — down to custom course and session tiles.
- The REST API lets you build your own catalogue, timetable, location map or app on live data, with server-side credentials.
- Make-ups, trials, payment plans and waiting lists are enforced by the platform, so your front end cannot sell something the business does not offer. Worth reading how make-up sessions actually work before you estimate building them.
- AI tools plug in. Your website chatbot can know the logged-in parent, and staff can run day-to-day work from Claude through the Zooza MCP server.
- Your payment gateway stays yours. Connect your own and Zooza takes no cut of the transactions — a fee applies only on Zooza-provided card processing. For a developer sizing up platform risk, that is usually the question behind the question.
You keep the design and the customer journey. You skip the edge cases.
Five questions before you decide
Answer these with the business owner in the room, not alone at the keyboard:
- How do make-ups work today, and how many times has that policy changed in the last two years?
- How many payment models do you sell — term, monthly, pay-as-you-go, instalments?
- Do you run trials, and who follows up on them?
- How many venues will there be in three years?
- Who maintains this when the developer who wrote it has moved on?
If the answers come back as “it’s complicated”, “several”, “yes”, “more than now” and a pause — start from a platform and build on top of it.
Getting started
Create a free account at signup.zooza.online, request a REST API key from support, and start from the integration examples. Each one ships with copy-paste code and a prompt for your AI coding agent. If you would rather see the surface first, the REST API overview and the multi-step trial booking example are the two pages that answer “can this do what we need” fastest.
