The first version of a booking app has to do five things well: show real availability, take a booking in a few steps, send a confirmation and a reminder, let customers cancel or reschedule on their own, and give you a clear list for the day. Memberships, loyalty points and reports can wait for version two. If the first five work, people will use it.
The five must-haves
- Real availability. Opening hours, breaks, time off, the length of each service and the gap between appointments, for every staff member or resource (a chair, a room, a test vehicle). If the app shows open slots that aren't really open, people go back to phoning after the first double booking.
- Booking in a few steps. Service, staff member (or "whoever is free"), time, then name and phone number. No account required for a first booking.
- Confirmation and reminder. Right after booking, a message with the day, time, address and how to cancel. Before the appointment, a reminder. Attach a calendar file in the standard iCalendar format so the booking lands in the phone's calendar with one tap.
- Customers cancel and reschedule themselves. With a cutoff you set, for example up to a day before. A customer who can move their own appointment has one less reason to simply not show up.
- A daily list for you and your team. Who's coming, when and for what. Plus a quick way to block a slot for a phone booking or a walk-in.
That's version one. It sounds like little, but each of the five has details that take time: time zones, the switch to daylight saving time, two customers tapping the same slot in the same second.
Notifications: don't rely on push alone
On phones running Android 13 or later, a newly installed app has notifications off by default. It has to ask for permission, and people can say no. Android's documentation recommends asking in context, after something the user does, not the first time the app opens.
For a booking app, the natural moment is right after the first booking: "Want a reminder the day before?" Even then, some people will decline. That's why the important reminder also goes out by text or email, not only as a push notification. We covered when notifications help and when they annoy in our article on push notifications.
An app or a booking page?
For many businesses, version one can be a booking web page, linked from your Google profile and Instagram. Customers don't install anything, and you find out quickly whether people actually book online. An installed app makes sense when customers come back often, say to a salon or a gym, and you want to show them their history, membership or offers.
We compared the two options in our article on web apps versus store apps, and how to decide what goes into a first version in our piece on MVPs.
Deposits: only if you need them
If no-shows are a real problem for you, you can ask for a card deposit at booking. In the EU, electronic payments require strong customer authentication (the Payment Services Directive, PSD2, Article 97): the customer confirms the payment in their banking app or with a code. The payment processor handles the technical side. Your part is making sure that after this step the customer lands reliably on the booking confirmation, not on a blank page.
If no-shows aren't an issue, leave deposits for later. An extra payment step can make some people give up halfway.
Personal data: ask only for what you use
A booking usually needs a name and phone number, maybe an email for the confirmation. GDPR requires data to be limited to what the purpose needs and kept only as long as necessary. No national ID number, no date of birth, no home address unless you actually use them for something.
There's one more question for day one: who on the team sees what. The front desk sees all bookings, a staff member only their own, a customer only theirs. We wrote about this in our article on app roles.
What can wait for version two
- memberships and session packages;
- loyalty points and automatic discounts;
- automatic review requests after a visit;
- detailed reports;
- integration with your invoicing software;
- multiple locations with different schedules.
What drives the cost: how many staff and resources you have, how many services, web page or store app, online payment and reminder channels. See how we work on our App Dev services page.
Sources
- Notification runtime permission, Android Developersthe POST_NOTIFICATIONS permission in Android 13, notifications off by default on install, asking in context
- RFC 5545, Internet Calendaring and Scheduling Core Object Specification (iCalendar)the standard format for calendar events, independent of any calendar service
- Directive (EU) 2015/2366 on payment services (PSD2), EUR-LexArticle 97: strong customer authentication for electronic payments
- Regulation (EU) 2016/679 (GDPR), EUR-LexArticle 5: data minimization and storage limitation
Checked: surse Xenia Pușcașu · editare Nora Vlăsceanu · SEO Mihnea Tăbăcaru






