CalmLlama
A full-stack booking platform where customers discover wellness venues, reserve slots, and pay online - while owners manage bookings, availability, and refunds from one portal.
- Role
- Solo full-stack
- Scope
- Customer app + owner portal
- Payments
- Stripe + Apple Pay
- Status
- Live in production
The problem
Small wellness venues ran bookings by phone and notebook: no upfront payment (frequent no-shows), availability scattered across staff memory and paper diaries, no central record of bookings or refunds, and owners stuck on the phone instead of running the business.
The result
Designed and shipped end to end, solo, into production at calmllama.life: self-serve booking, payment-first checkout (Stripe + Apple Pay), and a single owner portal for bookings, availability, and refunds.
“I have worked with Yash, throughout two separate projects during which he was part of the ToraTech AI team. Yash has always shown tremendous initiative to get work done and work around problems. I was impressed with his back end skills, aswell as having a great eye for a UX and UI. I would recommend Yash to any company looking for efficient development.”
Role & ownership
Solo full-stack developer. Owned the customer app, the business owner portal, the Express API, the database schema, the Stripe payment integration, and deployment.
Core components
The platform is built around three pillars: the booking flow, the payment gateway, and the business portal.
Booking flow
The customer journey from discovery to a confirmed reservation.
- Browse and search venues, view services and live availability
- Select a slot and party size, enter details - guest checkout supported, no account required
- Choose to pay now or pay on arrival, then receive an automatic confirmation
Engineering highlights
- Idempotency guard: checks for an existing booking on the same venue + date + time + email before inserting, preventing duplicates on retries or double-clicks.
- Guest checkout: bookings work without an account, which required carefully scoped database policies so anonymous users can book without exposing other data.
- Decoupled confirmations: the confirmation webhook runs after the booking is saved - if it fails, the booking still succeeds.
Payment gateway (Stripe)
The revenue engine - secure card payments and owner-initiated refunds.
- Server-side Stripe Checkout sessions for PCI-safe hosted payment pages (EUR)
- Apple Pay for faster mobile checkout, alongside a pay-on-arrival option
- Refunds issued from the portal, returned via Stripe with the customer notified automatically
Engineering highlights
- Payment-first booking: creates the Stripe session, confirms payment_status server-side, then writes the booking - paid records are always backed by a real charge.
- Safe refund rules: refunds only run for Stripe-paid bookings with a stored payment_intent_id, and are blocked if already cancelled or refunded.
- Payment intent tracking: every charge's Stripe reference is stored on the booking, making refunds a direct lookup instead of a fragile search.
Business owner portal
The command center where venues run day-to-day operations.
- Bookings management: view, filter, cancel, and refund in one click
- Availability & calendar: weekly schedules, slot creation, and a timeline view
- Payments setup, gift vouchers, add-ons, and an AI customer chatbot
Engineering highlights
- Reliable writes under RLS: the server uses a Supabase service-role key for booking and refund operations, so critical writes succeed even with strict Row-Level Security protecting customer data.
- Real-time metrics: booking stats and calendar views give owners an at-a-glance picture of their day.
Architecture & approach
The frontend (customer app + owner portal) talks to a thin Express API that orchestrates Stripe and Supabase. All payment and booking logic lives server-side so secrets stay off the client and writes stay trustworthy. Supabase provides Postgres with Row-Level Security, Auth, and Edge Functions; n8n handles booking-confirmation webhooks out of band.
Technical challenges & decisions
- 1
Server-side service-role key for critical writes
Bookings were silently failing under Supabase Row-Level Security. Running booking and refund writes server-side with the service-role key guarantees they succeed, while RLS still locks down everything clients can read.
- 2
Idempotency check before every booking insert
Network retries and double-clicks were creating duplicate reservations. The API now checks for an existing booking on the same venue + date + time + email before inserting.
- 3
Payment-first booking
A booking should never exist without a real charge. The app creates the Stripe session, confirms payment_status server-side, then writes the booking - so every paid record is backed by an actual payment.
- 4
Guarded refunds
Refunds risked double-charges and orphaned records. They only run for Stripe-paid bookings with a stored payment_intent_id, and are blocked if a booking is already cancelled or refunded.
- 5
Decoupled confirmation webhook
Notification failures shouldn't break a booking. The n8n confirmation webhook runs after the booking is saved - if it fails, the booking still succeeds.
Tech stack & tools
- React 18
- TypeScript
- Vite
- Tailwind CSS
- shadcn/ui
- TanStack Query
- React Hook Form
- Zod
- Node.js
- Express
- Supabase
- PostgreSQL
- Stripe
- Apple Pay
- n8n
- Netlify
Have a product that needs building?
I help founders ship full-stack products - from the first architecture decision to production. Currently available for freelance work.