Booking & payments system
A studio ran its bookings by hand and lost slots to double-bookings and abandoned checkouts. Now guests book themselves — and the calendar can't lie.
- Role
- Sole developer, end to end
- Delivery
- Installable PWA, no login
- Operations
- Airtable as the staff backend
The problem
Bookings lived in a hand-run calendar. Two people could pay for the same slot, an abandoned checkout could block a slot nobody bought, and every mistake ended in a refund conversation.
A booking system earns its keep on one promise: the calendar never lies.
What I built
One system, four deliberate choices:
Real-time availability with expiring holds
A slot locks the moment checkout starts and releases itself automatically if payment doesn't complete — double-booking becomes structurally impossible, not procedurally discouraged.
Stripe payments
Payment happens inside the booking flow — a slot is confirmed exactly when the money is, never before.
Airtable as the operations backend
Staff manage rooms, prices and bookings in a tool they already knew — no admin panel to build, learn or maintain.
Guest self-service as an installable PWA
No account, no login, no app store — guests book from the browser and can pin it to their home screen.
The outcome
The failure modes it was built to kill are gone:
- Double-bookings: structurally impossible — the hold model prevents them, not a policy.
- Abandoned checkouts release their slots on their own.
- Staff run everything from Airtable — zero new tools to learn.
Stack
Next.js 16 and React 19 at the front, Stripe for the money, Airtable for operations. The interesting engineering is the hold-expiry model, not the stack.
Does this sound like your app?
Every engagement here started the same way: an app already live, and a problem someone decided to stop living with. The audit is the low-risk way to start — read-only access, a written report, a prioritized fix list.