Wat een boekingssysteem in 2026 echt kost

"Boekingssysteem" is één term die het werk van drie doet. De website van een kapper met een kalenderpagina is een boekingssysteem. Een restaurantplatform dat tafelvoorraad over veertig zaken jongleert is een boekingssysteem. Booking.com is, technisch gezien, een boekingssysteem. Dus als een founder vraagt wat er een kost, is het eerlijke eerste antwoord een tegenvraag: welke van die drie ga je bouwen?

De prijskaartjes lopen van $10 per maand tot een half miljoen dollar, en beide uitersten zijn voor iemand een legitiem antwoord. Dit is waar de grenzen liggen in 2026, en waar het geld zich verstopt zodra je besluit te bouwen. Het zit nooit in de kalender.

De vraag van $20 per maand: moet je überhaupt bouwen?

Begin met de saaie optie, want voor de meeste bedrijven wint die. Calendly begint bij $10 per seat, Acuity bij $20, SimplyBook.me loopt van gratis tot ongeveer $60, en Mindbody opent op $99 per locatie. Een hele industrie die met bijna 15% per jaar groeit concurreert er al om dit voor je op te lossen, en als je probleem "klanten moeten een slot kiezen en een herinnering krijgen" is, dan is dat jaren geleden al opgelost. Je moet geen developer betalen om het opnieuw op te lossen. Wij bouwen boekingssystemen voor de kost, en dit is nog steeds het eerste wat we vertellen aan mensen die ons bellen.

Het huursegment wordt interessanter wanneer de leverancier een percentage rekent in plaats van een abonnement. FareHarbor, het dominante boekingsplatform voor tours en activiteiten, neemt ongeveer 6% per boeking, bovenop de checkoutprijs van de klant, en zodra de kaartverwerking erbij komt zit het totaal rond 7 tot 9% van elke transactie. Peek Pro werkt op dezelfde manier. Bij klein volume is dit een prima deal. De software is feitelijk gratis tot je iets verkoopt.

Dan gaat de meter tellen. Een operator die $1 miljoen per jaar door een 6%-platform laat lopen betaalt $60,000 per jaar, voor altijd, en dat is toevallig elk jaar opnieuw een compleet bouwbudget. Dat is de eerste van de twee eerlijke redenen om te bouwen: de feerekensom slaat om. De tweede is fit. Elke gehuurde tool codeert één manier van werken, en als je voorraad, je regels of je lokale markt niet bij die vorm passen, breng je je leven door met vechten tegen de tool. Geldt geen van beide redenen voor jou, huur dan, en steek het verschil in marketing.

Drie builds die schuilgaan achter één term

Als mensen zeggen dat ze een boekingssysteem willen bouwen, bedoelen ze een van drie projecten, en de markttarieven voor die drie overlappen nauwelijks.

• Een boekings-MVP: één bedrijf, één type dienst, een betaalstap, geautomatiseerde herinneringen. Marktgidsen komen samen op $25,000 tot $60,000 en 8 tot 16 weken, en dat komt overeen met onze eigen schattingen.
• Een volledig boekingsproduct: meerdere medewerkers en resources, rollen en rechten, annuleringsvoorwaarden, aanbetalingen, een adminpaneel, een paar integraties. $80,000 tot $180,000.
• Een boekingsplatform: multi-property- of multi-vendorvoorraad, channel managers, OTA-koppelingen, de stack op hospitality-niveau. $120,000 tot $250,000 en stijgend.

Het platformniveau is waar integraties ophouden een voetnoot te zijn. Publieke calculators prijzen een channel manager-koppeling rond $4,800, een OTA-integratie rond $3,900, en GDS-connectiviteit rond $6,900, elk als eenmalige regelpost. Elk daarvan brengt zijn eigen authflow mee, zijn eigen faalmodi, en zijn eigen sandbox die zich net iets anders gedraagt dan productie. Integraties, niet schermen, zijn de reden dat builds op hotelniveau in de zes cijfers beginnen.

