Classly.software · Group-class & studio session booking · 2026

A session isn’t one slot for one person. It’s a roster with a seat count.

Most booking tools are built around one calendar, one person, one claimed time. A dance class, a yoga session, a tutoring group, a workshop doesn't work that way — many people book into the SAME session, up to a seat limit, and the next person in line when it fills goes on a waitlist, not a dead end. Tools built for 1:1 appointments retrofit that shape awkwardly. Tools built for one fitness vertical lock you into their workflow.

Classly.software is capacity-first from the start: the roster IS the booking, not a feature stapled onto a single-claim slot. It runs on the same shared fixed-slot / identity-keyed capacity decision core the rest of the schedule.software family is built on — the same booking law, just run at capacity N instead of capacity 1 — so a studio that later wants 1:1 sessions or a recurring cohort series reaches for a sibling product on the same engine, not a new vendor.

Reserve early access See how it works

Nseats per session, not one — the same capacity decision core the schedule.software family is built on, run at capacity N

0commission skim on any session fee, at any planned tier — a pricing commitment, not a live guarantee: classly.software takes no payment today, so there is nothing to skim yet

2server-guaranteed invariants the shared engine enforces on a capacity-N booking — no over-fill + no duplicate booking, both at the database

1waitlist queue per session once the seat count is reached — designed, not built on a classly.software surface today

Why classly.software exists — capacity-first, not a 1:1 tool with classes bolted on

1:1 booking tools retrofit group sessions awkwardly. Single-vertical suites lock you into one workflow and skim a commission.

A tool built for one person's calendar treats a group class as a special case — a single “slot” that somehow needs to hold many bookings, with the actual roster logic patched on afterward. Legacy fitness-marketplace suites solve the roster problem, but they solve it inside one vertical (usually fitness studios specifically), often with a marketplace commission taken off every session fee, and rarely with a path to add 1:1 appointment booking without switching to a different product entirely.

Classly.software starts from the roster instead. Capacity N — many people booking into one session — is the native shape of the booking law from the start, running on the same decision core as the family's capacity-1 siblings. No commission on any session fee, and no vertical lock-in: the same engine is designed to serve a fitness studio, a tutoring group, a workshop series, and K-12 after-school/community-ed alike.

Product type	Capacity-first, not retrofit	Commission on session fees	Not single-vertical-locked	One shared engine with 1:1 booking
1:1 appointment tools with classes bolted on	No — capacity-N retrofitted onto a capacity-1 core	Varies by vendor	Yes	No — two different products
Legacy fitness/studio marketplace suites	Yes	Often a marketplace commission on session fees	No — fitness-vertical-specific	No
Single-vertical class-management tools	Yes	Sometimes, on payment processing	No — locked to one vertical	No
Classly.software (planned)	Planned — capacity-N as the shared engine’s native mode	None, at any tier	Planned — fitness, tutoring, workshops, K-12 after-school alike	Planned — the same shared booking engine at capacity 1

Our own row describes the plan, not a shipped product. The capacity-N booking law underneath it is built in the shared engine; the classly.software tiers and console above are in development and priced display-only. Mindbody, TeamUp, Punchpass, Zen Planner, and WellnessLiving are named here only as factual category references for the group-session booking market this product competes in; none of their code or copy is used anywhere in this product.

Capabilities — what runs today, what is in development, labelled honestly

One capacity-N booking engine. Roster, waitlist, and instructor view around it.

Read the pill before you read the headline: Built is a seat-law mechanic that exists in the shared booking engine right now — it does not mean a roster on this brand has ever held a real booking. Partial is a mechanic that exists in the engine with no finished classly.software screen in front of it yet. Planned is a drawing. The three are not interchangeable and this page will not blur them.

Capacity-N session booking

Many people book INTO one session with a seat limit — not one person per slot

A session — a dance class, a yoga session, a tutoring group, a workshop — publishes a seat count, and up to that many people book into the same session at the same time. This is the same fixed-slot / identity-keyed capacity decision core the rest of the schedule.software family runs on, in its CAPACITY-N mode: capacity 1 is an appointment, capacity N is a class roster — the same booking law, already built in the shared engine, not a retrofit bolted onto a 1:1 tool. Per-session capacity is counted under a lock inside the same transaction that books, so a session can never silently over-fill even when several people try to claim the last seat at once. The engine mode is built; the classly.software-branded roster page a student would actually open is in development.

Engine built (capacity-N mode) · branded roster page in development

Waitlist when a session fills

A full session doesn’t turn a client away — it queues them for the next open seat

When a session's seat count is reached, the next person to try booking is offered a waitlist spot instead of a dead end. If a seat opens — a cancellation, a capacity increase — the next waitlisted person in line is offered it. This is designed as a queue keyed off the same capacity-N decision core the session booking itself runs on, so a waitlist promotion can never push a session over its seat limit. The waitlist mechanism is planned for the branded surface and is not live today.

Planned · not yet built on a classly.software surface

Instructor roster & attendance view

An instructor sees exactly who is coming to a session — not a headcount guess

