Product Requirements

This PRD translates MentorLoop's Strategy and Personas work into a build-ready v1 specification for a two-person team — one technical co-founder and one part-time contract designer — shipping inside four months with no engineering co-founder. Every requirement below is scoped against that constraint first: if a feature cannot be justified against the core loop (a founder finds a vetted mentor, books an hour, pays, and the mentor gets paid), it is named explicitly in Scope as deferred, not silently dropped.

Overview & Goals

MentorLoop is a two-sided marketplace web application connecting early-stage hardware and deep-tech founders (pre-seed through Series A, concentrated in Boston, the Bay Area, Munich, and Stuttgart) with retired and semi-retired engineers and manufacturing/operations leaders who hold deep domain expertise in design for manufacturability (DFM), supply-chain qualification, EMC/safety certification (UL, CE, FCC), and contract-manufacturer tooling negotiation. Founders search or browse mentor profiles by expertise domain, book a paid hourly session with a specific named mentor, and pay through the platform; mentors set their own rate and availability and receive payout after each completed session, net of MentorLoop's 20% platform fee. v1 is web-only, launching first in the US and Germany, and exists to prove one thing: that a structured, vetted, paid booking marketplace for this specific expertise gap can generate real, repeat, two-sided transaction volume — not just sign-ups on either side.

This v1 must achieve three goals, each directly load-bearing for the go/no-go decision on building the Structured Track package and expanding beyond two markets:

1. Prove the core transaction loop end to end. A founder must be able to discover a relevant mentor, book them, pay for the session, and (post-session) leave a review, with zero manual intervention from the MentorLoop team for a booking that goes smoothly. Manual intervention should only ever be required for the exception paths (vetting, disputes), not the happy path.
2. Prove mentor supply-side activation, not just sign-up. It is not enough for retired engineers to create a profile; v1 must show that a meaningful share of approved mentors actually set live availability and accept at least one real booking within their first 60 days on the platform — the single biggest unproven assumption from the Idea Brief's own Key Assumptions section.
3. Prove the platform can operate its own exception paths at this team's actual capacity. With one technical founder and no dedicated ops hire, mentor vetting and dispute handling must be operable by a single person in well under an hour per case, or the model does not survive past the first few dozen bookings.

Everything in this document is designed to make those three goals measurable within 90 days of launch, not to build every feature the long-term vision implies (see the Structured Track and other deferred items below).

Scope (In / Out for v1)

In scope for v1:

• A responsive web application (no native mobile app) serving both founder and mentor sides from one codebase, usable on desktop and mobile browsers.
• Mentor application intake: a structured form (claimed employer history, years of experience, specific technical domains, a free-text description of representative hardware problems solved, and at least one professional reference contact) that a human admin reviews manually before approval.
• A public mentor profile page: bio, named former employer(s) and years of experience, listed expertise tags, hourly rate, aggregate star rating, and published reviews, visible to any logged-in founder.
• Founder-side search and filtering by expertise domain (DFM, supply chain, certification, tooling negotiation, and a small fixed initial tag set), geography/timezone, and price range.
• Mentor-set weekly recurring availability (with the ability to block off individual dates) and a single hourly rate per mentor (no tiered or per-topic pricing in v1).
• A booking flow in which the founder selects an open slot, provides a short free-text note on what they need help with, and pays the full session price at time of booking via Stripe Connect.
• Session delivery via an external video link (Zoom, Google Meet, or Microsoft Teams) that the mentor attaches to the confirmed booking — MentorLoop does not build or host its own video conferencing in v1.
• Post-session reviews: a 1-5 star rating plus optional text comment from the founder, published to the mentor's profile after a lightweight moderation pass (auto-published, with a "report this review" flag any user can raise, reviewed manually).
• Automatic mentor payout via Stripe Connect (Standard accounts) 48 hours after a session's scheduled end time, provided no dispute has been filed in that window.
• A manual admin console (a role-gated section of the same web app, not a separate product) for reviewing mentor applications, viewing flagged reviews, and resolving disputes/no-shows by hand.
• Automated email notifications for the core lifecycle events: booking confirmed, booking reminder (24 hours and 1 hour before), session marked complete, payout sent, mentor application approved/rejected.

