What is the difference with Mews, Booking.com, Resengo or a comparable SaaS?
Mews, Apaleo, Cloudbeds (hospitality), Booking.com (marketplace), Resengo, TheFork (restaurants), Salonized, Treatwell, Eversports (beauty and fitness) and similar platforms are good at general mechanics. They reach their limits on four points. Firstly, industry- or format-specific logic: a hotel chain that wants to combine rooms and spa in one booking, or a fitness brand that links personal-trainer slots to childcare. Secondly, integrations with non-standard PMS, POS or CDP stacks where adapter work becomes expensive and fragile. Thirdly, commission and fee structures that make your best channel more expensive the better it performs. Fourthly, ownership of customer data: on a marketplace the guest remains their customer, not yours. We are also honest about when an off-the-shelf SaaS solution is enough: for a standard booking flow without exotic integrations, that can be a perfectly good first step.
Native or cross-platform: what do you recommend?
It depends on the mechanics and your internal capacity. For standard booking flows (slot selection, payment, reminders, loyalty), Flutter or React Native work very well and deliver simultaneous release on iOS and Android from a single codebase. For apps that rely heavily on hardware (Apple Wallet for passes, advanced push segmentation via OS features, NFC check-in at the counter, complex animations that carry the brand's feel), we increasingly choose native: Swift for iOS, Kotlin for Android. We advise case by case. We can deliver either route and do both well. For the web version of the app that you open in the browser (for example from a Google search result), we build a Progressive Web App that shares the same booking engine.
How do you handle PMS and till integration?
We integrate with all the common PMS and POS systems in the Benelux: Mews, Apaleo, Cloudbeds, Opera, Protel, RoomRaccoon and in-house PMS via our own middleware, plus the common POS systems (Lightspeed, Untill, Tally Pay, Toast, Storyous, Vectron, MplusKASSA, Square, Adyen POS stacks). The integration can work both ways: reading availability (real-time or via a cache with invalidation on change) and writing bookings (atomic, with retry logic on timeouts so that double bookings are ruled out). For industry-specific systems (Salonized, Treatwell, Mindbody, Eversports, Trainin, Resengo, Salonkee) we build the adapters so that migrating existing bookings doesn't have to be a big bang.
How do you handle payments, PSD2 and SCA?
Payments run through Mollie or Stripe as standard, and for larger volumes through a
dedicated payment platform. We comply with PSD2 and Strong Customer Authentication (SCA) through 3D Secure 2.0 for card transactions, a native flow for iDEAL and Bancontact, and a frictionless flow where the PSP supports it. For recurring payments (subscriptions, no-show fees, repeat deposits), we use mandates with the right SCA exemption. Refund flows are covered by automated tests, because a refund error damages a customer relationship faster than an ordinary booking error.
How do you arrange no-show fees so they stay customer-friendly?
No-show fees solve a real operational problem, but they weigh heavily on the customer relationship if they go wrong. We build in three mechanisms. First, a grace period with an automatic reminder in advance, so the customer can still cancel or reschedule. Second, a transparent policy within the booking flow: the terms are visible before the customer pays, not buried in general terms and conditions. Third, a reasonable appeal route so that staff can reverse a no-show fee if the customer raises it with a good reason. Customers experience a fair system, and you keep operational capacity under control.
How do you handle GDPR and customer data?
Booking data is inherently sensitive: names, contact details, payment details and, in healthcare, medical context too. We build a GDPR-compliant opt-in flow for marketing communications, a granular consent model (you can book without receiving personalised offers), retention policies for customer and transaction data, and a data vault structure in which sensitive attributes are kept separate from operational data. For healthcare practices we add NEN 7510 practices (encryption at rest, an audit log for every access, pseudonymisation where possible, role-based access under BIG registration). We include a DPIA as standard in broader CDP projects. ePrivacy also applies to push notifications, which require a separate consent step.
What about the EAA and WCAG accessibility?
From 28 June 2025, a booking app falls under the European Accessibility Act (EAA), which sets WCAG 2.1 level AA as the minimum. We build accessibly from the start: correct contrast ratios, visible focus states, screen-reader labels on interactive elements, stock selection that works with keyboard navigation, and a booking flow that does not rely on timeout buttons. For sector-specific requirements (healthcare, government) we go beyond AA where necessary. We carry out an accessibility audit at the end of the project and deliver an accessibility statement that you can publish on the site.
How do we prevent duplicate bookings for the same slot?
Double bookings almost always arise from a race condition: two customers book the exact same slot at the same moment for the last available place, and the back end accepts both. We solve this with atomic booking transactions on the database (Postgres advisory locks or row-level locking), combined with a queueing mechanism for peak moments such as a popular group class or a busy dinner slot. The booking engine guarantees that a slot can be taken at most once, regardless of how many customers press the "confirm" button at the same time. Automated tests cover these edge cases, so regressions cannot reach production.
What about gift cards and the Dutch Gift Card Act (Cadeaubonwet)?
If you issue gift cards for bookings — dinner vouchers, spa vouchers, escape room gifts, fitness passes — specific rules apply in the Netherlands regarding validity (a minimum of two years since 2023), information obligations, disclosure of the remaining balance, and the position on loss or expiry. We make sure the redemption flow complies with these requirements, and for larger programmes we explicitly involve a legal specialist — so there are no surprises later on in a first discussion with a regulator.
Does the app work offline?
For viewing confirmations, calendar entries and wallet passes, working offline is usually not critical, as the booking is made on the customer's side with internet access. For staff tools at the front desk or in a meeting room without coverage, we have built offline-friendly flows: the staff app caches booked slots locally, guests can be checked in without a connection, and changes sync as soon as the network is back. This matters especially in older buildings, basement locations or hospitality venues with thick walls where Wi-Fi is unreliable.
How do you measure whether the app works commercially?
We set up reporting on occupancy by location and resource, revenue per slot category, no-show percentage, conversion through the funnel (from app open to confirmation), customer lifetime value per segment, and commission savings if you migrate from a marketplace. For more mature programmes, we also build in A/B tests on price points, slot presentation and upsell flows, so you know not only whether the app works but also which variant performs best for which segment. Reporting goes to your BI tool if you already use one, or appears as a dashboard in the app's own admin.
Who owns the code, customer data and booking history?
You do. We deliver the complete source code, schemas, build pipelines and deployment scripts. The data resides in your cloud (GCP, AWS, Azure) or with a hosting provider of your choice. If you later want to continue with another agency, or take things over in-house, you can — there is no technical lock-in, no hidden API keys, and no subscription to something you no longer want. We earn our keep through good work that lasts, not by keeping clients locked in.
What determines the cost of a booking app?
The main cost drivers are the complexity of the booking mechanics (single-resource versus multi-resource with capacity and waitlists), the number of integrations (PMS, point of sale, calendar, CDP, marketing automation, ERP, finance), the degree of personalisation and revenue management (static prices versus a dynamic pricing engine), the number of locations and languages, and whether native or cross-platform is the right choice for your brand. In addition, sector-specific compliance requirements (healthcare, financial) play a role. We work in sprints with fixed sprint budgets, so you are not faced with surprises and can steer scope on a sprint-by-sprint basis.
How long before we can go live?
A first working version with slot selection, payment and confirmation can be live on TestFlight and in the Google Play internal track within a number of sprints. A full platform with multi-resource booking, waitlists, no-show fees, dynamic pricing, loyalty and multi-location integration takes several sprints. We often roll out in phases, so a single pilot location can start while we continue building. We feed that feedback in directly before the wider launch.