The four things that decide the price
Who pays, and when. Free sign-up is a calendar. Payment at booking is a calendar plus a payment provider, refund rules and reconciliation. Invoicing afterwards is a third system, and it is rarely the cheapest one.
What happens after the payment. A confirmation email is one thing. A code valid for exactly that window, a heater that starts forty minutes early, a reminder the day before and a follow-up afterwards are four things – each with its own way of going wrong.
How many people share the calendar. One resource in one place is simple. Several rooms, several locations, different prices at different hours, seasons, staff who each need their own view – that is not more of the same, it is a different data model.
Whether something physical has to happen. The moment a booking has to drive a lock, a heater or a counter, the software is talking to the world. Now it has to cope with the network being down, the hardware answering late, and a guest standing outside the door regardless.
What you are actually buying
A booking system is sold as one thing and is usually seven:
- The calendar – availability, duration, buffers, seasons, blocked hours.
- The payment – capture, refunds, part payments, reconciliation.
- The customer relationship – accounts, memberships, punch cards, history.
- The messaging – confirmation, reminder, change, cancellation, over email and SMS.
- The admin – the part you live in every day, and the part most often left until last.
- The integrations – accounting, locks, controls, calendars, whatever you already run.
- Operations – monitoring, backups, updates, and somebody who answers when it stops.
When two quotes are wildly far apart, it is almost always because they count a different number of these.
Off-the-shelf or your own code
Ready-made systems are good, and they are cheaper than building. The rule we use ourselves: off-the-shelf for as long as the business can follow the system. Your own code when the system has to follow the business.
Three situations tend to justify building. When your workflow is the product and will not bend. When two or three systems are kept in sync by hand and somebody spends an hour a day doing it. And when something physical has to be controlled – there is usually no off-the-shelf option at all.
HeatBooking was built for the third reason. Booking, payment, memberships, the cleaning schedule and door access hang together in one flow, and at Vestfjord Sauna that same flow drives a PLC with temperature probes and a heater that has to be hot when the guest arrives. That does not exist as a subscription.
Where the price actually runs away
Not in the features. In the edges:
- Cancellation. Who gets money back, how late, and what happens to the punch?
- Double booking. Two people tapping the last slot at once. Solved in the database, not in the interface.
- Daylight saving. Twice a year an hour exists twice, or not at all.
- Payments that hang. The card was charged, the answer never arrived. The system has to survive that without a human tidying up.
- Personal data. What is stored, for how long, and who can see it.
None of this is extra work. It is the work. A quote that mentions none of it has moved the bill to later.
How to find out in an hour
We do not put a price on something before knowing what it is – a logistics company with machine learning and a two-room sauna business are not the same job, and a price list would be useless to both.
So: describe your operation in the Living Brief and you get an architecture sketch, phases and a range in weeks straight back, without anyone phoning you. If you would rather start wider, the free AI review looks at the whole business and points at what is worth doing first.