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

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.

References: Cambly’s public tutoring workflow

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.

References: PostgreSQL range constraints

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.

References: LiveKit tokens and grants

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.