At a glance
Founder-operated ballet and Pilates school in Tokyo. Running daily on Pepperoni Booking for 6–12 months. 50–150 active clients across 10 locations. Uses the same Booking-tier features available to every customer — no special access, no hidden tooling.
- Location
- Tokyo, Japan
- Active clients
- 50–150
- Time on platform
- 6–12 months active on the platform
- Plan tier
- Booking
First — full disclosure
Larry's School of Ballet is founded and operated by Daishin Murooka — the same person who founded Pepperoni Booking. It is not a third-party customer; it is the studio whose pain shaped the product.
We publish this case study anyway because it is the longest-running tenant on the platform. Hiding the founder relationship would let us tell a more flattering story and a less true one. We chose true.
What you can take from this: the platform survives daily contact with a real studio. The features used are the same ones available to every Booking-tier customer. What you cannot take from this: that an external studio chose Pepperoni from a list of competitors. Osaka Ballet is also on the platform — a friendly tenant who came through the founder's network — and their story is told separately. A case study about a studio that chose Pepperoni cold from a competitor comparison is the next one we want to write.
Read Osaka Ballet's case study →
The studio
- Name
- Larry's School of Ballet
- Location
- Tokyo, Japan
- Locations
- 10
- Studio owner
- Daishin Murooka (also founder of Pepperoni Booking)
- Specialties
- Ballet and Pilates classes
- Active clients
- 50–150
- Time on platform
- 6–12 months active on the platform
- Plan tier
- Booking
I run my own studio. I built Pepperoni for the parts that kept stealing my evenings — the rebookings, the no-shows, the calendar that lived in three places. If a feature didn't help my own week, it didn't ship.
“I teach ballet at Larry's. I see what works in the studio every day — which class times fill, which students keep coming back, where the schedule has room to grow. The platform reflects what teaching there has taught me.”
Ai is an AI instructor. Her perspective shapes the platform the way a human instructor's would — and we disclose her nature here for the same reason we disclose the founder relationship: the honest version is more useful than the polished one.
The pre-Pepperoni state
Larry's didn't migrate from another booking system — the platform was built for it. Before Pepperoni existed, the studio ran the way most small studios still do: messaging apps for confirmations, a calendar in one place, a spreadsheet in another, and a notebook that was the most accurate of the three. The pain that shaped the product wasn't 'we need a better tool'; it was the founder's own evenings disappearing into reconciliation work that shouldn't have existed.
A more specific account — exact tools, exact workflows, what broke first — is being written. Until then, the sketch above is the honest version.
What changed at Larry's
The same scenarios on the home page, but specific to Larry's day. Not a marketing claim — the homepage shows the framework; this section shows the instance.
Before Pepperoni
Phone Rings Mid-Class
A prospective student wants to book a private. Miss the call mid-teaching, lose the booking.
After Pepperoni
Bookings Come Through The Platform
Class is taught uninterrupted. Confirmation goes out automatically — the studio never sees it happen.
Before Pepperoni
Paper vs Spreadsheet
Paper schedule said 10 spots. Spreadsheet said 12. Two students arrived to a full studio.
After Pepperoni
Capacity Is Enforced
Capacity stops at 10. Waitlist activates automatically. Overbooking becomes impossible.
Before Pepperoni
Late-Cancellation Tax
Last-minute cancellations quietly ate evenings — rescheduling, reaching back out, sorting the calendar — for sessions that produced nothing.
After Pepperoni
Time Stays With Teaching
Cancellations are handled in the platform. The waitlist fills the spot. Time that used to evaporate stays with teaching.
What features Larry's uses
These are features available to every Booking-tier customer, not Larry's-only privileges.
- Bookings — student-facing booking flow, capacity rules, no-show tracking
- Classes — recurring schedule, weekly enrollment, per-session notes
- Teachers — instructor profiles, per-instructor scheduling
- Students — client database, trial → member conversion
- Notifications — booking confirmations, reminders, cancellation flows (Japanese, English fallback)
- Calendar feeds — personal iCal feed for the studio owner
- Support chat — direct line to platform support
Features Larry's tests as a first user before they ship to other tenants
The dogfood loop made explicit: features ship behind PostHog flags, get exercised in real-world usage at Larry's, then roll out to other tenants once proven. Other tenants benefit from the testing without absorbing the risk.
- Class formats (group / private classification)
- Semi-private (host books N seats)
- New admin calendar IA
- PostHog session replay scoped to booking flow
What this case study cannot tell you
Direct, honest list:
- Whether Larry's would have chosen Pepperoni from a list of competitors. The founder built the platform; he didn't shop for it.
- Whether the platform is what an outside studio would want it to be. The founder's preferences are not necessarily other studios' preferences; we mitigate this with the founding cohort program.
- Whether the metrics generalize. A 10-location ballet school in Tokyo is not a 1-location yoga studio in Berlin. Numbers from Larry's are real for Larry's; they are a starting point, not a promise, for anyone else.
- Whether switching from your current system is worth it. Larry's didn't switch — the platform was built for it. Most prospect studios already use something (WhatsApp, messaging, Google Calendar, or another booking SaaS). Their question isn't 'do I need a tool?' — it's 'is switching worth the friction?' This case study cannot answer that for you. The founding cohort program is designed to absorb the switching friction (10-minute founder-led setup, soft-entry on one class type, parallel-run period — see /how-to-switch for the full plan).
What this case study can tell you
- The platform is used in production every day by someone whose livelihood depends on it working.
- Bugs that affect Larry's get fixed first because they affect the founder's business directly.
- Features that don't survive contact with a real studio don't survive the dogfood loop.
- The product roadmap is shaped by a studio owner who is in the studio, not a product manager who has visited one.
Why this case study is short for now
The fuller story — pre-Pepperoni operating state, the specific operational changes that mattered most — is being written. The case study is published in this honest interim form because the dogfood disclosure itself is the load-bearing trust signal, not the polish. When the studio-owner narrative is added, this section is replaced. Until then, what's above is verifiable; what's missing is acknowledged.
This case study is published to set the standard: any future case study about a third-party founding studio will be at least this honest about what it does and doesn't claim.
Explore further