Everything that’s in the platform today.
Four feature areas, each documented in detail. Every claim on these pages traces back to shipped code — nothing here is on a roadmap.
Customer booking experience
The 5-step funnel, mobile full-page takeover, deep linking, payment options, confirmation emails and SMS, customer self-service for cancel and reschedule, and the “Zero Dead Ends” UX principle that runs through every screen.
Read more →Operator admin backend
Products and pricing tiers, sessions and the bulk scheduler, bookings (manual create, modify, refund), gift cards, the merch shop, promo codes, holiday surcharges, waivers, resources, and operator-editable confirmation emails.
Read more →Embeddable booking widget
One <script> tag, iframe isolation, deep linking
via data-product, postMessage events for
analytics, opacity fade so there’s no white flash on load, and
graceful Stripe hand-off.
Per-tenant infrastructure
Each operator gets their own Postgres database, their own DB role,
their own domain, their own server slot, their own
.env.local. One-line deploy command and a drift
detector to catch config skew before customers do.
What we deliberately don’t do
It’s as important to be clear about what bookingapp doesn’t do as what it does.
- No marketing funnel dashboard. The admin has a
live operations dashboard (bookings, revenue, upcoming week), but
there’s no built-in conversion-rate or traffic-source
analytics — the widget emits
postMessageevents you plumb into Google Analytics, Plausible, or Fathom for that. - No multi-user RBAC. One admin login per tenant. Suited to owner-operators, not large teams with role-based access.
- No waitlist or “notify me”. Sold-out customers get the alternatives sheet instead, and a phone fallback.
- No marketplace. Customers find your business directly, not browse a directory of competitors.
- No multi-language. English only today.