How to Build a Booking App in Next.js (2026)

How to Build a Booking App in Next.js in 2026

Calendly looks like a calendar with a button. The reality of building a production booking app is closer to a small SaaS: availability rules with timezone math, recurring schedules, blocking out conflicts, integrations with Google and Outlook calendars, a customer-facing booking page that doesn't break on mobile, an admin to manage everything, payment collection if you charge, automated reminders, and a fast way to cancel and reschedule without making customers angry. That's twelve to sixteen weeks of work for a competent team.

This guide walks through what a real booking app has to handle, the architecture decisions that bite you later, and the realistic path from zero to a production-ready Next.js scheduling app.

Or skip the build entirely: get every kit for $499

If you're shipping more than one product, All Access unlocks every Next.js kit on thefrontkit. A booking and scheduling kit is in development — join the waitlist below. Plus the SaaS Starter Kit, CRM, HR, Kanban, E-commerce, AI UX, Blog CMS, and 7 more. One-time payment, lifetime access, no subscription.

See All Access for $499 →

What a Real Next.js Booking App Has to Do

The features that distinguish a real scheduling product from a calendar with a save button.

Availability Rules Done Right

The hardest part of any booking app. Real availability is not "Monday 9am-5pm." It's:

Weekly schedules per service — different services may have different windows
Buffer time between appointments (15 minutes to clean up between massages, 30 minutes between consults)
Minimum notice — bookings must be at least N hours/days in the future
Maximum lead time — bookings can't be made more than N weeks out
Date overrides for holidays, conferences, time off
Recurring blocks like "no bookings on the second Tuesday of every month"
Capacity per slot for group bookings (a class with 8 spots, not 1)

Get this data model right on day one. Retrofitting availability rules into a flat-table schedule is a 6-week rebuild.

Calendar Integrations

Customers expect their booking to appear in their calendar. Hosts expect blocks on their calendar to prevent double-booking.

Google Calendar two-way sync — read busy times from the host's calendar, write new bookings as events
Outlook / Microsoft 365 calendar — same pattern, different OAuth and API
Apple iCloud / CalDAV — older protocol, less used but enterprise customers ask for it
ICS file download for customers without an account

Calendar integrations are usually 2-3 weeks of work alone. The OAuth flow, token refresh, and event sync logic are surprisingly intricate.

Customer Booking Page

The thing your customers see. Standards:

Service or appointment type selector with description, duration, and price
Calendar grid showing available days with available slots loading on selection
Mobile-optimized slot picker — the desktop grid doesn't translate; build a separate mobile UX
Timezone awareness — show the customer's local timezone, store everything in UTC
Quick form for name, email, and any custom questions per service
Payment collection at booking (optional) via Stripe Checkout
Confirmation page with calendar download links
Confirmation email with the meeting link, location, or instructions

This page is your conversion surface. Every second of friction loses bookings.

Admin Dashboard

Where the host manages bookings:

Day view showing today's appointments with customer info
Week and month calendar views
List view for filtering and bulk operations
Booking detail with cancel, reschedule, refund, and message-customer actions
Customer list with booking history per customer
Services management — create, edit, archive services with their availability rules
Schedule settings — weekly availability, buffers, date overrides
Notification settings — email and SMS templates for confirmation, reminder, cancellation
Integrations — connected calendars, payment provider, video conferencing

Admin functionality is half the build. Most early booking apps underbuild this and operators complain within a week.

Cancellation and Rescheduling

The single most-used feature after booking itself.

Cancel link in every confirmation email with a configurable refund policy (full refund up to N hours before, partial after, none within last X)
Reschedule flow that holds the original slot until the new one is confirmed
Host-initiated cancellation with automated email and refund
Cancellation reasons for analytics

The biggest mistake here is making customers email you to cancel. They won't. They'll just no-show.

Reminders and Notifications

Automated, scheduled emails and SMS:

Booking confirmation immediately
Reminder 24 hours before (configurable)
Reminder 1 hour before (configurable)
Follow-up after asking for review or rebooking
Failed payment if charge happens later
Reschedule and cancellation confirmations

SMS is typically 2-3x more effective than email for reminders. Use Twilio or MessageBird.

Payment Collection

Optional but expected:

Pay at booking via Stripe Checkout
Pay later with the option to send a payment link
Free bookings for consultations and discovery calls
Variable pricing per service (the kit must support it)
Tax handling (Stripe Tax for US-only, TaxJar or Avalara for international)
Refund flow tied to cancellation policy

For high-ticket services (legal, medical, coaching at $200+), pre-payment dramatically reduces no-shows.

Tech Stack: Booking-Specific Decisions

The general Next.js stack applies (Next 16, App Router, Tailwind v4, shadcn/ui). The booking-specific additions:

Date handling: Luxon or date-fns-tz. Timezone math is the most common source of booking bugs. Don't use native Date for anything calendar-related.

Calendar UI: FullCalendar handles week/day/month views with drag-and-drop. A custom month-view in React works for the customer-facing slot picker.

Calendar integrations: Google Calendar API via the official client. Microsoft Graph API for Outlook. Nylas or Cronofy as a unified API if you want one integration to cover both.

Payment: Stripe with mode: 'payment' for one-time bookings or mode: 'subscription' for recurring memberships.

Email: Resend with React Email for templates. Twilio for SMS reminders.

