Booking Bible
A multi-tenant booking and studio-management platform built to replace Mindbody — payments, streaming, AI assistants, and a public API. The engine under every other project on this site.
Run your studio.
- Orange
- Amber
- Cream
- Ink
Plain language. No jargon.
One platform under every brand in this index — bookings, memberships, payments, streaming and a public API, multi-tenant from day one. Studios keep their name, their rules and their revenue; the engine stays out of sight.
One codebase, many venues — every studio gets its own brands, staff, pricing and rules, isolated at the database layer.
Stripe with MobilePay, VAT engines per purchaser type, split tenders at the front desk, and receipts that satisfy Danish bookkeeping law.
Hybrid classes stream through Mux — an encoder, a QR code, and a phone can broadcast a class.
Admins ask questions and delegate tasks in plain language; every write the AI makes is reversible by design.
The same contracts the sister sites run on — schedule, checkout, gift cards, SSO — are the product's public surface.
Studios arrive with years of history in other systems; imports are dry-run first, guarded, and audited.
Case study
The problem
Every studio in the ecosystem ran on Mindbody, and Mindbody decided what a member could do, what a receipt looked like, when a feature arrived and what leaving would cost. It also got the local details wrong in the way foreign software always does: VAT by purchaser type, MobilePay, split tenders at the front desk, receipts a Danish bookkeeper will actually accept.
What I did
Sole founder and sole engineer. I modelled the schema, wrote the API, built the admin, the member portal and the point of sale, shipped three mobile apps, integrated Stripe and Mux, wrote the migration tooling that lifted years of history off Mindbody — and then ran my own studios on it for months before offering it to anyone else.
- Domain modelling
- Backend
- Frontend
- iOS & Android
- Payments
- Video
- Design
- DevOps
- Documentation
- Support
Architecture
- Multi-tenant from the first migration: one codebase, many venues, isolated at the database layer — 692 tables and 932 reviewed migrations, every one applied to staging first.
- 774 API route handlers. The admin, the member portal, the sister sites and the public API all consume the same contracts, so each behaviour has exactly one implementation.
- Stripe for payments with MobilePay and 35 currencies; Mux for live and recorded video; Supabase for Postgres, auth and realtime.
- Three React Native apps — consumer, white-label studio and staff — from one Expo codebase against the same REST API.
- Kill switches on every risky subsystem, append-only audit logs, dry-run guarded imports and 2,688 test files. Nothing dangerous ships without an undo.
Outcomes
- Mindbody switched off. Bookings, memberships, passes, payments, point of sale, streaming and the member portal all run in-house.
- Hot Yoga Copenhagen operates on it daily; Yoga Bible runs five brands, roughly 150 clients and around 15 staff through it.
- The sister sites are built on its public contracts — which is how the API surface got stress-tested before it had a single external customer.
- A written business-continuity handover exists, in plain English, for an executor or a new engineer who has never seen the code.
Status
Live at bookingbible.com, commercially pre-launch. Booking Bible ApS · CVR 46504666.
In the ecosystem
The engine. Every other project in this index is a customer of this one.
First commit. Yoga Bible becomes the dogfooding operator — 5 brands, ~150 clients, ~15 staff.
Mindbody switched off. Payments, bookings, memberships and streaming all live on Booking Bible.
Booking Bible ApS incorporated (CVR 46504666), with Mister Shamir ApS as parent. Raising to market it.
Software a studio
can trust.
Why it exists
The room adapts per project: for the platforms this section carries screenshots, dashboards and an architecture sketch instead of interior photography.
Every studio in the ecosystem below runs its bookings, payments and schedules through this one platform — so this is the room where the diagram lives: tenants, plans, webhooks, the parts nobody visits but everything depends on.
The engine room
Every other project on this site is a customer of this one. The studios book through it, the streaming sites authenticate against it, the marketing suite listens to its webhooks. Building the whole ecosystem on one platform wasn't the business plan — it was quality control. If a feature annoys the founder at his own front desk at 07:58, it gets fixed.
It is also the most disciplined codebase in the house: staging-first migrations, kill switches on every risky subsystem, append-only audit logs, and a session log that remembers every change since the first commit.