Explicitly out of scope for v1, and why:

• No native mobile app. The responsive web app covers both sides of the marketplace at a fraction of the engineering cost; there is no evidence yet that either founders or retired mentors need a native app experience to complete a booking, and building one would roughly double the surface area a one-person engineering team must maintain inside a 4-month window.
• No Structured Track package. The $4,000, four-mentor, 90-day curated roadmap requires multi-mentor scheduling coordination, milestone tracking, and a packaged-curriculum UI that don't exist yet, and depends on first proving that even a single mentor-founder hourly match works reliably. Building it before the core loop is validated would risk a large, complex feature nobody has proven demand for yet. Fast-follow, targeted for the first major release after v1's 90-day data is in.
• No automated mentor-quality scoring. At the expected launch volume (a first cohort of roughly 20-30 mentors), a scoring model has no training data to learn from and would add a false sense of rigor to what is, in practice, a small, high-touch manual review. Vetting is 100% manual in v1; automated scoring is revisited only if application volume grows past what one person can review in a reasonable turnaround time.
• No in-platform video conferencing. Building reliable, recorded, screen-share-capable video infrastructure is a multi-month effort on its own; routing sessions through an external tool the mentor already uses (nearly universal at this demographic) is a deliberate, explicit trade of polish for shipping speed.
• No in-platform messaging or chat between founder and mentor before a booking is confirmed. The structured "what do you need help with" note captured at booking time is the only pre-session communication channel in v1. A full messaging system invites scope creep (read receipts, notifications, spam/abuse handling) that the core loop does not need to function.
• No algorithmic/ML-based mentor matching. Founders use manual search and filters only. There is nowhere near enough booking data at launch to train or even meaningfully hand-tune a recommendation system, and a simple, transparent filter UI is easier for a founder to trust than an opaque "we matched you" black box on a marketplace this new.
• No markets beyond the US and Germany, and no currencies beyond USD and EUR. Expanding geography multiplies vetting complexity (different professional credentialing norms, different payout/tax regimes) faster than it multiplies usable supply or demand at this stage.
• No public API or third-party calendar/CRM integrations beyond a basic per-booking .ics calendar-file download. Two-way calendar sync (Google Calendar, Outlook) is a real mentor convenience but not a blocker to completing a booking, so it is deferred.
• No automated tax-form generation (US 1099-NEC, EU VAT invoicing). At an expected mentor count well under 50 in the first 90 days, the founder can handle this manually or via Stripe's built-in reporting tools where available; automating it is a fast-follow once mentor volume makes manual handling genuinely burdensome.
• No dedicated in-app dispute/arbitration workflow. v1's dispute handling is a "report an issue" button on a booking plus a manual admin review (email or call, with a free-text resolution note logged against the booking) — not a structured evidence-upload or multi-party arbitration UI. This matches the team's actual capacity to operate exceptions personally at launch volume.

User Stories & Acceptance Criteria

US-1: As a founder, I want to search and filter mentors by expertise domain, geography, and price range, so that I can quickly find someone who has actually solved my specific problem instead of scanning a generic list of advisors.

• Search results can be filtered by at least the following expertise tags: DFM, supply chain, certification (UL/CE/FCC), tooling negotiation, and fundraising-for-hardware.
• Filtering by geography/timezone and by hourly rate range narrows the result set without a full page reload.
• A search or filter combination that matches zero mentors shows a clear empty state rather than an error or a blank page.
• Each result card shows the mentor's name, headline (former employer + years of experience), hourly rate, and average star rating without requiring a click-through.

US-2: As a founder, I want to view a mentor's full profile, including their real background and past reviews, before booking, so that I can trust the person on the other end has actually shipped what they claim to have shipped.

