Getting started · Classly.software

There is no sign-up form on this page. That is deliberate.

The capacity-N booking law — the seat count guaranteed under a lock, no-double-book at the database — is built in the shared engine. The classly.software-branded product surface around it — the roster page, the waitlist, the instructor dashboard, self-serve onboarding — is not. A form that cannot provision a roster is a form that lies about what it does, so: a conversation first, and an honest account of what runs today.

This page tells you exactly what happens if you reach out, in order, and what you get at each step. Nothing here creates an account, charges a card, or starts a contract.

What actually happens

Four steps, and you can stop after any of them.

✓1 — Tell us the shape of your studio

Write to [email protected] with what you run — classes, workshops, tutoring groups — roughly how many sessions and how many seats, and what breaks today (a spreadsheet, a sign-up sheet that overbooks, a waitlist kept by hand). One paragraph is plenty.

✓2 — A walkthrough of what is built, not a pitch deck

We show you the capacity-N booking law running — the seat count guaranteed under a lock, the no-duplicate-booking index — and we name, out loud, which parts of the roster page, waitlist, and instructor view are still in development. You should leave the call able to repeat back what is real.

✓3 — A scoped conversation about your first session type

Almost nobody should plan for every session shape at once. We scope the conversation to the one that hurts most — usually a single recurring class or workshop series — and talk through what a pilot on it would actually need.

✓4 — Widen only once the first one is boring

The capacity-N booking law is the same whether the seat count is 1 or 30, so adding a second session type or a second instructor is designed to be a configuration change on the same engine, not a second procurement. That is the argument for the product, and it is worth nothing until the first session type is dull and reliable.

Three conversations, depending on who you are

Studio, Multi-instructor, Multi-location/Education.

Studio (Building). A single instructor or a small studio running one or a few recurring class types — we walk the capacity-N booking law and the planned Building-tier commitments: no commission, a custom domain.

Multi-instructor (District tier). Several instructors sharing one calendar, each with their own sessions — we talk through the planned instructor roster and attendance view and what white-label branding would look like for your studio’s name.

Multi-location / Education. A multi-site studio, or a K-12 after-school / community-ed program — we scope the multi-location console and the consent posture a school-facing roster would need before any student data touches the system.

Choose one independent adult session to describe

Start with an invented adult writing studio that offers a weekly critique session. Each dated meeting is an independent choice, with six places and a ninety-minute duration. A participant can choose one evening without enrolling in every later meeting. Write the offered date, time zone, duration, capacity and public description on a preparation sheet. Those facts establish the session you want to discuss. They do not publish it on this website. If the real program instead expects the same group to complete an entire course, name that difference before treating a single-session model as the right fit.

Then describe the operator's immediate problem. Perhaps the studio currently has to reconcile repeated requests by hand, or people cannot tell whether an expression of interest means they have a place. Pick one consequence and explain it with fictional counts. A broad request for better scheduling makes it difficult to evaluate the proposed product; a specific request to distinguish an existing booking from another claim gives the conversation a decision to address. Keep the actual customer list in the existing service. You can prepare the useful example without a name, an email address, a payment record or a copied booking reference.

Prepare a normal result, a refusal and an unresolved policy

For the fictional six-place critique session, first describe five represented places and a request from another distinct adult. The expected decision can be written without running a booking system. Next, describe a repeated request from someone already represented and ask how the future customer view should explain that outcome. Finally, make the session full and introduce another interested adult. That last example depends on the planned waitlist surface. Keep the states separate on the preparation sheet rather than treating all three requests as successful bookings or assuming the marketing page can accept them.

Add one policy question the studio has not settled. A cancellation after the intended deadline might release capacity under one policy and require a separate discussion under another. The session model does not choose that business rule for the operator, and a cancellation decision does not prove a refund. State which question concerns scheduling and which concerns the studio's existing commercial arrangements. The useful output is a small set of expectations and an admitted uncertainty. An evaluator can then identify what the shared decision core addresses, what the branded surface still needs and what remains a human policy decision.

Decide what would justify moving beyond the conversation

The writing-studio example gives a later walkthrough something concrete to answer. Ask for an explanation of the offered session, the result of each fictional request and the point at which a planned surface would be needed. A roster picture alone does not establish that a booking was recorded. A displayed waitlist label does not establish promotion, and an email-shaped preview does not establish delivery. The evidence should match the particular outcome being claimed. This public site supplies reading material and an email route, so it cannot complete those operational steps while you prepare the questions.