Alle drie de ranges gaan uit van de gemengde bureautarieven die we uitsplitsten in wat maatwerksoftware kost in 2026. Een Amerikaans bureau kan ze verdubbelen. Een freelancer kan ze halveren, en kan ook in week negen verdwijnen met de repo.

De kalender is het goedkope deel

De kalender-UI is het goedkoopste onderdeel op de factuur. Datepickers zijn een opgelost probleem. Waar je voor betaalt is alles eronder, te beginnen met het voorraadmodel, oftewel het precieze antwoord op "wat wordt er precies gereserveerd, en wanneer komt het weer vrij?" Een tijdslot bij één kapper is makkelijk. Een tafel voor vier van 19:00 tot 21:00 uur, waar dezelfde tafel om 21:15 een ander gezelschap ontvangt en de plattegrond op vrijdag verandert, is dat niet. Toen we LetsBar, een reserveringsplatform voor restaurants bouwden, was het niet een mooiere kalender die de dubbele boekingen halveerde. Het was voorraadlogica en concurrencycontrole. Dat twee obers op hetzelfde moment dezelfde tafel accepteren moet onmogelijk zijn, niet slechts onwaarschijnlijk.

De tweede helft van de rekening is concurrency, tijdzones en betalingen. Preventie van dubbele boekingen die standhoudt onder echte load. Zomertijdovergangen, die precies twee nachten per jaar bugs opleveren en daarna elk een week aan supporttickets. En betaalflows die veel verder gaan dan "een kaart belasten": aanbetalingen, gedeeltelijke refunds, no-showkosten, annuleringsvensters met per dienst andere regels. Dat laatste cluster verdient zijn kosten terug aan de omzetkant. Brancheonderzoeken zetten de no-showdaling door betalen bij het boeken op bijna 28%, en door geautomatiseerde herinneringen rond 29%. De features die een boekingssysteem duur maken zijn dezelfde features die het laten renderen.

Na de lancering, met één oog op de agents

De factuur is niet het einde van de uitgaven. Hosting voor een boekingsproduct is bescheiden, meestal enkele honderden dollars per maand voor de app, database, opslag, e-mail en monitoring. Onderhoud is de rekening die niemand in de spreadsheet zet: reken op 5 tot 10 procent van de bouwkosten per jaar om dependencies actueel en gepatcht te houden. Twee jaar updates overslaan bespaart je geen geld. Het verandert je product stilletjes in een rewrite.

Nog één 2026-specifieke noot. AI-agents zijn begonnen met boekingen maken namens mensen, en we schreven eerder dit jaar al over wat dat met planningsproducten doet. Het praktische gevolg voor een nieuwe build is goedkoop om op te acteren: zet de boekingslogica vanaf dag één achter een schone API en behandel je eigen website als gewoon nog een client daarvan. Dat is sowieso goede architectuur. Het betekent ook dat wanneer een agent aanklopt en naar je beschikbaarheid vraagt, de deur al bestaat.

Dus wat is het cijfer?

Een planningspagina: bouw hem niet, huur hem voor minder dan $100 per maand. Een boekings-MVP voor één bedrijf: $25,000 tot $60,000. Een serieus product met personeel, beleid en betalingen: $80,000 tot $180,000. Een multi-property-platform met channel managers: $120,000 tot $250,000 voordat je klaar bent. Tel er 5 tot 10 procent per jaar bij op om wat je ook bouwde in leven te houden.

Doe voor dat alles eerst de twee checks die het cijfer echt maken. Vermenigvuldig je jaarlijkse boekingsvolume met de commissie die een gehuurd platform zou nemen, want dat is het bouwbudget dat je al uitgeeft. Schrijf daarna de ene workflow op die de kant-en-klare tools niet kunnen. Blijft de pagina leeg, dan heb je nog geen maatwerksoftware nodig. Boekingssystemen belonen het saaie pad: huur tot het pijn doet, en bouw dan het kleinste ding dat de pijn stopt.