Classa
Studio and classes management, built so the admin work runs itself.
Type
Client project
Role
Product Designer & No-Code Developer
Client
Classa
Platform
Web App · Responsive
/ Overview
Services
Product Design · UX/UI · No-Code Development
Deliverables
End-to-end SaaS app, onboarding, scheduling and billing flows
Industry
SaaS · Studio Management
Classa gives studios one place to run classes end to end — scheduling, rosters, attendance, memberships and billing — instead of juggling spreadsheets, WhatsApp and a calendar. The hard part was never the screens: it was the business logic underneath them, where a punch card, a waitlist and a cancellation window all touch the same seat.
/ Challenge
The
challenge
A booking in a studio is not a row in a calendar — it is a punch off a card somebody paid for. So every action that touches a class has to move money correctly and on its own: cancelling returns the punch, rescheduling carries the bookings across, removing a class refunds everyone on it. Get one of those wrong and a member quietly loses a session they already bought.
Two payment models had to live behind the same screens. A punch card counts down and eventually runs out; a monthly pass must never decrement and must never read as spent. Same booking button, same profile, opposite rules underneath — and the member should never have to work out which one they are holding.
Four kinds of user share one product: a visitor who opens a studio link, a member, an instructor, and the owner running the place. The first two routes — the public studio page and the payment link — had to work with no account at all, because a studio sells to people who have not signed up yet.
/ User flows
Booking a class
From a link a friend forwarded to a confirmed seat — including what the product does when the class is already full.
Yes
No
Both legs end in a confirmed seat — the waitlist is a slower yes, never a no. Seat counts are recomputed from bookings rather than incremented, so a place can never be sold twice.
/ Approach
How we
got there
Follow the punch
Before any screen: map every path a paid seat can take — booked, cancelled, waitlisted, promoted, rescheduled, refunded. The flows came out of that map rather than the other way round.
Let the roles draw the product
Visitor, member, instructor, owner. Each got its own surface and its own ceiling — an instructor reaches classes and rosters and stops there, never memberships or settings.
Hide the billing model
Punch cards and monthly passes resolve behind one interface, so the booking button, the schedule and the purchase history read the same whichever one you hold.
Build it in Hebrew, right to left
RTL is a direction, not a translation. Dialog and dropdown positioning, arrow-key order, date and time formats and every outgoing email had to work in it — including the places the component library got it wrong.
/ Selected screens
The work
Three user scenarios — member, instructor, studio owner
Billing: punch cards, monthly passes and payment links