Before considering a pilot, list the dependencies that matter to the studio. A working instructor view may be essential; a custom domain may be useful later; a roster export might be unnecessary for the first narrow question. Compare each dependency with the status ledger instead of assuming everything arrives with the shared engine. The result may be to wait until a required surface exists. That is a reasonable evaluation outcome, and it does not require a purchase commitment or moving the studio's current bookings. Keep the existing arrangement responsible for real sessions until a separately defined operational change is actually made.

End the preparation with a short acceptance sentence and a refusal sentence. For this example, an adult should be able to understand whether the dated critique session has a confirmed place for them; an expression of interest must not be presented as that confirmation. Those sentences are specific enough to review and small enough to discuss without real records. They keep a future demonstration focused on the result the studio needs rather than on how many controls appear in a planned interface.

What starting does not involve

No card, no charge, no contract signed on a web page.

There is no live checkout on this site, and classly.software has never taken a payment. Reserving early access does not create a payment, does not store a card, and does not commit you to anything — the pricing on the home page is a planned launch tier, not a price you can be billed at today. No pricing commitment, no signup.

The roster page, the waitlist queue, the instructor dashboard, and self-serve onboarding are in development or planned; the capacity-N booking law and the database guarantees underneath them are built. We would rather you hear the difference here than discover it in week two.

Reserve early access Read the help page

The mechanism underneath the plan

Capacity-N is built in the shared decision core; the Classly product surface is still being made.

A group session differs from an appointment in one decisive way: several people claim seats in the same scheduled occurrence. The underlying engine treats that as a capacity decision keyed to the person and session. It counts confirmed bookings while holding the session row under a database lock, then accepts or refuses the next claim inside the same transaction. A partial unique index prevents one person from holding the same session twice. Capacity one and capacity thirty use the same law at different values of N.

That decision core exists. A Classly-branded public schedule, roster, waitlist, instructor console, attendance workflow, payment page, and self-serve setup do not exist as a live product today. The distinction is repeated because a polished marketing page can otherwise make a database capability sound like a service someone can buy. Early access starts with a conversation; this site creates no account, charges no card, and books no seat.

The planned public flow is simple enough to inspect: an adult customer chooses a session, sees an honest seat state, identifies themself, and receives either a confirmed place or a waitlist position. A studio operator sees the same occurrence as a roster with capacity, schedule details, and status. An instructor sees only the practical attendance view needed for the session. Those surfaces share a decision but have different disclosure and editing rights.

Waitlist promotion is planned. It must be transactional for the same reason booking is: releasing one confirmed place and promoting the next eligible person cannot be two unrelated writes. Notification delivery must follow the committed decision and remain retryable without creating a second booking. Until those paths and their operator controls exist, this site describes them as planned rather than demonstrating a fake queue.

For evaluation, use a synthetic studio and synthetic adults. A useful example might contain three instructors, six weekly session types, capacities between four and twenty, a cancellation window, and invented attendee names. That is enough to test schedule shape, capacity pressure, waitlist policy, and instructor visibility without bringing real customer records into an early product conversation.

Commercial and operational boundary

Zero commission is a pricing commitment for the planned product, not evidence of a live checkout.

The planned tiers do not take a percentage of session fees. A studio may still choose a payment provider whose processing terms apply, but Classly does not plan to add a marketplace commission. Prices shown on the overview are display-only. There is no subscription checkout, payment token, active trial, or automatic renewal on this website.

White-label presentation, custom domains, roster export, attendance tools, waitlist promotion, and the multi-location console are planned product surfaces. The capacity decision beneath them is built, but that fact does not prove the branded workflow, accessibility review, support process, or operational monitoring around them. Each feature becomes available only when its whole path can be exercised and supported.

Classly makes no adoption, outcome, uptime, or customer-count claim. It presents no testimonial and claims no FERPA, COPPA, SOC2, or VPAT certification. The site contains ordinary product documents and an email link. It sets no marketing cookie, accepts no roster upload, and asks prospects not to send identifiable participant data during evaluation.

An operator also needs a recovery story before a booking surface opens. Session changes must preserve the prior occurrence long enough to explain what attendees originally accepted. Cancellations and capacity changes need named actors and timestamps. Notification delivery can be retried, while the committed roster remains stable. Support staff should be able to inspect a synthetic reproduction without gaining broad access to every studio. Backups, exports, and operational logs need retention and deletion rules. These are ordinary service responsibilities, but none can be inferred from the presence of an atomic booking function. They belong in the readiness decision for each planned surface.