An instructor's view of a session shows the actual roster: who booked in, whether a seat is a waitlist promotion, and a place to mark attendance after the session runs. This is the studio-facing surface classly.software is built for — the counterpart to the capacity-N booking engine that already guarantees the roster can never exceed the published seat count. This dashboard is designed and not built today; nothing on this page represents a live instructor console today.

Planned · instructor dashboard not yet built

Zero commission on any booking

No percentage taken off a session fee, at any tier, ever

A booking through classly.software is never skimmed a commission — not a percentage of a class fee, not a per-seat cut. This is a stated commitment for the planned pricing tiers below (Starter, Studio, and Multi-location/Education custom), not a claim about a live payments product; classly.software does not process payments today, and no card is charged anywhere on this site.

Planned pricing commitment · no live payments today

One shared calendar substrate across the family

A studio that outgrows classly turns on adjacent modules — no vendor switch

classly.software runs on the same shared calendar substrate as the rest of the schedule.software family: the same fixed-slot / identity-keyed capacity decision core, run here at capacity N instead of capacity 1. A studio that starts with drop-in group classes and later wants 1:1 sessions, or a recurring cohort series, is designed to reach for a sibling product on the same underlying booking law instead of migrating to a new vendor and a new data model. This is a structural property of the shared engine today; the cross-product account/billing handoff between siblings is planned, not built.

Shared engine built · cross-product account handoff planned

No-double-book at the database, not the form

A malformed booking is rejected at the database — never a silent over-fill

Whether a session's capacity is 1 or 30, the same server-side invariants apply: a SELECT … FOR UPDATE counts current live bookings against the published seat count before writing, and a partial-unique index prevents the same person from double-booking the same session. A conflict — a full session, a duplicate booking attempt — returns a clean, retryable response with a machine reason, never a silent over-fill and never a 500. This is the same database-level discipline the shared engine already carries for its capacity-1 siblings, applied here to a roster instead of a single seat.

Built in the shared engine · not yet exposed on a classly.software surface

How it works — the booking flow

Four steps — publish a seat count, book in, guarantee the roster, mark attendance

The booking flow is the same for a group class, a workshop, or any capacity-N session. Only one of these four steps is code a studio could run today; the other three are the screens around it. Each step says which it is.

Step 1 — An instructor publishes a session and a seat count (surface in development)

An instructor sets up a session — a class, a workshop, a recurring weekly meetup — and publishes how many seats it holds. This is part of the classly.software roster page, which is in development and not live today.

Step 2 — People book into the same session, not a private slot (surface in development)

A client sees a session's real remaining seats and books into it — sharing the session with everyone else who books, unlike a 1:1 appointment link. If the session is full, they're offered the waitlist instead of a dead end. Also part of the surface in development.

Step 3 — The server guarantees the seat count in one transaction (built)

This step is the built part. The shared capacity-N decision core counts live bookings under a lock in the same transaction that books, rejecting a booking that would push a session over its published seat count before any write lands, and preventing the same person from double-booking the same session with a partial-unique index. A conflict returns a clean, retryable machine reason — never a silent over-fill.

Step 4 — An instructor sees the roster and marks attendance (planned)

After bookings close, an instructor's dashboard shows the roster who actually booked in, with a place to mark attendance for the session that ran. This dashboard is designed and planned; it is not built today.

Pricing — the plan, grounded and honest. Not a live checkout. No card is charged.

Priced by tier, never by a percentage of what a session earns.

Read the numbers below as a published intention, not an offer. Nothing on this page is a live checkout, no card is charged by anything you click here, and a studio cannot buy classly.software today at any price — there is no product surface to sell yet. What the tiers do commit to is the shape: a flat monthly line, never a slice of what a session earns.

Starter

~$29 / mo

Planned · not a live checkout

Capacity-N session booking
Same no-over-fill guarantee as every tier
Zero commission on session fees
Roster + waitlist (planned)
Custom domain — planned for every tier, not locked behind a top plan

Studio

~$79 / mo

Planned · not a live checkout

Everything in Starter
Instructor roster & attendance view (planned)
Multiple instructors, one shared calendar
Zero commission, no per-seat metering
White-label branding — your logo, colors, and the badge gone (planned)

Multi-location / Education

Custom

Volume · multi-site · planned

Everything in Studio
Multi-location console
K-12 after-school / community-ed fit
SLA and dedicated support

Reserve early access Discuss pricing for your studio

Every figure above is a planned launch tier. This is not a live checkout, no card is charged, and no money moves through this site in either direction — the payments seam exists in the codebase but is switched off, and classly.software has never taken a payment.

Correctness is a database invariant, not a form — the structural approach

Twelve people racing the last four seats all get a clean result. Never a 13th seat. Never a 500.

Most class-booking tools enforce a seat count in application code: a conditional check before the INSERT, a counter incremented after a form submit. The problem is that several requests arriving in the same instant can all pass the check, all see a seat as open, and all write a booking — a session over its published capacity. The only fix that holds under concurrency is a database-level invariant.

