Why booking apps work as a first AI build

Booking is a predictable category. Users browse, tap a time, pay, get a confirmation. The happy path is known. The edge cases are where apps die.

If you build the happy path with AI help and then spend your time on the edge cases — timezone mismatches, cancellation windows, calendar sync — you will ship something real. Most AI-generated booking apps skip the edge cases and break the first time someone from a different timezone tries to book.

I have shipped this category twice. Here is what actually matters.

What you actually need to build

• List with filtering: Time slots, locations, staff or service. Keep filters minimal — date and category is enough for v1.
• Payment at booking time: Stripe is the right default. Reserve the slot on payment success, not before. Do not hold slots during checkout.
• Confirmation loop: Email + push + calendar attachment. Missed this on my first app. Had to ship v1.1 within a week to add it.
• Cancellation windows: Define the rule, show it on the booking screen, enforce it on the backend. Do not rely on the mobile app for enforcement.
• Provider side (if relevant): Simple inbox of upcoming bookings. You do not need a full admin panel in v1.

No AI-generated availability matching. No demand forecasting. Not in v1. The category rewards reliability.

The stack I use

• React Native + Expo — single codebase for iOS and Android.
• Supabase — Postgres with row-level security, realtime for booking conflicts.
• Stripe — payment plus automatic_tax.
• NestJS — the booking transaction runs server-side so the mobile client never races.
• Claude Code + 11 AI agents — scaffolds screens, wires the schema, drafts the App Store description.

All of this is preconfigured in Shippen.

Real build time

My first booking app was roughly 6 weekends solo. The second one, using the same boilerplate, was 2 weekends. The boilerplate is where you buy back time.

• Scaffolding + auth: ~6 hours (mostly gone once you have the boilerplate).
• Stripe + backend transaction: ~8 hours.
• Push + calendar attachment: ~5 hours.
• Edge cases (cancellation rules, timezones, double-booking guard): ~10 hours.
• App Store screenshots + submission: ~5 hours.

Realistic number for your second app in this category: 25–30 hours.

Where people get stuck

• Race conditions on slot booking: Two users tap the same slot at the same second. Without a server-side lock one gets a duplicate. Always do the booking transaction inside a Postgres function, not from the client.
• Timezones: Store slot times in UTC. Display them in the user local time. Never the other way around.
• Missing cancellation windows: Users cancel one minute before the slot and you lose the booking fee. Enforce the window on the backend, not the UI.

The boilerplate ships with a Supabase function for the booking transaction. You skip all three pitfalls above.

Skip the setup

Stripe, Supabase, NestJS, push, auth — pre-configured. The AI agents scaffold your list view and booking flow from a prompt.

See pricing