How to Build a Tutoring Marketplace Platform

Building a tutoring marketplace means building two products at the same time. One for students and parents searching for help. One for tutors managing their schedule and income. Both must work well or neither side shows up.

This is what makes marketplace development cost more and take longer than a single-sided app. You are not building one user flow. You are building six interconnected systems that serve two different audiences with competing incentives.

Here is the architecture behind each one.

What the platform does on both sides

The online tutoring market was valued at $8.7 billion in 2023 and is projected to reach $15 billion by 2028, growing at roughly 12% annually. That growth is driven by a simple dynamic: students want personalized help and parents want results, but supply is local and pricing is inconsistent. A marketplace solves both problems by aggregating verified tutors and standardizing the booking and payment experience.

For students and parents: search for tutors by subject, grade level, availability, and price. Review tutor profiles with ratings, credentials, and sample sessions. Book a session, pay via credit card, join a video session at the scheduled time, and receive session notes afterward.

For tutors: complete a profile with subjects, grade levels, hourly rate, and availability. Pass a background check and credential verification. Accept or decline booking requests. Join video sessions. Write post-session notes. Receive monthly payouts via direct deposit.

For the platform operator: earn a 15-25% commission on each session. Monitor tutor verification status. Review disputes. Track session completion rates and payout records.

These three user types share one database but have very different views of it.

MVP vs. full platform

An MVP ships with the core booking and payment loop:

• Tutor profiles with subject, grade level, rate, and basic availability

• Search and filter by subject and availability

• Booking flow with Stripe Connect payment hold

• Video sessions via Daily.co embedded room

• Post-session notes by the tutor

• Star rating and text review from the student

A full platform adds:

• Background check integration via Checkr

• Credential document upload and verification queue

• Weighted ranking algorithm (not just filter-based search)

• Whiteboard and screen sharing in the session room

• Progress reports across multiple sessions

• Mobile app for parents and tutors

• Tutor response rate and acceptance rate tracking

• Automated re-booking suggestions based on past sessions

Ship the MVP with 20 tutors in a single niche. Prove the booking loop works before building credential verification infrastructure.

Core architecture

Tutor profiles and verification

A tutor profile has two parts: the public listing (subject tags, grade levels, bio, hourly rate, ratings, sample session video) and the verified fields (background check status, credential documents, identity confirmation).

Search results only show tutors whose verification_status = 'approved'. Tutors with pending verification can see their profile in draft mode but don't appear in search.

Background checks connect to Checkr via API. The flow: tutor completes profile, your system calls POST /v1/invitations on the Checkr API with the tutor's name and email, Checkr sends the tutor a link to submit their information, and your system receives a webhook with the result (clear/consider/suspended). The result updates tutors.background_check_status in your database.

Credential verification is simpler: tutors upload a file (degree scan, teaching certificate), your system stores it in S3, and a staff member reviews it in an admin queue. Approved uploads flip tutors.credentials_verified = true.

Booking engine with calendar sync

The booking flow has three states: requested, confirmed, and completed.

Requested: student picks a tutor and a time slot. The system checks tutor availability (stored as a weekly recurring schedule with individual exceptions). If the slot is open, a booking record is created with status requested and a payment hold is placed via Stripe.

Confirmed: the tutor accepts the request (or the system auto-confirms if the tutor has instant-book enabled). The Stripe payment hold is authorized but not captured. The Daily.co room is created and the room URL is stored on the booking record.

Completed: after the session end time, the system marks the booking completed and captures the payment. The tutor payout is triggered. If either party disputes the session, a manual review holds the payout.

Use a database-level unique constraint on (tutor_id, start_time) to prevent double bookings. Use a short-lived Redis lock during the booking creation request to handle race conditions when two students try to book the same slot simultaneously.

Stripe Connect for payment escrow

Stripe Connect is the correct tool for marketplace payment flows. It handles the legal and financial complexity of holding and routing money between three parties.

The setup:

1. Each tutor onboards as a Stripe Express account. Stripe handles their identity verification and bank account collection. Your system stores their stripe_account_id.
2. When a student books a session, they pay via a standard Stripe payment method. The charge is created with a transfer_data.destination pointing to the tutor's Express account and a transfer_data.amount equal to the session fee minus your commission.
3. Stripe holds the transfer until you trigger it. You trigger it when the booking status becomes completed.
4. Your commission stays in your platform Stripe account automatically.

This three-party escrow pattern protects students (payment is held, not sent, until the session happens), protects tutors (payment is guaranteed once the session completes), and protects your platform (you control the release trigger).

Don't build a custom escrow system. Stripe Connect exists for this use case and handles the financial regulation complexity you don't want to manage yourself.

Embedded video sessions

Create a Daily.co room when a booking is confirmed. Daily.co's API takes 200ms to provision a room with a unique URL. Store the URL on the booking record.

Show a "Join session" button on the booking detail page starting 15 minutes before the scheduled start time. Both the student and tutor get the same room URL. Daily.co handles the video routing, media permissions, and connection quality degradation gracefully.

After the session end time plus a 10-minute buffer, mark the booking completed and trigger the Stripe payout. Don't rely on users clicking "end session." Use the scheduled end time as the source of truth.

For whiteboard integration, embed Tldraw in an iframe alongside the video frame. Both share the same booking ID as a room identifier. Tldraw's collaborative canvas syncs in real-time via WebSockets without additional backend code.

Screen sharing works natively in Daily.co. No additional integration needed.

Session notes and progress tracking

After each session, the tutor gets a post-session form: what was covered, what homework was assigned, what to focus on next time. This fills in as a session_note record linked to the booking.

Parents see session notes in their portal. Over time, multiple notes for the same student-tutor pair form a progress timeline. This is one of the strongest retention levers. Parents who see progress notes book more sessions.

