The availability engine
Weekly rules + date overrides + DST-correct slot generation. Portable to any appointment business — clinics, tutors, studios, trades.
Mystic Wellness
A wellness studio that used to book by text message now runs sessions, studio hire, workshops, a shop, gift cards and referrals through one system.
- Stack
- React 19 · tRPC · Hono · MySQL
- Deploy
- GitHub Actions → Docker VPS
- Money
- Stripe, live mode
- Surface
- 30+ routes, 2 domains
- Checks
- 19/19 automated production checks
- Languages
- English
01 The brief
Mystic Wellness is a one-room sound-healing studio in Petersham. Private sessions, studio hire, workshops, events, a small shop — all of it was run through direct messages and goodwill. Availability lived in one person’s head. Double bookings were a live risk. Payments happened on the day, or didn’t.
The brief was not “a website”. It was: make the whole operation legible to the customer and to the business — availability, booking, payment, confirmation, records, follow-up — without adding admin work at the end of it.
02 What was built
A business where the website is the least of the system.
- Marketing front door + 25-page booking application
- 4-step booking wizard with live availability
- Server-side pricing — the catalogue is the only source of truth
- Checkout with Stripe (Payment Element + hosted fallback)
- Webhook-verified payment confirmation
- Confirmation email + Google Calendar, sent only after verified payment
- Lifecycle emails: 24h-before reminder, 24h-after follow-up with referral code
- Admin console: bookings, enquiries, orders, stock, gift cards, CSV export
- Enquiry lanes for studio hire, events, collaborations
- Shop, gift cards and referral codes
- Events with capped seat allocations and stale-hold release
- Campaign attribution: UTM first-touch, GA4, QR codes that log scans
- Automated post-deploy verification of the live production site
03 The system
The website is the surface. This is the path underneath.
Step 1 — Visitor
Arrives via the front door, an event page, search, or a printed QR code that logs the scan.
04 Behind the screen
Backend decisions you'll never see, and always feel.
- 01
Double-booking is impossible at the database level
Every slot is a generated key with a unique index. Two people cannot hold the same time, even if they click at the same millisecond — the database refuses the second write.
- 02
Payments are confirmed, never assumed
Stripe webhooks are signature-verified with a tolerance window and logged to an idempotency journal. Replays and duplicates are acknowledged, then ignored. A failed payment never releases the slot by accident.
- 03
The price lives in one file
Services, durations and prices exist once, server-side. The UI reads them; it cannot invent them. Changing a price is a one-line change with everything else following.
- 04
Emails that can’t double-send
Lifecycle reminders claim a row before sending — if the process crashes mid-send, the next hour’s sweep picks up exactly where it left off.
- 05
Every deploy is verified against the real site
After each release, an automated check opens the production domain in a real browser and confirms 19 things: health, database, Stripe, email, calendar, no console errors, no mobile overflow, deployed code matches. A green build is not a deployment.
05 Project screenshots
Real screenshots, no mockups.
Live — booking and business system
Open live system book.mysticwellness.com.au
06 What became reusable
Your build can reuse patterns from this project.
Webhook-journal payment pattern
Verify, journal, act once. The same shape protects every money path I build.
Enquiry lifecycle stages
Leads don’t disappear into an inbox; they advance with the customer’s actual journey.
Deploy verification
The production site is checked by a real browser after every release — catching what CI can’t see.
· Next case study — 02
Phoenix Live — TRI ÂN
A one-night Vietnamese live show, sold as 26 premium tables at $700–$900, to a bilingual audience, with a floor plan that stays truthful as tables sell.