A service menu is a price list that also sets your day, because every row is a block of time.

What actually belongs on a service menu row?

Nine columns cover almost every trade. An id you generate rather than the name, because names get rewritten. A display name and a short description for the booking screen. A planned length in minutes. A turnaround in minutes, meaning the time after the appointment that belongs to you and is not for sale. A price. A flag for whether the service is bookable on its own or only as an add-on. A category, so a long menu can be grouped on screen. An active flag. And a sort order, because owners care about the order of their menu far more than any developer expects them to.

Two of those are worth arguing about before you write the schema. The active flag is not a nicety: the moment a booking references a service you can never delete that row without orphaning history, so retiring a service has to mean hiding it from the menu while leaving it readable. Teams that skip this discover it when an owner tidies up the menu in January and last year's takings stop adding up. The add-on flag earns its place differently. It is what stops someone booking a fifteen minute beard trim as a standalone slot that wrecks the shape of the afternoon. An add-on carries its own length and is added to a parent booking, which is the reason the booking stores its own total rather than reading the menu back at display time.

Then the column most menus are missing. Length is not a property of the service alone, it is a property of the service and the person doing it. A senior stylist does the cut in forty minutes that a new joiner needs an hour for, and an app that insists both take fifty is an app the staff work around. The fix is small. Keep the default length on the service, then put a nullable length on the row that joins a staff member to a service, and have availability read the override when one exists. Price usually varies along the same line, so that join row ends up holding both and you avoid duplicating the whole service per person.

A menu built this way is most of an appointment calendar app already. The slot generator needs four inputs and no more: the day, the staff member, the hours that person is working, and a length. It walks the working window in steps, drops any step that collides with an existing booking or a break, and returns what is left. Every hard part of that is in the length, which is why the menu is the right place to start and the booking screen is the wrong one.

How does a calendar store an appointment that is forty minutes long?

As a start and an end, and nothing else. The Google Calendar API events reference, read on 14 October 2026, gives an event a start object and an end object. Each holds either a date, for an all day event, or a dateTime for a timed one, plus an optional timeZone. There is no duration field anywhere in the resource. The reference calls the start inclusive and the end exclusive, and that one word is what makes back-to-back bookings behave: an appointment that ends at ten and one that starts at ten do not overlap, so you do not need a second of padding to keep them apart.

Three more field level facts save a rewrite later. A dateTime needs a time zone offset unless a zone is given separately in timeZone, so a bare local timestamp is not a valid value. For a recurring event the timeZone is required, and it is the zone the recurrence is expanded in, which is how a six o'clock weekly slot stays at six through a clock change instead of drifting to five. And the recurrence field takes RRULE, RDATE, EXRULE and EXDATE lines, but the reference states that DTSTART and DTEND lines are not allowed in it. A repeating service slot therefore takes its length from the master event's start and end, not from the rule, which is another reason the length has to be stored somewhere you control.

Two fields decide whether the event you write is any use to the person whose calendar it lands in. The transparency field defaults to opaque, and its other value, transparent, means the event does not block time on the calendar, which is the opposite of what a booking needs. And you are allowed to set the event id yourself: lowercase letters a to v and the digits 0 to 9, between 5 and 1024 characters, unique within the calendar. Deriving it from your own booking id makes the write idempotent, so a retry updates the event instead of creating a second copy of the same appointment. If you are about to add calendar sync, that single decision prevents most of the duplicate events people end up apologising for.

Your service id has nowhere obvious to go on a calendar event, and the answer is extendedProperties. The reference describes extendedProperties.private as properties private to the copy of the event that appears on this calendar, and extendedProperties.shared as properties shared between copies of the event on other attendees' calendars. Put the booking id and the service id in private. It gives you a way to find your own events again without matching on the title, which is what people do instead and then regret the first time an owner edits a title by hand. The status field is worth reading at the same time, because cancelled covers both a deleted event and a cancelled occurrence of a repeating one, and a booking app has to tell those apart.

Google Calendar API, Events resource reference, read 14 October 2026

Where does buffer time actually go?