Keep the note form simple: 3 fields, all optional (topic covered, next steps, homework). Tutors who are required to fill in long mandatory forms skip it or copy-paste from last session.

The hardest problem: the ranking algorithm

A parent searches for "Algebra 2, grade 10, test in 3 weeks, $40-$60 per hour, available Tuesdays after 5pm."

A filter query returns 200 tutors who match those fields. A ranked result returns 10 that will convert to bookings.

"In two-sided marketplaces, the ranking algorithm is the product. You can have thousands of supply-side listings and still fail if the matching quality is poor. The platforms that win are the ones that surface the right fit, not just any fit." -- Andrei Hagiu, Professor at Boston University Questrom School of Business and two-sided marketplace researcher, from his published work on marketplace design.

The difference is a weighted scoring function. Here is how to build one:

Score each tutor on five signals:

1. Subject expertise depth (0-30 points): does the tutor list Algebra 2 specifically, or just "Math"? Specific subject match scores higher. Tutors with 10+ reviews on that subject score higher than tutors with one review.

2. Availability overlap (0-25 points): does the tutor have open slots on Tuesdays after 5pm in the next 3 weeks? Score decreases as available slots decrease.

3. Price fit (0-20 points): tutors priced in the middle of the requested range ($48-$52 in a $40-$60 range) score higher than tutors at the edges. Tutors at $39 or $61 score zero.

4. Review score weighted by volume (0-15 points): a 4.8 rating from 25 reviews scores higher than a 5.0 rating from 2 reviews. Use a Bayesian average: (reviews * rating + C * prior) / (reviews + C) where C is a constant (typically 5-10) and prior is the platform average rating.

5. Response rate and acceptance rate (0-10 points): tutors who respond to requests within 2 hours and accept 85%+ of bookings score higher. This predicts session reliability.

Sum the scores. Sort by total score descending. Return the top 10 results.

This is not machine learning. It is a transparent scoring function with tunable weights. You can adjust the weights based on which signals correlate with completed bookings once you have data. Start with these weights, ship, and iterate.

Store tutor scores as a precomputed column in the database, updated nightly and on each new review. Don't compute scores at query time for every search.

Use Algolia for the search layer. Algolia handles the subject text matching and geographic radius filtering fast. Your ranking function runs on the result set Algolia returns, not on the full database.

Timeline and cost

MVP (tutor profiles, booking, Stripe Connect, video sessions, basic search, reviews):

• Timeline: 16-22 weeks

• Team: 2 senior backend, 2 frontend, 1 designer

• Cost: $160,000-$260,000

• Running cost: $1,500-$4,000 per month (Stripe fees, Daily.co, Checkr, Algolia, hosting)

Full platform (MVP plus Checkr integration, credential verification, whiteboard, weighted ranking, mobile app, progress reports):

• Timeline: 28-36 weeks

• Team: 3 senior backend, 2 frontend, 1 mobile, 1 designer

• Cost: $300,000-$500,000

• Running cost: $3,000-$8,000 per month

The cost range is wide because marketplace complexity scales with niche depth. A STEM-focused marketplace with strict credential requirements costs more to build than a general tutoring platform with lighter verification.

Build vs. buy

Three platforms dominate the tutoring marketplace space:

Wyzant takes 25% commission on every session. For a student booking a $60/hour tutor, Wyzant earns $15 and the tutor earns $45. If you are the platform owner building your own marketplace, that 25% is your addressable revenue.

Tutor.com and Varsity Tutors are both fully managed services with their own tutor supply. They are not white-label software you can run under your brand.

Build custom when:

• You are targeting a specific niche (SAT prep, ESL for adult learners, STEM for K-8) where you can own the supply side

• Your commission model is 15-20% and you can undercut Wyzant on tutor earnings to attract better tutors

• You want to own the data, the relationships, and the platform economics long-term

• You are building in a specific geography where English-language platforms have weak supply

Don't build a general tutoring marketplace to compete with Wyzant on every subject at every grade level. You will spend $300K to build something that competes with a $100M platform on their home turf. Niche down first.

Tech stack

Backend: Node.js with PostgreSQL for the core data model. Redis for session locks and tutor availability caching. Algolia for search indexing and subject text matching.

Frontend: React for the web app. React Native for the mobile app (shares the same API). FullCalendar.io or a custom availability grid for the tutor calendar UI.

Payments: Stripe Connect with Express accounts for tutor onboarding and payout routing.

Video: Daily.co for embedded video rooms and screen sharing. Tldraw for collaborative whiteboard.

Background checks: Checkr API for tutor background verification. Persona or Stripe Identity for document verification.

Email: SendGrid for booking confirmations, session reminders, payout notifications, and review requests.

Infrastructure: Vercel for the web frontend. AWS for the API and database (RDS PostgreSQL with read replicas for search-heavy queries). CloudFront for S3-hosted tutor profile images and uploaded credential documents.

What to build first

Start with the booking loop: tutor profile, availability calendar, booking request, Stripe Connect payment hold, and session confirmation. Get this working end-to-end with a manual payout process before you automate anything.

Once the booking loop works, add video sessions. This is your core product moment. If a student can find a tutor, book a session, join a video call, and pay without leaving your platform, you have a working marketplace.

Everything else (credential verification, ranking algorithm, whiteboard, progress reports) is iteration on top of that core loop.

According to Stripe's developer documentation on Connect, the platform-to-recipient escrow pattern is the standard for compliant marketplace payouts, and Stripe Express onboarding handles KYC, tax forms, and bank account collection automatically.

RaftLabs has shipped two-sided marketplaces with complex matching logic and payment flows. If you are building a tutoring platform or a service marketplace with credential requirements, talk to us about your architecture.