ADPList was built on free, one-off mentorship. It worked for acquisition – but altruism only goes so far. By mid-2023, mentors were off-ramping to private coaching and mentees were churning without transformational career outcomes. The platform had built trust but wasn't converting it into depth.
ADPList Advance was the strategic bet – a shift from volume to depth. Productise recurring, paid mentorship so mentors had a path to professionalise and mentees had a path to real outcomes.
The design challenge wasn't just building a payment flow — it was making monetisation feel like a natural evolution of the community, not a contradiction of it.
ADPList - a global mentorship platform with 32,000 mentors across 140 countries.
Mentors were giving time freely – but a single session with no recurring option made it impossible to build ongoing relationships. Engagements were moving off-platform to manage recurring logistics. Additionally, without any payment time was taken for granted and no-shows were common.
Mentees reported high satisfaction but low career outcome rates. 90-day churn was high because the platform couldn't deliver the outcome.
Part of the problem was discoverability as mentees didn't know rebooking the same mentor was possible as they couldn't make another booking while having one active.
The booking experience was built for one-off sessions with single session on their profile. The infrastructure had to evolve first, in phases, before paid sessions were even technically possible.
Hypothesis
Strategy
The research was clear – mentees would pay more for reliable, long terms results than for uncertain short term fixes. That alignment, from price sensitivity to outcome sensitivity, guided the entire design direction.
By the time paid sessions launched, mentors already knew how to manage multiple session types and the infrastructure had been tested in production. Advance was the third phase, not the first.
Phase 1
Introducing Multiple One-Off Sessions
Mentors could offer more than one type of session on a single profile – portfolio review, career chat, interview prep — giving mentees clearer choices and mentors more flexibility.
Phase 2
Adding Recurring as a Native Session Type
Recurring sessions were introduced alongside one-off on the same profile. Mentors could offer both without separate tools or workarounds – the first time the platform supported ongoing engagement natively.
Paid for Outcomes, Free for Discovery
Commitment
Paid sessions were recurring only – deliberately
One-off paid sessions would have replicated the same transactional dynamic. Recurring sessions created a relationship arc that changed behaviour — mentors prepared differently, mentees showed up differently.
Accessibilty
Free Sessions Were Non-Negotiable
Paid couldn't exist without free on the same profile. Remove free and ADPList becomes just another coaching marketplace. Keeping free as the entry point protected the community promise.
Session Templates That Removed the Guesswork
Mentors knew their expertise but didn't know how to package it. Templates gave them a starting point – predefined session types with suggested durations, scope, and pricing – so they could go live without having to figure out every variable from scratch.
Paid Mentorship, Discoverable on Demand
Defaulting to paid would have changed the feel of the platform overnight and alienated the community ADPList was built on. The toggle gave mentees who were ready for paid mentorship a way to find it without making it the dominant experience for everyone else.
Trade-offs
US-focused Beta Launch – Control Over Coverage
We launched with 90–100 US mentors who met strict criteria – 100+ sessions, 3+ months on ADPList, 80%+ attendance, 35+ reviews. Top ~1% validated the product and kept the codebase stable.
Stripe doesn't support mentor payouts in 50+ countries. I explored Razorpay for India – 2nd largest mentor base – but hit two blockers:
engineering estimated a 2-month delay to build a custom Razorpay bridge
the integration itself required official registration in India, adding another 3+ weeks minimum
Mentees could pay regardless of their country – the payment side worked everywhere.
Mentor no-shows post payment created a problem engineering wasn't ready to solve. Building automated refunds would have added complexity to a system already carrying too many bugs. We handled refunds manually through CS via Intercom in V1.
Impact
The numbers below aren't feature adoption metrics. They're signals that the shift from volume to depth actually worked.
Post-Launch Iterations
For over two years, mentors raised a similar question in 200+ Intercom conversations – why isn't my availability showing?
The calendar preview finally solved it. Mentors could see exactly when they were open for bookings, and real-time conflict alerts flagged clashes with existing calendar events or settings.
Global and Session-Level Calendar Settings
After launch, we refined the calendar settings architecture based on how mentors were actually using it. Booking questions and availability remained session-level, so mentors could tailor each session type independently.
Settings that applied universally – timezone, auto-accept, notice period, booking limits, buffer time, video call integration, and override all-day events – stayed global, so mentors didn't have to repeat configuration.
Reflections