• The profile page displays the mentor's named former employer(s), years of experience, a bio, listed expertise tags, hourly rate, and all published reviews with star ratings.
• The profile shows the mentor's current availability at a glance (e.g., "next opening: Thursday 2pm ET") without requiring the founder to open the booking flow first.
• A mentor with zero reviews yet shows "New to MentorLoop" rather than a blank or zero-star rating that could read as a bad signal.

US-3: As a founder, I want to book a specific available time slot with a mentor and pay for the session in one flow, so that the booking is confirmed and paid without a separate invoicing step.

• The founder can select any slot the mentor has marked open, add a required free-text note describing what they need help with (minimum 20 characters), and proceed to payment in the same flow.
• Payment is collected via Stripe Connect at the time of booking; the booking only moves to "confirmed" status after payment succeeds.
• The selected slot is locked (removed from availability for any other founder) the moment payment succeeds, preventing two founders from booking the same slot.
• The founder receives an immediate on-screen confirmation and a confirmation email containing the date, time, mentor name, and the external video link once the mentor has attached one.

US-4: As a founder, I want to leave a rating and written review after a completed session, so that future founders get an honest signal about this mentor and the mentor gets recognized for a good session.

• The review prompt (star rating 1-5, optional text) becomes available only after the booking's scheduled end time has passed.
• A submitted review is published to the mentor's public profile and included in their average rating calculation.
• A founder can submit at most one review per booking, and cannot edit the star rating after submission (a one-time text edit within 24 hours is allowed for typo correction only).

US-5: As a founder, I want to report a no-show or a session that went badly, so that I have real recourse instead of just losing the money and never using the platform again.

• A "Report an issue" action is available on any completed or missed booking for 7 days after its scheduled end time.
• Reporting an issue creates a dispute record visible in the admin console and pauses that booking's mentor payout until the dispute is resolved.
• The founder receives an email acknowledging the report within the same flow (not a separate manual step), stating that a human will follow up within 2 business days.

US-6: As a retired engineer, I want to apply to become a mentor by submitting my background and credentials, so that I can be considered for a platform whose entire value depends on real, verifiable expertise.

• The application form requires: full name, contact email, at least one named former employer with years of experience there, a free-text description of hardware/manufacturing problems solved, requested expertise tags, requested hourly rate, and at least one professional reference contact (name + email or phone).
• The application cannot be submitted with any required field empty, and the applicant sees a clear confirmation that their application was received and is under review.
• An incomplete or abandoned application is saved as a draft the applicant can return to, rather than being lost.

US-7: As an approved mentor, I want to build a public profile with my real background, so that founders can evaluate my credibility before booking me.

• Only mentors whose application has been approved by an admin can access profile-editing and publish a live, bookable profile.
• The profile editor lets the mentor edit their bio, expertise tags (from the approved list), hourly rate, and profile photo after initial approval, without requiring a new admin review for routine edits.
• Changing the named former employer(s) or years-of-experience fields after initial approval flags the profile for a lightweight admin re-check before the change goes live, since those are the fields founders rely on most for trust.

US-8: As an approved mentor, I want to set my weekly availability and my hourly rate, so that founders can only book time I have actually agreed to give.

• The mentor can define a recurring weekly availability pattern (e.g., "Tuesdays and Thursdays, 2pm-5pm, America/New_York") and block off individual dates as exceptions.
• The mentor can set and update their hourly rate at any time; a rate change only applies to future bookings, never retroactively to an already-confirmed one.
• Availability is always stored and reasoned about in UTC internally and displayed to both the mentor and any founder in each user's own local browser timezone.

US-9: As an approved mentor, I want to review and accept (or decline) an incoming booking request before it's fully confirmed, so that I retain control over who I actually agree to meet with.

