A WhatsApp-native management system for pilates, physio and yoga studios.
Users & job-to-be-done
Owners and front desk of pilates studios, physiotherapy clinics and yoga centers in Türkiye who run bookings, packages and member follow-up out of WhatsApp and spreadsheets today.
Problem
Studios live in WhatsApp: members book, cancel and ask about packages there. Staff answer by hand between sessions, cancelled slots go empty, expired packages go unnoticed, and clinical notes sit next to marketing chats.
Insight
The studio's interface should be a web panel, but the member's interface should stay WhatsApp. Nobody downloads a studio app, so meet members where they already write, and keep clinical data structurally out of reach of the chat channel and the AI.
Bet
Ship a multi-tenant studio system (calendar, bookings, membership credit ledger, task queue) with a WhatsApp assistant that answers only from the studio's own knowledge base and hands off to staff when it should not answer.
My role
Solo builder: positioning, product spec, ADRs, Go backend, Next.js studio app, WhatsApp integration and the sales landing. AI accelerates implementation and review; scope, data-boundary and pricing decisions stay with me.
Journey
- Discover: sales call from the landing page; the account is opened by Umay, no self-serve signup
- Set up: studio identity, rooms, class types, packages and opening hours in a guided wizard
- Run: calendar, bookings, check-in, credit ledger and a task queue for the front desk
- Retain: WhatsApp reminders in the member’s local time, waitlist offers on cancellation, expiring-package follow-up
Architecture
- Multi-tenant Postgres with forced row-level security, isolation tests and DB-role walls around clinical data.
- Fenced WhatsApp AI agent: code-level guardrails before and after the LLM, credit quotas, a per-turn audit log.
- Swappable LLM layer (Anthropic, OpenAI-compatible, fake) with eval-corpus baselines that fail on regressions.
Tradeoffs
- No member app and no member web surface: WhatsApp is the member UI.
- No member payment collection; payments are recorded manually and reminders carry no payment link.
- Clinical notes and treatment plans never enter the assistant’s context, a fixed rule rather than a setting.
- Assistant answers only from the studio’s knowledge base; if it does not know, it says so and hands off.
- Double-booking prevented in the database, not just in application code.
Validation
- Dogfooded the full studio path against a seeded studio: bookings, packages, check-in, payroll and member 360.
- Row-level security, forced RLS and explicit grants on every table, with a tenant-isolation test suite in CI.
- Invariant lint gates and integration tests run on every verify, so data-boundary rules are enforced by tooling rather than by memory.
Outcome
North star: Cancelled sessions that get refilled without staff touching WhatsApp
A live studio management product with a working panel, booking and credit engine, WhatsApp transport and a strict clinical-data boundary, sold through a Turkish landing page and a sales-led onboarding.
Skills & know-how
What this proves: that I can take a regulated B2B product from positioning to a working multi-tenant system on my own, and hold hard lines (no member app, no payments, no clinical data in the AI) instead of shipping every feature.