Learning Management & Course Marketplace Platform
GigRocket
Overview
GigRocket is a course marketplace and LMS: instructors publish and sell courses, learners buy and consume them, and money moves between both sides through a marketplace payment layer. As the sole backend engineer, I owned everything server-side (schema, APIs, payments, deployments) for the entire lifetime of the product.
The problem
A course marketplace has to solve three hard problems at once: model a catalog and enrollment system flexible enough for many course formats, move money correctly between learners, the platform, and instructors (including refunds and chargebacks), and keep the purchase funnel frictionless enough that a forced account-creation step doesn't kill conversion. None of these can be bolted on after the fact; they shape the schema and the API surface from day one.
Architecture & approach
The data layer is a 27-table PostgreSQL schema covering catalog, enrollment, payments, payouts, and fraud signals, designed so that course structure (sections, lessons, pricing tiers) and commerce state (orders, payouts, reserves) are cleanly separated but link back through consistent foreign keys.
On top of that schema sit 200+ REST APIs built in NestJS, organized by domain module (catalog, checkout, payments, instructor payouts, admin) so that ownership and testing boundaries map directly to the business domains they serve.
Payments run on Stripe Connect in a marketplace topology: platform account, connected instructor accounts, and dual-sided webhook handling so that both the buyer-facing charge and the instructor-facing payout are driven by Stripe's event stream rather than client-side confirmation.
Technical decisions
Dual-sided webhooks over polling
Order state and payout state are both driven entirely by Stripe webhook events rather than client callbacks or polling. This keeps the system correct even when a buyer closes the tab mid-checkout or a payout is delayed on Stripe's side; the database only advances state when Stripe confirms it.
Rolling reserves for chargeback risk
Instructor payouts hold back a rolling reserve rather than paying out the full balance immediately. This absorbs the lag between a sale and a possible chargeback without exposing the platform to clawback risk on funds already paid out.
Anomaly detection as a layer, not a gate
Fraud signals (unusual purchase velocity, mismatched billing signals, refund patterns) are scored and surfaced to admins rather than auto-blocking transactions. This avoided false-positive friction on legitimate buyers while still giving the platform visibility into risk.
11-API guest checkout flow
Signup was removed from the critical path of a purchase. Guest checkout is its own 11-endpoint flow that captures payment and delivers course access via email, with account creation offered afterward rather than required upfront, directly reducing drop-off at the point of highest purchase intent.
Outcome
- Shipped and operated a production marketplace payment system handling real instructor payouts across a rolling reserve model, with zero manual intervention required for standard order and payout flows.
- Guest checkout removed a hard signup wall from the purchase funnel without compromising order integrity or fulfillment.
- Deployments across development, staging, and production run through GitHub Actions CI/CD with automated database migrations, so schema changes ship with the same review and rollback safety as application code.