• Every new booking request initially transitions the mentor's slot into a "pending mentor acceptance" state, visible as such on the mentor's dashboard, rather than confirming immediately on payment alone.
• A mentor can decline a booking request within 24 hours of it being placed; declining triggers an automatic full refund to the founder and reopens the slot.
• If a mentor takes no action within 24 hours, the booking auto-confirms — a mentor cannot let a request silently expire and leave the founder in limbo.
• The mentor receives an immediate notification (email) for every new booking request.

US-10: As an approved mentor, I want to be paid automatically after I complete a session, so that I don't have to invoice founders myself or chase payment.

• A completed session (scheduled end time has passed with no dispute filed) triggers an automatic payout of the session price minus MentorLoop's 20% platform fee, via Stripe Connect, 48 hours after the scheduled end time.
• The mentor can view a running payout history (completed, pending, and disputed-and-held amounts) on their own dashboard at any time.
• A mentor whose Stripe Connect account is not fully verified/enabled cannot have a live, bookable slot — the system blocks publishing availability until payout setup is complete.

US-11: As a platform admin, I want to review and vet a new mentor application against clear criteria, so that only founders and mentors with real, verifiable hardware/manufacturing expertise appear on the platform.

• The admin console lists all pending applications with the applicant's claimed background, requested expertise tags, and reference contact, sortable by submission date.
• The admin can approve, reject, or request more information on an application, and any rejection requires a free-text reason that is included in the applicant's notification email.
• Approving an application immediately unlocks profile-editing and availability-setting for that mentor; rejecting it does not delete the application record (kept for potential future resubmission).

US-12: As a platform admin, I want to review and resolve a reported dispute or no-show, so that both sides of a bad session get a fair, timely outcome instead of an unresolved complaint.

• Every open dispute appears in a dedicated admin queue with the booking details, the reporting party's account, and their written explanation.
• The admin can resolve a dispute with one of: full refund to founder, partial refund to founder, pay mentor in full, or no action — each resolution requires a short note and is logged against the booking permanently.
• Resolving a dispute automatically releases or reverses the held mentor payout according to the chosen resolution, without a separate manual Stripe action.

US-13: As a platform operator, I want the system to automatically deduct MentorLoop's 20% platform fee from every completed booking's payment, so that revenue is captured reliably without manual invoicing or reconciliation work.

• Every booking payment is split at the payment-processing level (Stripe Connect application fee) into an 80% mentor portion and a 20% platform portion at the moment of payout, not calculated separately after the fact.
• The platform fee amount is visibly itemized to the founder at checkout (e.g., "Session: $200 · Platform fee included") so pricing is never a surprise.
• A finance-facing report (even a simple exportable table in the admin console) shows total gross booking volume, total platform fee revenue, and total mentor payouts for any selected date range.

Functional Requirements

Search & discovery

• FR-1: The system must support filtering mentor search results by one or more expertise tags drawn from a fixed, admin-managed tag list (initial set: DFM, supply chain, certification, tooling negotiation, fundraising-for-hardware).
• FR-2: The system must support filtering by hourly rate range (e.g., under $150, $150-200, $200+) and by mentor timezone/region (US or Germany at launch).
• FR-3: Search results must load within 2 seconds under normal load for a catalog of up to 500 mentors, and must degrade gracefully (a loading state, never a blank page) beyond that.

Booking & scheduling

• FR-4: The system must prevent double-booking of the same mentor time slot through a database-level uniqueness constraint on (mentor_id, slot_start_time), not application-logic checks alone.
• FR-5: A booking request must transition through exactly these states: requested → confirmed (on successful payment and, once implemented, mentor acceptance) → completed, or requested → cancelled (declined by mentor, or payment failure), or confirmed → disputed → resolved.
• FR-6: The system must send an automated reminder email to both founder and mentor 24 hours and 1 hour before a confirmed session's start time.
• FR-7: A mentor must be able to attach or update an external video meeting link on a confirmed booking up until its scheduled start time; the founder must be notified by email the moment a link is added.

Payments & payouts