Classly.software inherits both guarantees at the database from the same shared engine the schedule.software family is built on. Per-session capacity is counted under a SELECT … FOR UPDATE in the same transaction that books; a partial-unique index prevents the same person from double-booking the same session. Whether the seat count is 1 or 30, the invariant is identical — the same booking law, run at a different N.

What is built and what is not — plainly stated

The capacity-N booking law is built. The standalone classly.software product surface is in development. We say so directly.

Already built in the shared engine: the capacity-N decision core (the same fixed-slot / identity-keyed capacity law as the family's capacity-1 siblings, run with N > 1), the per-session transactional seat count, and the no-duplicate-booking partial-unique index. There is no classly.software deployment serving live bookings today — the engine mode is built; this brand's surface on top of it is not.

In active development or planned: the public roster page a student would open, the waitlist queue and promotion logic, the instructor's roster and attendance dashboard, self-serve onboarding, and the multi-location console.

Honest-off (infrastructure in place, not live): payments — the seam is in place, Stripe is not enabled, there is no live checkout on this site. No AI-assist claims of any kind are made here. Classly.software does not hold FERPA, COPPA, SOC2, or VPAT certification.

Reserve early access

The capacity-N booking law is built. The standalone product is opening next.

The hard part — the no-over-fill guarantee, the transactional seat count, the no-duplicate-booking invariant — is already built in the shared engine. What is opening next is the standalone classly.software surface: the public roster page, the waitlist queue, and the instructor dashboard. We are taking early access registrations now. No live checkout, no automatic charge. A conversation first — what your studio needs, what is ready today, what is landing next — then we discuss what access looks like.

To reserve early access or book a conversation: [email protected]

FAQ

Common questions

How is capacity-N booking different from an appointment slot?

An appointment slot has a capacity of exactly one — one person claims it and it's gone. A classly.software session has a capacity of N — many people book into the same session up to a published seat count, with a waitlist once it fills. Both run on the same shared fixed-slot / identity-keyed capacity decision core; capacity-N is simply that core's other mode, not a different, retrofitted product. This is a genuinely different booking mechanism, not a re-skin of a 1:1 tool with classes bolted on afterward.

Is the roster page, the waitlist, or the instructor dashboard live today?

No. The capacity-N booking law itself is built in the shared engine. The branded classly.software surfaces around it — the public roster page a student would open, the waitlist queue, and the instructor's attendance dashboard — are in development or planned; none of them is built today. We say this plainly rather than imply a console exists.

Do you skim a commission on class or session fees?

No commission skim on any booking, at any tier — a stated pricing commitment for the planned Starter and Studio tiers below. classly.software does not process live payments today; this is a claim about how pricing is planned to work, not about a live checkout running now.

Is classly.software affiliated with any other product that uses a similar name?

No. classly.software is a separate product with no association, affiliation, or shared ownership with any other product operating under a similar mark, in any market or vertical. This page does not name, link to, or reference any such product, and does not borrow its positioning or copy.

What is the difference between classly.software and cohort.software?

classly.software is the single-session sibling: one class, one seat count, drop-in or recurring bookings into the same session. cohort.software is the planned companion for recurring fixed-roster series enrollment — a multi-week program where the same group of people stays enrolled across sessions. Both are designed to run on the same capacity-N booking law; neither is live as a standalone product surface today, and neither is a feature of the other.

How exactly is over-booking a session prevented — is it just a check in application code?

No, it is not an application-code check. Per-session capacity is counted under a SELECT … FOR UPDATE inside the same transaction that books, and a partial-unique index prevents the same person from double-booking the same session. A booking that would exceed the published seat count is rejected at the database before any write lands, with a clean, retryable machine reason — not a form-level check a race condition could slip past.

Can I actually pay for a tier on this page today?

No, and nothing here will try to charge you. The tiers are a published intention; there is no live checkout, no card is charged, and the Stripe seam behind those numbers is switched off. Reserving early access puts you in a conversation about what your studio needs — billing is a later conversation that starts only once there is something to bill for.

What can we actually see or use right now?

The capacity-N booking law — per-session seat counting under a lock, no-double-book at the database — is built in the shared engine this whole family is assembled on. The standalone classly.software product surface (the public roster page, the waitlist queue, the instructor dashboard, self-serve onboarding) is in development or planned. So the honest answer is: nothing on this brand, yet. Book a conversation and we will show you the seat law running and name a date for the roster page rather than a demo of one.

Do I need to pay extra to use my own domain and remove your branding?

Not for the domain, as planned: a custom domain sits on the entry Starter tier, not locked behind an enterprise conversation the way it is on some sign-up tools. Removing our badge and applying your logo and colors is Studio, one plan step up. Both are planned pricing-tier commitments today, not a live self-serve screen — the classly.software-branded setup screen for a domain or a brand is in development, the same status as the roster page and the waitlist queue above, and classly.software sets no custom domain and removes no branding today.

If I white-label classly.software, do notification emails come from my own domain?

No, and we say that plainly rather than let it be assumed. A white-labeled account would carry your display name and reply-to on any notification; the actual sending domain and the consent/legal footer stay the platform’s at every tier — that floor does not move, even at the top plan. This is a planned pricing-tier shape; classly.software sends no notification email today.