A tutoring marketplace MVP launched in nine weeks, not six months
A first-time founder had a 40-item feature list, a fixed budget, and customers waiting. We scoped the list to five items that could take money, and launched a working marketplace in nine weeks.
- Client
- A first-time founder launching a tutoring marketplace
- Industry
- Education technology, 2 founders
- Engagement
- 9 weeks, then a monthly retainer
- Published
Note.Client name is anonymized and figures are illustrative until publication is approved.
- 9 wks
- From first call to public launch
- 140
- Bookings taken in the first month
- 0
- Deferred features that needed a rewrite when added
Business context
The client is a first-time founder building a tutoring marketplace. She had a list of 40 features, a fixed budget, and a group of tutors and parents who had already said they would use a first version. Two agencies had quoted six-month builds that the budget could not cover. The work was MVP development for startups at its most constrained: one budget, one launch, and no room to carry unused features.
She asked us to get a working product live and take payments. Her words were "something real, not a demo."
The problem
The feature list was the problem. Reviews, in-app chat, mobile apps, a tutor rating system, video lessons, and a subscription plan all sat at the top of her notes. Each one sounded reasonable on its own. Together they described a two-year product, not a first launch.
The risk was not technical. It was spending the whole budget on features and having nothing to show users. The marketplace also had a cold-start question: with no tutors signed up, parents had nothing to book.
What we built
We built the launch on Next.js as a web app development project and cut the list to the smallest set that could take money: tutor profiles, availability, booking, payment with a platform fee, and email notifications. Everything else went into a written "out of scope" list with a reason and a rough cost for later. That page did more to focus the build than any other part of the proposal.
Tutor profiles and availability
Each tutor has a profile page, subjects, rates, and a weekly availability calendar. The founder adds tutors herself for the first version, so there is no self-serve onboarding to build yet.
Booking and payment
A parent picks a tutor, a slot, and a subject, then pays a deposit through Stripe. The platform keeps a fee, and the rest is scheduled for payout after the lesson. Cancellations follow one simple rule, written on the booking page.
Email notifications
Both sides get a confirmation, a reminder 24 hours before the lesson, and a note when a lesson is marked complete. This is plain email; there is no chat.
Rollout
- Week 1: Scope workshop. We turned the 40-item list into a launch list and an out-of-scope list.
- Weeks 2 to 5: Building profiles, availability, and bookings.
- Weeks 6 to 7: Payments, payouts, and notifications, tested with real Stripe test data.
- Weeks 8 to 9: Onboarding the first ten tutors and running five test bookings end to end then launching to the waitlist.
Before and after
| Item | Before | After |
|---|---|---|
| Timeline | Two agency quotes of 6 months | Live in 9 weeks |
| Feature list | 40 items, no order | 5 launch items, 35 deferred |
| Payments | Manual invoices | Stripe with an automatic platform fee |
| Scope changes | Unbounded | Each addition weighed against the launch list |
Results
The marketplace launched nine weeks after the first call. In the first month it took 140 bookings from the founder's waitlist, and the platform fee covered its own running costs from month two.
None of the features added after launch needed a rewrite. The data model for tutors, availability, and bookings was designed for the deferred features even though the screens were not built. That meant adding reviews later was a new page and a small table, not a rebuild.
The clinic booking work we did earlier followed the same lesson: an online booking portal for a physiotherapy clinic worked because we designed for reception staff, not just patients. The founder spent her remaining budget on tutor recruitment instead of more features.
Lessons learned
- The "out of scope" list was the most useful page of the proposal. It turned arguments about features into a comparison against a fixed launch list.
- The founder nearly added chat in week six. We showed her that the first version had no tutor-to-parent conversation to support, and the feature would sit empty. She agreed and put the budget into tutor recruitment.
- We underestimated payment payouts. Splitting a payment and scheduling a later payout took a full week, and the first test run hit a Stripe rule we had not read. It worked, but the schedule slipped by three days.