Bookings that don't double-book.
Scheduling, availability rules, deposits, reminders, no-show flows. Built against real calendar systems with real timezone math.
- Starting at
- $35k
- Structure
- Phase-by-phase quote, fixed bid
What you get for the work.
- 01
Timezone math that actually works
We store UTC, render in the user's zone, and test against DST transitions. The bug that loses three customers a year never ships.
- 02
Deposits via Stripe
Auth-hold or charge-now, with refund rules per service. The no-show flow is built, not bolted on.
- 03
Calendar sync
Google Calendar and iCal at the floor. Outlook on request. Two-way sync so the provider never double-books.
- 04
Owned by you
Code, Stripe account, calendar credentials, hosting. The booking flow is mission-critical, you should own all of it.
What we build it on.
- Nuxt or Next + Postgres
- With Luxon or date-fns-tz for timezone math.
- Stripe (or PaymentIntents)
- Deposits, no-show charges, refund rules.
- Google Calendar API / Microsoft Graph
- Two-way sync per provider.
- Twilio + Postmark
- Reminders and confirmations.
- Inngest
- Reminder scheduling, no-show enforcement.
$35k buys this. Bigger scope scales it.
Included at the floor
- Multi-resource availability model (staff, rooms, equipment)
- Customer-facing booking flow with calendar pick
- Stripe deposit collection (auth-hold or charge-now)
- Email and SMS reminders at 24h and 1h
- Google Calendar two-way sync for one provider
- Admin to see and override bookings
What scales the number
- Multi-location with location-specific rules
- Group bookings, packages, gift cards
- Loyalty or membership pricing tiers
- Customer mobile app (see Mobile)
- Inventory or class-pass mechanics
What a starter booking platform looks like
Multi-resource availability, customer booking flow, Stripe deposits, reminders, calendar sync, admin. Eight to twelve weeks. The booking and no-show flows both work end-to-end at launch.
Where the build scales
Multi-location is the most common scaler (location-specific availability, pricing, staff rules). Group bookings need their own data model. Class-pass and inventory mechanics add a usage layer on top of the booking core.
What we will not build
Booking platforms with no deposit flow (the no-show problem will eat you). Anything where the customer cannot see live availability.
Common questions.
- Why not Calendly or Acuity?
- They are great for simple cases. The moment you have multi-resource booking, custom pricing rules, deposits with tiered refunds, or branded checkout, the off-the-shelf tools start to leak. We rebuild from them often.
- How long until launch?
- Eight to twelve weeks at the $35k floor. The hard work is rules, not screens.
- What about timezone bugs?
- We test DST transitions and edge cases as part of QA. Storing UTC and rendering in the user's zone is the discipline. We do not get this wrong.
- Can it text customers reminders?
- Yes, via Twilio. 24-hour and 1-hour reminders by default. Configurable per service.
Pair this build with.
Build this with us.
Twenty minutes through the intake. A real reply within a work day.