How to Build a Tutoring Platform Like Preply or Cambly

A tutoring platform like Preply is a two-sided marketplace with five systems on top: tutor profiles and search, scheduling across time zones, live video, payments with tutor payouts, and reviews and trust. Buy the video from an API instead of building it, take payment when a lesson is booked, and release the tutor's share only after the lesson has happened.

This guide is for founders planning a human-tutor marketplace. A note on proof first: RAITHub built PadhAI, an AI tutoring platform with payments across 9 gateways, and it informs the tutoring and payment sections below. PadhAI is not a marketplace of human tutors, and RAITHub has not shipped one. The marketplace parts of this guide are engineering guidance, and they are labelled that way.

What are the parts of a tutoring marketplace?

Five systems, and the build-or-buy call is different for each.

System	What it does	Build or buy	The hard part
Tutor profiles and search	Subjects, languages, price, availability, video intro, ratings	Build	Ranking new tutors fairly against established ones
Scheduling	Availability, booking, rescheduling, cancellation rules	Build	Time zones and double bookings
Live lessons	Video, audio, screen share, whiteboard, chat	Buy a video API	Quality on poor connections; recording consent
Payments and payouts	Trials, packages, refunds, commission, tutor payouts	Build on a gateway	Prepaid credit is a liability until the lesson happens
Reviews and trust	Verified reviews, tutor verification, reporting, safeguarding	Build	Keeping reviews honest and learners safe

A course library, homework and progress tracking are a different product: a learning management system. If that is what you need, read how to build an LMS from scratch instead.

How do tutoring marketplaces like Preply make money?

Through commission on lessons, weighted towards the first one. Preply's tutor page says the commission for a trial lesson with a new student is 100%, and for later lessons it "starts at 33% and decreases to 18%" as a tutor teaches more hours (Preply: teach online, checked on 29 September 2026).

That model tells you what to build. The platform pays to find the student, so it keeps the first lesson; after that, a falling commission rewards tutors for staying. Your own numbers will differ, but the engineering consequence is the same: commission is a rule that depends on the tutor's history and the lesson type, so store the rate on each lesson at the moment it is booked, never compute it later from current settings.

How do you handle scheduling across time zones without double bookings?

Store every lesson as a time range in UTC, store each tutor's IANA time zone (such as Asia/Dhaka or Europe/Berlin) with their availability, and let the database refuse overlapping lessons. Weekly availability is written in the tutor's local time and expanded into real dates, which is where daylight-saving changes catch people out: "Mondays 18:00" in Berlin is a different UTC time in July than in January.

PostgreSQL can enforce "no two active lessons for the same tutor overlap" as a constraint, so a race between two students booking the same slot cannot succeed twice:

CREATE EXTENSION IF NOT EXISTS btree_gist;

CREATE TABLE lessons (
  id          bigserial PRIMARY KEY,
  tutor_id    bigint NOT NULL,
  student_id  bigint NOT NULL,
  during      tstzrange NOT NULL,
  status      text NOT NULL DEFAULT 'booked',   -- booked | completed | cancelled
  rate_minor  integer NOT NULL,                 -- price at booking, in cents
  commission_bps integer NOT NULL,              -- commission at booking
  -- A tutor cannot have two non-cancelled lessons that overlap in time.
  EXCLUDE USING gist (tutor_id WITH =, during WITH &&)
    WHERE (status <> 'cancelled')
);

The application still checks availability first so students see free slots, but the constraint is the guarantee. Test it by firing two bookings for the same slot at once and asserting that exactly one succeeds.

Should you build video calling or use an API?

Use an API. Real-time video across countries and mobile networks is a product in itself, and a tutoring startup gains nothing by rebuilding it. The cost is small at the start. As one published example, Daily's video SDK includes 10,000 free participant minutes a month, then $0.004 per participant minute up to 100,000 minutes, with cloud recording at about $0.0135 a recorded minute (Daily video SDK pricing, checked on 29 September 2026). Other providers price similarly; compare them on your learners' networks, not only on price.

Monthly volume (illustrative)	Participant minutes	Video cost at those rates
200 lessons of 50 minutes, 2 people each	20,000	(20,000 − 10,000) × $0.004 = $40
1,000 lessons of 50 minutes	100,000	(100,000 − 10,000) × $0.004 = $360
1,000 lessons, all recorded	100,000, plus 50,000 recorded minutes	$360 + about $675 recording

Recording is the line that grows fastest, and it carries a consent question, especially with children. Make recording opt-in, per lesson, with retention limits, and confirm the rules for your learners' countries with your adviser.

How should payments and tutor payouts work?

Take the money when the lesson is booked, hold it, and pay the tutor after the lesson is completed. Everything else follows from that choice.