• FR-8: All payment collection must use Stripe Connect (Standard connected accounts for mentors); no raw card data may be transmitted to or stored on MentorLoop-owned infrastructure at any point.
• FR-9: The platform fee must be calculated as exactly 20% of the session's listed price, deducted as a Stripe Connect application fee at the time of transfer, not as a separately invoiced amount.
• FR-10: A mentor payout must be automatically initiated 48 hours after a booking's scheduled end time, unless a dispute has been filed against that booking, in which case the payout is held until the dispute is resolved by an admin.
• FR-11: A mentor-declined or system-cancelled booking must trigger a full automatic refund to the founder's original payment method within the same business day.

Mentor onboarding & profiles

• FR-12: Mentor applications must capture, at minimum: name, contact email, at least one named former employer and years of experience there, a free-text expertise narrative, requested expertise tags, requested hourly rate, and one professional reference contact.
• FR-13: Only an admin-approved application may unlock a live, publicly bookable mentor profile; there is no self-service publish path.
• FR-14: A change to a mentor's named employer history or claimed years of experience after initial approval must flag that profile for admin re-review before the change is publicly visible.

Reviews

• FR-15: A review may only be created against a booking whose scheduled end time has passed, by the founder who made that booking, and at most once per booking.
• FR-16: A mentor's displayed average rating must be recalculated whenever a new review is published or an existing review is removed by moderation.

Admin & vetting

• FR-17: The admin console must present a queue of pending mentor applications and a separate queue of open disputes, each sortable by age (oldest first, default).
• FR-18: Every admin resolution action (application approve/reject, dispute resolution) must be logged with the admin's identity, the action taken, a free-text note, and a timestamp, retained permanently for accountability.

Notifications

• FR-19: The system must send transactional emails for: booking confirmed, booking declined/refunded, session reminders (24h/1h), session completed (review prompt), payout sent, mentor application approved, mentor application rejected, and dispute filed/resolved — each independently, so a failure sending one notification type must not block any other.

Non-Functional Requirements

Payment security & PCI scope. All card and bank-account handling must go through Stripe Connect and Stripe's own hosted payment elements (Stripe Checkout or Stripe Elements); MentorLoop's own servers must never receive, process, log, or store raw payment card data. This keeps MentorLoop's own PCI-DSS compliance obligation at the lowest applicable tier (SAQ A), since card data never touches infrastructure MentorLoop controls. Stripe API keys must be stored as encrypted secrets, never committed to source control, and the webhook endpoint that receives payment-status events must verify Stripe's signature on every request before acting on it, to prevent forged payment confirmations.

Data privacy & GDPR. Both sides of the marketplace include EU data subjects — German founders and German mentors are an explicit, named launch market, not an edge case — so GDPR applies to the full system from day one, not just to a future EU expansion. Concretely: (1) the mentor application form must collect only the data actually needed for vetting (name, background, references, expertise) and must not request unrelated personal data "in case it's useful later"; (2) both founders and mentors must be able to request an export of their own data and request account deletion, with deletion actually removing personally identifying fields rather than merely hiding the account, while preserving the minimum transaction/financial records required for tax and accounting law; (3) a signed Data Processing Agreement must be in place with every vendor that touches personal data (Stripe, the email-sending provider, the hosting/database provider) before launch; (4) session recordings are out of scope for v1 specifically because MentorLoop does not host video, which sidesteps a significant category of sensitive-data handling that would otherwise require its own consent and retention policy.

Performance targets. Mentor search and profile pages must return a server response in under 500ms at the p95 percentile under expected launch load (fewer than 100 concurrent users). The booking calendar view for a given mentor must reflect a just-completed booking by another founder within 5 seconds, to make the double-booking-prevention guarantee (FR-4) visible to the user in near-real time, not just correct at the database level.

Availability. The platform should target 99.5% uptime in its first 90 days (roughly 3.6 hours of allowed downtime per month) — a deliberately modest target reflecting a single-engineer team without a dedicated on-call rotation, revisited upward once booking volume makes downtime costlier than the operational overhead of a stricter SLA.