Nowhere in the API, which is the answer that surprises people. The events reference has no buffer field, no gap field and no travel time field. The nearest things in the resource are the autoDeclineMode settings on focus time and out of office events, and those decide whether a conflicting invitation gets declined, not how far apart two appointments sit. Google Calendar as a product plainly believes in the idea: an appointment schedule has a setting called Buffer time, under Booked appointment settings, alongside Appointment duration and Maximum bookings per day, checked on 14 October 2026. The feature exists and the API field does not, so in your own app the gap is yours to build.

There are two honest ways to build it. Pad the event, so a forty minute treatment with a ten minute turnaround is written as a fifty minute block and everything downstream just works. Or keep the turnaround in its own column and subtract it inside the availability query. Padding is a few lines of code and it moves a small lie into the owner's calendar: the ten o'clock massage looks like it runs until eleven when the customer actually leaves at ten to. That lie is harmless until someone reads the calendar to answer the phone, or until you try to report on paid minutes. The separate column keeps both truths and costs you a query that has to know about it. Pick one deliberately and write down which, because a codebase with half of each produces gaps nobody can account for.

Before you choose the column, decide who owns the gap, because it is not always the service. A treatment room needs airing and a fresh couch cover whatever was done in it, so the gap belongs to the room and applies to every service booked into it. A mobile service needs travel, which belongs to the pair of consecutive bookings rather than to either one of them, and changes with every day's route. A barber's five minutes of sweeping belongs to the service. Put the number on whichever of those three actually causes it, and the rule stays true when the menu changes. Put it on the service when the room caused it, and you will be editing twenty rows the day you move premises.

Then the case that defeats a single duration altogether. A colour appointment is apply, then develop, then finish, and during the develop stage the stylist is free. Sold as one unbroken two and a half hour block it costs you an hour of sellable time on every booking, which in a two chair salon is most of the week. The model that works is a stage list: each stage has a length and a flag for whether staff are held during it, the booking writes one calendar event per held stage, and the slot generator is allowed to place another short service inside the gap. Trades with a processing step all have this shape, and it is the main reason an off the shelf fifteen minute grid never fits them.

How do you take money for something on the menu?

On a card, and that is an instruction rather than a concession. App Review Guideline 3.1.3(e), Goods and Services Outside of the App, read on 14 October 2026, says that if your app enables people to purchase physical goods or services that will be consumed outside of the app, you must use purchase methods other than in-app purchase to collect those payments, such as Apple Pay or traditional credit card entry. People get this backwards and describe a haircut as exempt from in-app purchase. It is not exempt, it is forbidden from it. Build the deposit or the balance on a card processor and the rule is satisfied. Wire it to Apple's billing because that felt safer and you have built the thing that gets rejected.

Group sessions are where a service menu stops being one case. Guideline 3.1.3(d), Person-to-Person Services, says that if your app enables the purchase of real-time person-to-person services between two individuals, naming tutoring, medical consultations, real estate tours and fitness training, you may use purchase methods other than in-app purchase, and then it says one-to-few and one-to-many real-time services must use in-app purchase. So the single appointment on your menu and the group class two rows below it do not automatically share an answer. Read both guidelines against your own services before you build one checkout for the whole menu, and if you are genuinely unsure which one covers a class, ask App Review rather than guessing, because the two sentences point in opposite directions for a class people attend in a room.

The line that decides it is usually where the thing is consumed. Guideline 3.1.1 says that if you want to unlock features or functionality within your app, giving subscriptions, in-game currencies, game levels, access to premium content and unlocking a full version as the examples, you must use in-app purchase, and that apps may not use their own mechanisms to unlock content or functionality. A class streamed inside your app is content unlocked within the app. The same class in a studio is a service consumed outside it. One menu can hold both, and when it does the payment path forks even though the two rows look identical on screen.

One practical consequence for the menu itself. Because the money for in-person work does not run through store billing, the price on a menu row is just a number in your database, with no product id, no review queue and no store approval between you and changing it. That is a real advantage of a service business app and it cuts the other way too: nothing validates your prices, nothing stops a tax rate going stale, and refunds are entirely your problem. Keep the price on the booking as well as on the menu, for the same reason you keep the length there.

Apple, App Store Review Guidelines, guidelines 3.1.1, 3.1.3(d), 3.1.3(e) and 4.2.6, read 14 October 2026