Wat is het verschil met Mews, Booking.com, Resengo of een vergelijkbare SaaS?
Mews, Apaleo, Cloudbeds (hospitality), Booking.com (marketplace), Resengo, TheFork (restaurants), Salonized, Treatwell, Eversports (beauty / fitness) en vergelijkbare platforms zijn goed in algemene mechanieken. Ze raken hun grenzen op vier punten. Ten eerste branche- of formule-specifieke logica: een hotel-keten die kamers en spa wil combineren in één boeking, een fitness-formule die personal-trainer-slots koppelt aan kinderopvang. Ten tweede integraties met afwijkende PMS-, kassa- of CDP-stacks waar adapter-werk duur en fragiel wordt. Ten derde commissie- en fee-structuren die je beste kanaal duurder maken naarmate hij beter werkt. Ten vierde eigenaarschap over klantdata: op een marketplace blijft de gast hun klant, niet die van jou. We zeggen overigens eerlijk wanneer een SaaS-oplossing volstaat: bij een standaard boekings-flow zonder exotische integraties kan dat een prima eerste stap zijn.
Native of cross-platform — wat raden jullie aan?
Het hangt af van de mechaniek en je interne capaciteit. Voor standaard boekings-flows (slot-keuze, betaling, reminders, loyalty) werkt Flutter of React Native uitstekend en levert gelijktijdige release op iOS en Android op met één codebase. Voor apps waar je veel met hardware doet (Apple Wallet voor passes, geavanceerde push-segmentatie via OS-features, NFC-check-in aan de balie, complexe animaties die merkgevoel dragen) kiezen we steeds vaker native: Swift voor iOS, Kotlin voor Android. We adviseren per case. Beide kanten kunnen we leveren en allebei goed. Voor de webversie van de app die je in de browser opent (bijvoorbeeld vanuit een Google-zoekresultaat) bouwen we een Progressive Web App die dezelfde boekings-engine deelt.
Hoe regelen jullie PMS- en kassa-integratie?
We koppelen aan alle gangbare PMS- en kassasystemen in de Benelux: Mews, Apaleo, Cloudbeds, Opera, Protel, RoomRaccoon en eigen PMS via een eigen middleware, plus de gangbare kassa's (Lightspeed, Untill, Tally Pay, Toast, Storyous, Vectron, MplusKASSA, Square, Adyen-kassa-stacks). De integratie kan twee kanten op: beschikbaarheid uitlezen (real-time of via cache met invalidation bij wijziging) en boeking inschieten (atomic, met retry-logica bij timeouts zodat een dubbele boeking uitgesloten is). Voor branchespecifieke systemen (Salonized, Treatwell, Mindbody, Eversports, Trainin, Resengo, Salonkee) bouwen we de adapters zodat een migratie van bestaande boekingen niet als big-bang hoeft te lopen.
Hoe gaan jullie om met betalingen, PSD2 en SCA?
Betalingen lopen standaard via Mollie of Stripe, voor grotere volumes via een
eigen payment-platform. We voldoen aan PSD2 en Strong Customer Authentication (SCA) door 3D Secure 2.0 voor kaart-transacties, native-flow voor iDEAL en Bancontact, en frictionless-flow waar de PSP dat ondersteunt. Voor recurring (abonnementen, no-show fees, herhaal-deposits) gebruiken we mandaten met de juiste SCA-exemptie. Refund-flows zijn opgenomen in automated tests, omdat een fout in een refund een klantrelatie sneller stuk maakt dan een normale boeking-fout.
Hoe regelen jullie no-show fees zodat ze klantvriendelijk blijven?
No-show fees lossen een echt operationeel probleem op maar zijn een aanslag op de klantrelatie als ze fout uitpakken. We bouwen drie mechanieken in. Ten eerste een grace-period met automatische herinnering vooraf zodat de klant nog kan annuleren of verzetten. Ten tweede een transparante policy in de boeking-flow: voorwaarden zijn zichtbaar voordat de klant betaalt, niet verstopt in algemene voorwaarden. Ten derde een redelijk reclamatie-pad zodat staff een no-show fee kan terugdraaien als de klant met een goede reden aanklopt. Klanten ervaren een fair systeem en jij houdt operationele bezetting onder controle.
Hoe gaan jullie om met AVG en klantdata?
Boekings-data is per definitie gevoelig: namen, contactgegevens, betaalgegevens, in de gezondheidszorg ook medische context. We bouwen een AVG-houdbare opt-in-flow voor marketing-communicatie, een granulair consent-model (je kunt boeken zonder gepersonaliseerde aanbiedingen te krijgen), retention-policies voor klant- en transactiedata, en een data-vault-opzet waarin gevoelige attributen apart staan van operationele data. Voor zorg-praktijken voegen we NEN 7510-praktijken toe (encryptie at-rest, audit-log per inzage, pseudonimisering waar dat kan, BIG-rolgebaseerde toegang). DPIA doen we standaard mee bij bredere CDP-projecten. ePrivacy speelt mee voor push-notificaties — die hebben een aparte consent-stap.
Wat met EAA en WCAG-accessibility?
Vanaf 28 juni 2025 valt een boekings-app onder de Europese Toegankelijkheidswet (EAA), die WCAG 2.1 niveau AA als minimum stelt. We bouwen vanaf de start toegankelijk: contrast-ratios die kloppen, focus-states die zichtbaar zijn, screen-reader-labels op interactieve elementen, voorraad-keuze die met toetsenbord-navigatie werkt, en een boekings-flow die niet op time-out-knoppen leunt. Voor branchespecifieke vereisten (zorg, overheid) gaan we verder dan AA waar nodig. We doen een toegankelijkheidsaudit aan het eind van het traject en leveren een toegankelijkheidsverklaring die je op de site kunt publiceren.
Hoe voorkomen we dubbele boekingen op hetzelfde slot?
Dubbele boekingen ontstaan vrijwel altijd door een race-condition: twee klanten boeken op exact hetzelfde moment voor het laatste vrije slot, en de back-end accepteert beide. Wij lossen dit op met atomic boekings-transacties op de database (Postgres advisory locks of row-level locking), in combinatie met een queue-mechaniek voor piek-momenten zoals een gewilde groep-class of een populaire dinertijd. De boekings-engine garandeert dat één slot maximaal één keer kan worden ingenomen, ongeacht hoeveel klanten gelijktijdig de "bevestig"-knop drukken. Automated tests dekken deze edge-cases af zodat regressies onmogelijk in productie komen.
Wat met cadeaubonnen en de Cadeaubonwet?
Als je cadeaubonnen uitgeeft voor boekingen — diner-bonnen, spa-vouchers, escape-room-cadeaus, fitness-strippen — gelden in Nederland specifieke regels rond geldigheid (minimaal twee jaar sinds 2023), informatie-plicht, vermelding van resterende waarde en de positie bij verlies of vervaldatum. Wij zorgen dat de redemption-flow daaraan voldoet, en bij grotere programma's beleggen we de juridische check expliciet met een specialist — geen verrassingen achteraf bij een eerste discussie met een toezichthouder.
Werkt de app offline?
Voor het bekijken van bevestigingen, kalender-items en wallet-passes is offline-werken doorgaans niet kritiek — de boeking ontstaat aan de kant van de klant met internet. Voor staff-tooling aan de balie of in een vergaderzaal zonder dekking hebben we wel offline-vriendelijke flows gebouwd: de staff-app cached geboekte slots lokaal, gasten kunnen worden ingecheckt zonder verbinding, en wijzigingen synchroniseren zodra er weer netwerk is. Belangrijk in oude panden, kelder-locaties of horeca-gebouwen met dikke muren waar wifi haperend werkt.
Hoe meten jullie of de app commercieel werkt?
We installeren reporting op bezetting per locatie en resource, omzet per slot-categorie, no-show-percentage, conversie door de funnel (van app-open naar bevestiging), klant-LTV per segment en commissie-besparing als je migreert vanuit een marketplace. Voor de wat volwassener programma's bouwen we ook A/B-tests in op prijspunten, slot-presentatie en upsell-flows, zodat je niet alleen weet of de app werkt maar ook welke variant het beste presteert voor welk segment. Reporting gaat naar je BI-tool als jullie die al gebruiken, of staat als dashboard in de admin van de app zelf.
Wie is eigenaar van de code, klantdata en boekings-historie?
Jij. We leveren de volledige source code, schema's, build-pipelines en deploy-scripts op. De data leeft in jouw cloud (GCP, AWS, Azure) of bij een hosting-partij naar jouw keuze. Als je later met een ander bureau verder wilt, of intern wilt overnemen, kan dat — geen lock-in op techniek, geen verborgen API-sleutels, geen abonnement op iets dat je niet meer wilt. Wij verdienen aan goed werk dat blijft, niet aan klanten die vastzitten.
Wat bepaalt de kosten van een boekings-app?
De grootste kostendrijvers zijn de complexiteit van de boekings-mechaniek (single-resource versus multi-resource met capaciteit en waitlist), het aantal integraties (PMS, kassa, kalender, CDP, marketing-automation, ERP, finance), de mate van personalisatie en revenue-management (statische prijzen versus dynamische prijs-engine), het aantal locaties en talen, en of native of cross-platform de juiste keuze is voor je merk. Daarnaast spelen branchespecifieke compliance-eisen (zorg, financieel) een rol. We werken in sprints met vaste sprintbudgetten, zodat je niet voor een verrassing komt te staan en per sprint kunt sturen op scope.
Hoe lang voor we live kunnen?
Een eerste werkende versie met slot-keuze, betaling en bevestiging kan binnen een aantal sprints op TestFlight en Google Play interne track staan. Voor een volledig platform met multi-resource, waitlist, no-show fees, dynamische prijzen, loyalty en multi-location-koppeling rekenen we een traject van meerdere sprints. We rollen vaak gefaseerd uit zodat één pilot-locatie al kan starten terwijl wij doorbouwen — die feedback verwerken we direct voor de bredere lancering.