• Packages are prepaid credit. A student who buys ten lessons has paid for services not yet delivered. Keep a ledger of credit bought, used and refunded, so balances can always be explained line by line.
• Cancellation rules are money rules. A late cancellation might pay the tutor in full; an early one refunds the student's credit. Write the rules down before any code, and test each one.
• Payouts need a marketplace-capable gateway. The platform charges before it knows exactly what the tutor will earn, which is the case Stripe's documentation describes for separate charges and transfers: "You can create a charge before knowing the connected account" (Stripe: charges in Connect).
• Local payment methods matter. Learners in many markets pay with wallets or local gateways rather than cards. PadhAI, designed for 7 emerging markets, supports 9 payment gateways for that reason.

The payout itself is a small calculation that must be exact: a completed lesson's rate_minor less its commission, in integer cents, summed per tutor per payout period. Because the rate and commission were stored on the lesson at booking, the calculation never changes when you adjust your pricing later.

How do you build reviews and trust into a tutoring platform?

By tying every trust signal to something that actually happened on the platform.

• Reviews only from completed lessons. A review row references a lesson with status completed, one per lesson, so nobody can review a tutor they never met.
• Tutor verification. Identity, and where you claim it, qualifications, checked by a person with the evidence stored. Show what was verified, not a generic badge.
• Safeguarding for younger learners. Parent accounts, no private contact details before booking, lesson chat kept on the platform, and a clear reporting path. Background-check requirements vary by country; confirm them with your adviser.
• Keeping lessons on the platform. Students and tutors who meet on your platform may try to move off it to avoid commission. Fair pricing and useful features, such as scheduling, reminders and lesson notes, keep them better than blocking phone numbers in chat.

Where does AI fit in a human tutoring platform?

Beside the tutor, not instead of them. Useful first uses are lesson summaries, practice between lessons and help matching students to tutors. PadhAI's tutor is Socratic, guiding with questions instead of giving answers, with math verification and RAG, and its 70/20/10 model router sends each query to a lightweight, mid-tier or premium model to keep cost per learner viable. The design choices are in how to build an AI tutor.

What should you build first?

One subject, one market, one payment method, and the full loop from search to review. A first release that works end to end teaches you more than a wide one that half works.

1. Tutor sign-up, profile and manual approval.
2. Search with a few filters: subject, price, availability.
3. Booking with time zones handled and double bookings blocked.
4. Video lessons through an API, with a join link and reminders.
5. Payment at booking, completion, and a tutor payout run.
6. Reviews from completed lessons.

Leave packages, subscriptions, recording, group classes and native mobile apps for later. RAITHub builds responsive web apps and does not offer native mobile development. How a fixed-scope first release works is on the MVP development service page, and what shapes the budget of any marketplace is in the cost to build a marketplace platform.

Why RAITHub for a tutoring platform

• Tutoring and payments are shipped work. PadhAI has 11 services, 9 in Node/TypeScript and 2 in Python, a Socratic tutor, a PWA with WhatsApp and Telegram channels, and 9 payment gateways.
• Marketplace money logic too. TheSkinProof, the founder's own marketplace venture rather than a client project, handles per-seller commission and 4 payment rails, with 750+ automated tests.
• Honest scope. RAITHub has not shipped a human-tutor marketplace, and says so. The scheduling, video and payout parts are built from the patterns above and tested like the rest.
• Fixed scope. A free 15-minute technical audit, then a written fixed quote. You own the code; an NDA is standard.

When you don't need us

• You are one tutoring business, not a marketplace. An existing booking and payments tool will do the job for far less.
• You want to test demand first. A hosted marketplace builder can get a first version live quickly; build custom once the model is proven.
• You need published learning-outcome data from past work. RAITHub does not publish PadhAI outcomes.
• You need safeguarding or child-data legal advice. That is for a qualified adviser in your learners' countries.

More on education products is in the EdTech software development guide and on the EdTech industry page; PadhAI's architecture is on the work page. To plan yours, book the free 15-minute technical audit with your subject, your first market and how learners will pay.

Last reviewed: 29 September 2026. Preply, Daily and Stripe figures checked on 29 September 2026.

Frequently asked questions

How do I build a tutoring platform like Preply?

Build tutor profiles and search, time-zone-safe scheduling, payments with tutor payouts, and reviews tied to completed lessons, and use a video API for the lessons themselves. Start with one subject, one market and one payment method.

How much commission do tutoring platforms take?

It varies. Preply says its commission is 100% on a trial lesson with a new student, and starts at 33% on later lessons, falling to 18% as a tutor teaches more hours, as checked on 29 September 2026.

Should I build my own video calling for online tutoring?

No. Use a video API. At Daily's published rates, 1,000 fifty-minute lessons a month cost about $360 in video after the free 10,000 minutes, far less than building and running real-time video yourself.

How do I stop two students booking the same tutor slot?

Store lessons as UTC time ranges and add a database exclusion constraint so a tutor cannot have two overlapping lessons that are not cancelled. The database then rejects the second booking even if both arrive at once.

When should a tutor get paid?

After the lesson is completed. Take payment at booking, hold it, and pay the tutor their share, the lesson rate less commission, on a regular payout run.

Has RAITHub built a tutoring platform?

RAITHub built PadhAI, an AI tutoring platform with a Socratic tutor, math verification, RAG and 9 payment gateways. It is not a marketplace of human tutors, and RAITHub has not shipped one.