Auditability. Every state transition on a Booking (requested, confirmed, completed, cancelled, disputed, resolved) and every financial transaction (payment captured, fee deducted, payout sent, refund issued) must be recorded with a timestamp and never physically deleted, since real money and potential disputes depend on a reconstructable history months after the fact.

Accessibility. Core flows (search, profile view, booking, review submission) must meet WCAG 2.1 AA for keyboard navigation and screen-reader labeling, given that a meaningful share of the mentor population is an older demographic less likely to be fluent with unconventional or fully custom UI interaction patterns.

Browser & device support. The responsive web app must function correctly on the current and previous major versions of Chrome, Safari, Firefox, and Edge, and on mobile browser viewports down to 360px wide, since v1 explicitly has no native app and mobile web may be a meaningful share of founder-side traffic.

Data Model (Plain English)

Founder — a startup-side account. Holds company name, primary contact name and email, country (US or Germany at launch), a Stripe customer reference for payment methods on file, and account status (active/deleted). A Founder can have many Bookings and many Reviews (one review per booking they made).

MentorApplication — the pre-approval record every prospective mentor starts as. Holds the applicant's contact details, claimed former employer(s) and years of experience, a free-text expertise narrative, requested expertise tags, requested hourly rate, reference contact information, review status (submitted, in review, approved, rejected), the reviewing admin's identity, and any review notes. An approved MentorApplication "graduates" into exactly one Mentor record; a rejected one is retained, not deleted, in case of a future resubmission.

Mentor — the live, bookable profile that exists only after an application is approved. Holds bio, expertise tags, hourly rate, named former employer(s) and years of experience (the same fields as the originating application, editable afterward subject to the re-review rule in FR-14), country, a Stripe Connect account reference for payouts, aggregate star rating (derived from published Reviews), and profile status (active/paused, e.g. if a mentor takes an extended break). A Mentor has many AvailabilitySlots, many Bookings, and many Payouts.

AvailabilitySlot — a specific bookable time window belonging to one Mentor. Holds start and end time (stored in UTC), a recurrence source (part of a weekly recurring pattern, or a one-off manual addition), and status (open, booked, blocked). A slot moves from open to booked the moment a Booking successfully pays for it, and a database-level constraint guarantees no two Bookings can ever claim the same slot.

Booking — the central transactional record, linking exactly one Founder, one Mentor, and one AvailabilitySlot. Holds the founder's free-text note on what they need help with, the agreed price, the platform fee amount, the mentor payout amount, an external video meeting link (once the mentor adds one), a Stripe payment reference, and status (requested, confirmed, completed, cancelled, disputed, resolved) with a timestamp recorded for every status change. A Booking has at most one Review and at most one Dispute.

Review — a one-to-one record tied to a single completed Booking, written by the Founder about the Mentor. Holds a 1-5 star rating, optional text comment, a moderation/visibility flag, and a created timestamp. Reviews roll up into the Mentor's aggregate rating shown on their public profile.

Dispute — created when either party reports an issue with a Booking (a founder-reported no-show or bad session, or a mentor-reported founder no-show). Holds the reporting party, a free-text explanation, status (open, investigating, resolved), the resolution type chosen by an admin (full refund, partial refund, pay mentor in full, no action), an admin note, the resolving admin's identity, and timestamps. Opening a Dispute against a Booking automatically holds that Booking's associated Payout until the Dispute reaches "resolved."

Payout — a record of funds transferred to a Mentor via Stripe Connect for one completed Booking. Holds the amount (session price minus the 20% platform fee), a Stripe transfer reference, status (pending, paid, held-for-dispute, failed), and the date it was initiated/completed. Each completed, undisputed Booking produces exactly one Payout, 48 hours after the session's scheduled end time.

Success Metrics

Measured across the first 90 days after public launch in the US and Germany:

