The five parts every booking app has to cover
Customers see a list of services and a time picker. Behind that sit five pieces of work, and each one has a simple version and a version that doubles its effort. Before asking anyone for a number, decide which version of each you need for launch.
| Part | Simple version | Version that raises the quote |
|---|---|---|
| Services | A fixed list with a duration and price each | Variants, add-ons, packages of sessions, services that need two staff or a room |
| Availability | One opening schedule, one calendar, fixed slot lengths | Per-staff schedules, buffers between bookings, shared resources, several locations or time zones |
| Deposits and payments | A fixed deposit taken by card at booking | Full prepayment, cancellation fees, partial refunds, gift cards, stored cards for no-show charges |
| Reminders | Push notification and email before the appointment | SMS, custom timing per service, follow-ups, rebooking prompts, reminders staff can edit |
| Staff admin | Owner sees and edits the day's bookings | Roles for owner, front desk and staff, blocked time, payouts, reports, customer notes |
If most of your answers fall in the middle column, you are describing a focused first version. Several answers in the right-hand column usually mean a larger build, or a sign that existing scheduling software may suit you better (more on that below).
A sample scope, line by line
This is an example scope written in October 2026 for a typical small salon. It is an example scope, not a customer project: one location, three stylists, about fifteen services, a fixed deposit at booking, push and email reminders, and an owner who wants to see the week at a glance. There is no existing booking system to migrate. When two quotes differ a lot, put them side by side against a list like this and you will usually find one includes the staff dashboard and the other assumes bookings are managed by hand.
| Item | What is included | What drives effort |
|---|---|---|
| Platforms | Customer app for iPhone and Android from one codebase, plus a web dashboard for staff | Two store builds to test and submit; the dashboard is a second front end |
| Customer screens | Welcome and sign-in, service list, service detail, choose stylist or first available, date and time picker, booking summary with deposit, confirmation, my bookings, reschedule or cancel, profile and notification settings (about 10-12 screens) | The time picker and reschedule flow, which must respect every availability rule |
| User roles | Customer, stylist (own schedule only), owner (everything) | Each role needs its own permissions and its own test cases |
| Booking rules | Per-stylist hours, 10-minute buffer after colour services, 24-hour cancellation window with deposit refund before it | Every rule adds edge cases to build and test |
| Integrations | Card processor for deposits and refunds, push notifications, transactional email, optional one-way export to the owner's calendar | Payment failure and refund paths; two-way calendar sync would add more |
| Admin | Web dashboard with day and week calendar, booking detail, block time off, edit services and prices, edit staff hours, customer list, deposit and refund log, reminder settings | Admin screens often match the customer screens in number |
| Component | What it covers here | What drives effort |
|---|---|---|
| Design | Screen designs for the customer app and the staff dashboard in your brand | Number of screens and how custom the visual style is |
| Build | Customer app, dashboard, server, database and the integrations above | Availability rules, deposits and roles |
| QA | Testing on iPhone and Android devices, plus booking, payment, cancellation and reminder scenarios | Number of rules and failure paths to check |
| Store deployment | Store listings, privacy answers and builds submitted under your developer accounts | Review feedback, which Apple and Google control |
| Contingency | A stated allowance for unknowns found during the build | How much is still undecided when the quote is written |
- Excluded: SMS reminders.
- Excluded: gift cards, packages of sessions and loyalty points.
- Excluded: multiple locations.
- Excluded: two-way sync with staff calendars.
- Excluded: migration of customers or bookings from another system.
- Excluded: ongoing maintenance after the bug-fix window, which is scoped separately.
The smaller option: the quote drops if the owner manages bookings from an admin view inside the app instead of a separate dashboard, if there is no deposit, or if the first release covers one stylist's calendar. If your bookings are simply a service, a person and a time, a scheduling subscription will usually cost less than any custom build, and we will say so. Custom booking app vs scheduling software walks through that comparison.
| Cost | Paid to | What to expect |
|---|---|---|
| Apple Developer Program | Apple, in your name | $99 a year |
| Google Play registration | Google, in your name | $25 once |
| Hosting and database | Your hosting provider | Usage based; grows slowly for a single business |
| Card processing on deposits | Your payment provider | A fee on each payment, set by the provider's published pricing |
| Email and push | Your email and notification providers | Usage based; check each provider's plan |
| Maintenance | Your developer | Operating system updates and fixes after the bug-fix window, quoted separately |
Sources: [S19]: Apple Developer, Enrollment (opens in a new tab)[S20]: Google Play Console Help, Get started with Play Console (opens in a new tab)
Why availability takes more work than the booking screen
Showing open slots means answering one question correctly every time: is this person, room or piece of equipment free for this long, starting now? The answer depends on opening hours, each staff member's shifts, holidays, service length, cleanup buffers and bookings already made. Once a calendar outside the app is involved, it also depends on events the app did not create.
- Where the truth lives: the app's own database, an external calendar, or both with a sync between them.
- How long a slot is held while the customer pays, and what happens when two people pick it at once.
- Whether customers choose a staff member or just a time, and how the app assigns staff when they do not choose.
- Shared resources such as a treatment room, a chair or a rental item that limit bookings across staff.
- Time zones and daylight saving changes for online sessions or multi-city businesses.
Each of these is a rule the app must follow and a set of test cases QA must run. Our booking integration checklist walks one appointment through the conflicts that show up most often.
Deposits, refunds and the app store payment rules
A deposit sounds like one button. In practice it means a payment account in your name, a checkout screen, a confirmation that only appears after the payment succeeds, refund rules for cancellations and a record your staff can look up. Charging a stored card for a late cancellation adds consent wording and another failure path.
Appointments are services delivered in the real world, and the stores treat them differently from digital content. Apple's App Review Guidelines (section 3.1.3(e)) say apps that sell physical goods or services consumed outside the app must use payment methods other than in-app purchase, such as Apple Pay or card entry. Google Play's Payments policy similarly lists physical services as outside its billing system. A haircut deposit therefore usually goes through a card processor. Selling a digital subscription inside the same app is a different case and generally has to use the stores' in-app purchase systems.
Sources: [S8]: Apple Developer, App Review (opens in a new tab)
Reminders and staff admin
Push notifications are cheap to send but only reach people who allowed them. Email reaches almost everyone and sometimes lands in spam. SMS gets read, and each message costs money through an SMS provider, so it belongs in your running costs as well as the build. Most businesses start with push plus email and add SMS when no-shows justify it.
Staff admin is often where scope grows quietly. A single owner can manage everything from a simple day view. A team with a front desk needs roles, so a stylist sees their own day while reception moves bookings for everyone. Reports, payout splits and customer notes are each their own screens. A web dashboard for staff is common, because people manage schedules more comfortably on a laptop than on a phone.
What moves a booking app quote up or down
| Driver | Keeps the quote smaller | Pushes the quote up |
|---|---|---|
| Locations | One | Several, with different hours and staff |
| Calendar sync | None, or one-way export | Two-way sync with staff calendars |
| Payments | Fixed deposit | Prepayment, no-show charges, split payouts |
| Roles | Owner and customer | Front desk, staff, managers, franchise owners |
| Platforms | Customer app plus simple web admin | Separate staff app, kiosk mode, website widget |
| Existing data | Starting fresh | Importing customers and future bookings |
Published agency estimates for booking apps vary widely because they describe very different products, from a single-salon app to a travel marketplace. Price comparisons only make sense against a written scope. The general drivers for any app, from backend to compliance, are covered in our guide to mobile app development cost.
Costs that continue after launch
The recurring costs table in the sample scope applies to most booking apps: store accounts in your name, hosting, card processing on deposits and maintenance. If you add text reminders, SMS fees per message join that list.
After full payment you receive the project files and the original assets made for the app. Third-party services keep their own licenses, and your developer, hosting and payment accounts stay in your name. If buying a scheduling subscription looks cheaper over a few years, read custom booking app vs scheduling software before you commit. The booking app page shows what a first version usually includes.
Sources: [S19]: Apple Developer, Enrollment (opens in a new tab)[S20]: Google Play Console Help, Get started with Play Console (opens in a new tab)
Frequently asked questions
What makes a booking app expensive?
Complex availability rules, two-way calendar sync, flexible payments and multi-role staff admin. The customer-facing booking screens are usually the smaller part of the work.
Why won't DFY Games give a fixed price for a booking app?
Booking apps range from one-salon tools to multi-location systems with payouts. We write a scope with assumptions first, so the quote matches what you actually need.
Can a booking app take deposits without Apple's in-app purchase?
Generally yes, because appointments are services delivered outside the app, and Apple's guidelines direct those to other payment methods such as card entry or Apple Pay. Check the current Apple and Google rules for your markets before launch.
Do I need a web dashboard as well as the app?
Most businesses with staff do, because managing schedules is easier on a laptop. A sole trader can often manage from an admin view inside the app.
What should I prepare before asking for a booking app quote?
Your service list with durations, staff and opening hours, your deposit and cancellation policy, and any calendars or systems the app must connect to.
Sources
- [S19] Apple Developer, Enrollment
- [S20] Google Play Console Help, Get started with Play Console
- [S8] Apple Developer, App Review
- Apple Developer, App Review Guidelines
- Google Play Console Help, Payments
Written and reviewed by the DFY Games team. Published ; facts checked . Prices and store rules change: check the linked sources before you rely on a figure.
