# Build a Cambly clone: tutoring bookings, credits and video lessons

Canonical page: [Build a Cambly clone: tutoring bookings, credits and video lessons](<https://clone4.me/guides/build-cambly-clone/>)

A Cambly-style project combines a tutor marketplace, a scheduler and a real video lesson. The manageable first version is a small, invitation-only conversation club for adults, with fixed lesson lengths and approved tutors. It needs working reservations and room access, not just tutor cards.

## A practical starting point

Start with one language, scheduled 30-minute lessons and operator-issued test credits. Use a backend transaction for booking plus credit debit, then grant video access only to the booked learner and tutor. Real payments and payouts are separate milestones.

## Choose scheduled tutoring before instant matching

A learner should find an approved tutor, inspect available times in their own timezone, book one lesson and join it. The tutor should see the same reservation and its status. The operator needs a way to approve profiles and resolve a cancelled or disputed lesson.

Keep the pilot narrow: one language, a handful of tutors, one lesson duration and adult participants. Use invented sample profiles or consenting tutors. Instant availability, tutor recruiting, child accounts, recording and a subscription marketplace each add operational responsibilities that a first booking flow cannot establish.

- [Cambly’s public tutoring workflow](<https://www.cambly.com/english/tutors>)

## Make booking and credits one operation

Store lesson intervals as real instants while retaining the tutor’s timezone for recurring availability. A reservation consumes availability and one test credit together. If either operation fails, neither should remain committed. An idempotency key prevents a network retry from booking or charging twice.

Test both tutor and learner conflicts. Two different learners must not book the same tutor interval, and one learner must not book overlapping tutors. A database constraint or equivalent transactional design should enforce this even when requests arrive simultaneously. PostgreSQL documents range exclusion constraints as one way to reject overlaps.

| Entity | Why it exists |
| --- | --- |
| Tutor profile and availability | Approval, language and bookable intervals |
| Lesson | Participants, interval and current booking state |
| Credit entry | A traceable debit or refund tied to a lesson |
| Attendance and operator action | Evidence for reviewing no-shows or disputes |

- [PostgreSQL range constraints](<https://www.postgresql.org/docs/current/rangetypes.html>)

## Issue access to the lesson, not to a public link

The room-token endpoint should check the signed-in person, booking membership, status and permitted join window. Only then should it issue a short-lived token for that room and participant. A cancelled reservation must stop receiving new access. A random-looking room URL is not an authorization check.

LiveKit’s token documentation explains room-scoped grants and server-side token creation. Integrating a media service still requires your own booking authorization, device permission handling and real two-party testing. A placeholder meeting address is useful for a visual prototype only; label it honestly.

- [LiveKit tokens and grants](<https://docs.livekit.io/home/get-started/authentication/>)

## Define cancellation and attendance before charging money

Use explicit lesson states, such as confirmed, cancelled, completed and disputed. Decide when cancellation restores a test credit and write one corresponding ledger entry. Retrying cancellation must not produce multiple refunds. The operator should be able to see why the balance changed.

Do not infer successful tutoring from a countdown reaching zero in one browser. Record server-observed join/leave events, keep disputes reviewable and avoid recording lessons by default. Live subscriptions, tutor payouts and commercial support require additional provider setup, policy decisions and reconciliation beyond this pilot.

- Attempt the same booking from two learner sessions.
- Cancel twice and confirm one refund.
- Deny camera permission, reconnect mid-lesson and try joining a cancelled lesson.
- Request another learner’s room token directly; access must fail.

## Use the brief or evaluate a clone script carefully

The Cambly entry supplies a complete editable prompt, not installable marketplace source. If you are comparing a Cambly clone script, inspect its license, maintenance history, media provider, authentication and refund behavior before relying on its screenshots. A video integration does not automatically supply a reliable marketplace.

For an AI build, start with test credits and demonstrate one real lesson between separate sessions. Add commercial billing only after the booking and cancellation rules are stable. Compare Calendly for scheduling and Udemy for course delivery; a course library is a different learning product.

### Instructions to add after the complete brief

Build the adult tutoring pilot with one language, approved tutors, 30-minute reservations and test credits. Enforce learner/tutor overlap rules and exactly-once debit/refund behavior. Room tokens require lesson membership and an allowed join window. Show a real two-party call and a denied unauthorized join.

- [Cambly build brief](<https://clone4.me/tools/cambly-clone/>)
- [Calendly build brief](<https://clone4.me/tools/calendly-clone/>)
- [Udemy build brief](<https://clone4.me/tools/udemy-clone/>)

## Related build briefs

- [Cambly build brief](<https://clone4.me/tools/cambly-clone/>)
- [Calendly build brief](<https://clone4.me/tools/calendly-clone/>)
- [Udemy build brief](<https://clone4.me/tools/udemy-clone/>)