Planning a scheduling feature that holds up in production
Booking looks simple until the edge cases show up
Most teams scope booking as a calendar, a list of open slots and a confirm button. Then the interviews start. A color appointment blocks a stylist for two and a half hours but leaves a gap while the dye sets. A client wants the same barber every four weeks. The front desk squeezes walk-ins between appointments and needs to override the rules the app enforces.
That is why this template spends its first two weeks on discovery and definition, before anyone draws a screen. Interviews with clients and front desk staff come first, then the business rules for hours, services and professionals, then flows and wireframes. A rule discovered during the beta costs days of rework in the data model. The same rule found in an interview costs a line in a document.
The same plan works for a dental office, a physiotherapy practice, a fitness studio or a SaaS product that books demos. The phases stay the same. What changes is which rules dominate and which integrations sit on the critical path.
Time zones, calendars and other things to settle in week one
A handful of decisions shape the data model and the API. Leaving them for later usually means rewriting the availability logic halfway through the build.
- Store every appointment in UTC with the location's IANA time zone, such as America/Chicago or Europe/London, and render in local time.
- Test the daylight saving switches: the second Sunday of March and first Sunday of November in the US, the last Sundays of March and October in the UK.
- Decide whether staff calendars sync two ways with Google Calendar and Outlook, and plan for Google's OAuth app verification, which can take weeks.
- Set buffers between appointments, a minimum notice period and how far ahead clients can book.
- Write the cancellation and no-show policy, including whether a card deposit is taken at booking.
- For SMS reminders in the US, budget time for A2P 10DLC registration and collect explicit consent.
The 27 days, track by track
Once the business rules are agreed, work splits into two tracks of nine business days each. Design takes flows and wireframes into the booking screens UI. Engineering models the data for calendar, slots and services and builds the availability and reservations API. Both tracks land on the client screens in the app, so a slip on either side moves the launch.
Notifications and automatic reminders and the professional's day view only need the API. They carry a little float, roughly two days for reminders and one for the day view, before they start to delay the beta. Testing and the beta with a pilot salon run for five business days once reminders, client screens and the day view are all done. The feature launch is a zero-length milestone at the end.
In Great Gantt those dependencies are already wired. Push the API out by three days and the client screens, beta and launch all move, while the critical path highlight shows the day view has lost its float.
Where teams build this
The template is written around a salon app, but scheduling features show up in very different products. A few common versions and what each one adds:
- Salon or barbershop app: staff choice, service length, deposit for long color sessions.
- Dental or therapy practice: HIPAA safeguards, intake forms, insurance details captured before the visit.
- B2B SaaS demo booking: round-robin across sales reps, routing by region, CRM handoff after booking.
- Fitness or yoga studio: class capacity, waitlists and package credits instead of one-to-one slots.
- Home services: arrival windows rather than exact times, plus travel time between jobs.
Rolling it out behind a feature flag
Shipping booking to every customer on the same morning is risky. A gentler path is the pilot salon from the template, then 10 percent of accounts behind a feature flag, then a wider rollout once the numbers look healthy. The flag doubles as a kill switch. If something breaks, booking falls back to phone and front desk without losing existing reservations.
Agree on the metrics before the beta starts. Booking completion rate, no-show rate before and after reminders, double bookings caught in logs and support tickets per hundred bookings are enough to decide whether to widen the rollout or fix first.