Background jobs: Inngest or Trigger.dev for scheduled reminders. Vercel Cron for the lightweight version.

Video conferencing: Zoom API or Daily.co for creating meeting links automatically.

Build Path 1: From Scratch (12 to 16 Weeks)

The realistic order:

Week 1-2: Foundation. Next.js, auth, multi-tenant database (services are per-host).

Week 3-4: Availability engine. The data model and the slot-calculation algorithm. Test extensively.

Week 5-6: Customer booking page. Service picker, calendar, slot selection, quick form, confirmation.

Week 7-8: Admin dashboard. Day/week/month views, booking detail, customer list, services management.

Week 9: Calendar integration. Pick one (Google) and ship it. Add Outlook later.

Week 10: Payments. Stripe wiring. Pre-payment flow. Refund handling.

Week 11: Notifications. Email templates, scheduled reminders.

Week 12-13: Cancellation, rescheduling, edge cases.

Week 14-15: Mobile polish. Customer booking flow specifically; mobile is most bookings.

Week 16: Deploy and beta.

For most teams: 16 to 22 weeks. Availability rules alone routinely take 4-6 weeks.

Build Path 2: From a Booking & Scheduling Kit (2 to 3 Weeks)

A production-ready Next.js booking kit ships:

Availability engine with weekly schedules, buffers, lead times, overrides, recurring blocks
Customer booking page with calendar, timezone-aware slots, mobile-optimized picker
Admin dashboard with day/week/month views, booking management, services, schedule settings
Calendar integration patterns (Google, Outlook)
Payment collection via Stripe (pre-pay and post-pay)
Notification templates (confirmation, reminder, cancellation, follow-up)
Cancellation and rescheduling flows
30-40 pages on Next.js 16, Tailwind v4, shadcn/ui

The work that remains:

Wire your auth provider
Connect your database
Add your actual services and pricing
Configure Google/Outlook OAuth credentials
Customize email and SMS templates with your brand

A booking and scheduling kit is in active development at thefrontkit — join the waitlist on our All Access page to be notified when it ships.

Common Pitfalls

Treating availability as a flat schedule. Real availability has buffers, lead times, overrides, recurring blocks, and per-service rules. A flat "Mon 9-5" model breaks within a week of real use.

Storing local times instead of UTC. Every booking should be stored in UTC, displayed in the user's local timezone. The opposite causes daylight-saving bugs that lose customers.

Building one calendar integration first, then "we'll add more later." Each integration is a 2-3 week project. Plan for the second one upfront so the abstraction supports it.

No reminder system. Customers forget. Without reminders, no-show rates exceed 20 percent. Build the reminder system before launch, not after the first complaints.

Cancel-by-email policy. Customers will not email to cancel. They'll just no-show. Build a self-serve cancellation flow with a clear policy on refunds.

Mobile calendar UX that's the same as desktop. A 7-column day grid doesn't work on a 375px screen. Build a dedicated mobile slot picker.

Ignoring timezone display. Showing "10am" without saying "Pacific Time" leads to missed appointments by customers in different timezones. Always show the timezone next to the time.

Adjacent Reads

How to Build a SaaS in Next.js — broader build path
Add Stripe Payments to a Next.js Template — for paid bookings
Connect Supabase to a Next.js Template — pair with database

FAQ

How long does it take to build a booking app in Next.js from scratch? A competent solo engineer builds a credible Next.js booking app in 12 to 16 weeks. Realistic timelines, including the availability engine, timezone math, calendar integrations, and payment collection, land closer to 16 to 22 weeks. The availability rules engine alone is routinely a 4-6 week project. A booking kit removes 14 of those weeks.

Should I use Calendly or build my own? Depends on your differentiation. Calendly ($12-20/user/month) handles 90 percent of scheduling needs out of the box. Build your own when: you need deeper customization than Calendly offers (custom intake forms, branded checkout, multi-step flows), you're integrating booking into a larger product (a marketplace, an LMS, a healthcare platform), or per-seat pricing doesn't fit your scale. For solo professionals doing simple bookings, Calendly is the right answer. For products where booking is part of the experience, build.

What's the hardest part of a booking app? The availability engine. It looks simple ("show available slots") but in production it has to handle weekly schedules, buffer time, lead time, max booking horizon, date overrides, recurring blocks, capacity per slot, timezone conversions, and conflict detection across multiple synced calendars. Get the data model right on day one or plan to rewrite it.

Do I need Google Calendar integration in v1? Yes, if your customers expect their bookings in their calendar. Almost everyone does. Skip it only for very narrow use cases like in-person appointments where the customer doesn't manage their own calendar. Plan 2-3 weeks for the integration including OAuth, sync, conflict handling, and token refresh.

How do I handle no-shows? Two layers. First: reminders (email and SMS) 24 hours and 1 hour before. Second: pre-payment for high-ticket bookings, which dramatically reduces no-shows. For lower-ticket services, a credit-card-on-file policy with a no-show fee discourages without requiring full pre-payment.

How many screens does a real booking app need? The minimum for a credible product is around 18 pages: customer booking flow (service picker, calendar, slot picker, form, confirmation), customer cancel/reschedule page, admin dashboard (day, week, month, list views), booking detail, customer list, services management, schedule settings, integrations settings, notification settings, and auth. A full-featured product with marketplace features (multiple hosts, public profiles) is 30-40 pages.