What I Learned Scoping a Tutor App From Scratch

Last year I helped a client scope out a tutoring marketplace from zero. They had a clear idea connect students with tutors, handle bookings, run video sessions, take a cut of payments. Simple enough on paper.

Six weeks into the project we were still debating the data model for availability slots.

Here's what actually caught us off guard:

Scheduling is the hard part, not the video. Everyone worries about WebRTC and video quality. The real complexity is availability logic recurring slots, exceptions, timezone mismatches between tutors and students, and booking conflicts when two students hit "confirm" at the same second. We ended up using Redis locks just to handle that last case reliably.

Stripe Connect is non-negotiable for marketplaces. If tutors are getting paid, you need Connect. Rolling your own payout logic is a legal and compliance rabbit hole. Connect handles KYC, cross-border transfers, and tax reporting out of the box. Just use it.

The admin panel takes longer than the product. Dispute resolution, manual refunds, tutor verification, session monitoring none of this is glamorous but all of it blocks you from launching without it.

Build vs. outsource is a real question at this scope. A tutor platform isn't a CRUD app. Between scheduling, video, payments, notifications, and role logic, the surface area is wide. Some teams are better off working with a specialized tutor app development services provider for the first version, then taking it in-house once the architecture is proven.

If you're starting something similar happy to answer questions in the comments. Specifically around the scheduling model, it took us three iterations to get right.