• Mentor supply onboarded: at least 25 mentors fully approved and with live, bookable availability (not merely an approved-but-inactive application) by day 90, drawn roughly evenly across the four target metro areas (Boston, Bay Area, Munich, Stuttgart).
• Mentor activation rate: at least 60% of approved mentors accept and complete at least one real booking within their first 60 days on the platform — the direct test of the Idea Brief's own unproven assumption that retired engineers will actually convert into active, repeat mentors, not just sign up.
• Bookings completed: at least 120 completed (paid and session-held) sessions in the first 90 days.
• Gross booking volume (GMV): at least $24,000 in total session payments processed, based on a blended average session price of roughly $200 (within the stated $150-250/hour mentor rate range) across 120 completed bookings.
• Platform take-rate revenue: at least $4,800 in platform fee revenue (20% of the GMV target above) — a modest but real, non-zero proof that the transaction mechanism itself works end to end, independent of the Structured Track's larger, deferred revenue line.
• Repeat-booking rate: at least 20% of founders who complete one booking make a second booking (with any mentor) within the 90-day window — the clearest signal that the product delivers ongoing value rather than a single, one-off transaction.
• Dispute rate: fewer than 8% of completed bookings result in a filed dispute, and of those, a median resolution time under 3 business days — evidence the vetting process (US-11) is doing its job and the manual dispute process (US-12) is operable at this team's actual capacity.
• Review coverage: at least 70% of completed bookings receive a founder-submitted review, since review density is what makes the marketplace trustworthy to the next prospective founder.

Open Questions

• How strict does mentor vetting need to be at launch? A single professional reference and a free-text background narrative is the v1 bar (US-6/US-11), but it is genuinely unclear whether that is enough to prevent a confident-sounding but unqualified applicant from getting approved before the platform has any reputation to protect. Should v1 require a live reference-check phone call for every applicant (slower, higher-confidence) rather than an optional/asynchronous one, given that the entire product's credibility depends on this bar being right from mentor #1?
• Should sessions happen on-platform or via an external video tool, longer-term? v1 deliberately defers to external links (Zoom/Meet/Teams) for shipping speed, but this trades away the ability to record sessions (for dispute evidence or as a founder deliverable), to enforce that a session actually happened for a set duration, and to build session-notes tooling directly into the booking record. At what booking volume does building lightweight in-platform video become worth the engineering investment it was deliberately deferred to avoid in v1?
• What is the actual refund/recourse policy for a session that was merely disappointing, not a clear no-show? US-5/US-12 give the admin discretion (full refund, partial refund, pay mentor in full, no action), but there is no stated policy yet for the common, harder case: a session happened, the mentor showed up and tried, but the advice was generic or off-target. Is that ever grounds for even a partial refund, or does MentorLoop draw a hard line that a delivered session is non-refundable regardless of subjective quality, and if so, how is that communicated to founders before they book so it isn't a surprise the first time it happens?
• How does cross-border payout actually work for German mentors in practice? Stripe Connect supports SEPA payouts for German connected accounts, but the tax treatment (does MentorLoop, a US-something or EU-something legal entity not yet finalized, need to issue anything analogous to a 1099 for a German mentor, or handle VAT on the platform fee itself charged to a German mentor's earnings?) has not been resolved with an accountant and directly affects whether Payout (as modeled above) needs additional fields before engineering starts.
• Who actually owns dispute judgment calls when the single founder is unavailable? The entire admin/vetting/dispute model assumes one person can review every application and resolve every dispute personally within the success-metric targets above; there is no backup reviewer defined yet. At what queue depth or team size does this need a second trained reviewer, and should the admin console track a hard SLA countdown per open item now, even before a second person exists, so the gap is visible before it becomes a real backlog?
• Should the minimum bookable unit ever be less than a full hour? All figures in this PRD assume hourly bookings, but some founder questions (a 15-minute sanity check on a single certification detail) may not need a full hour, and some mentors may resist committing a full hour to a narrow question. Is a 30-minute booking option worth the added complexity to slot management and pricing before launch, or is it cleanly deferred alongside the Structured Track?

Needs real-world validation

What to do next

Downstream Summary