How to Build an Online Course Platform Like Teachable

Teachable's free plan takes 5% of every transaction. On the $39/month Basic plan, that fee disappears, but you are paying $468/year before you have sold a single course. On the $299/month Pro plan, you get more features, zero transaction fees, and a $3,588 annual platform bill.

A creator doing $10,000/month in course revenue on the free plan sends Teachable $500/month in transaction fees. That is $6,000/year. A creator at $100,000/month pays $5,000 every month, $60,000 per year, to a platform they do not control, cannot brand completely, and could lose access to if Teachable changes its pricing tomorrow.

The businesses that build their own course platforms are not doing it to save a few hundred dollars. They are doing it because the training product is the business, and running it on rented infrastructure is a long-term strategic problem. Here is how the platform actually works.

Who builds this

The decision to build a custom course platform usually comes from one of five types of organizations.

Training companies with established course libraries, typically 10 or more courses, need white-label infrastructure. Their brand is on the certificate. Their domain is in the URL. Teachable's footer and default emails undercut that positioning.

Professional associations running CPD or certification programs need certificates that carry credential weight. A Teachable-generated certificate does not look the same as one issued directly by the Institute of Chartered Accountants. The certificate is the product.

Corporate L&D teams building internal academies need SSO integration with Active Directory or Okta, completion data feeding into HR systems, and employee data staying inside the company's infrastructure. None of that works easily on Teachable.

Franchise systems training hundreds of location operators need consistent delivery across many learners, completion tracking tied to operational milestones, and the ability to require re-certification annually. Teachable is not built for that workflow.

Healthcare organizations delivering medical education often operate under HIPAA requirements. Where patient data intersects with learner data, external SaaS platforms add compliance complexity that a self-hosted or private-cloud deployment avoids.

The course builder

Everything starts with how instructors create courses. The data model is simple: a Course contains Sections, and each Section contains Lessons. Lessons can be video, text, audio, a downloadable file, or a quiz.

The instructor interface needs drag-and-drop reordering for both sections and lessons within sections. This sounds like a front-end detail, but it changes how instructors think about structuring content. Without it, reorganizing a 40-lesson course is painful enough that instructors stop iterating on their curriculum.

Drip content is a feature that unlocks lessons on a schedule after enrollment. A cohort-based course might release new lessons every week. A self-paced course might drip three lessons per day to prevent binge behavior and improve completion rates. The technical implementation stores a drip_delay_days value per lesson and calculates the earliest unlock date from the student's enrollment date.

Preview lessons let non-enrolled visitors watch the first lesson of a course for free before purchasing. This is one of the most effective conversion tools on any course platform and takes less than a day to build.

Video delivery: the hardest technical piece

Most teams underestimate the complexity of video delivery until they have already made the wrong choice.

The wrong choice is storing videos in S3 and serving them directly to students. S3 was built for file storage, not video streaming. When you serve a raw video file from S3, the browser downloads the entire file or large chunks of it. A student on a slow connection will buffer constantly. A student on mobile will burn data. There is no quality adaptation, so a 1080p upload plays at 1080p even on a 3G connection.

The right choice is a video platform that converts your uploads to HLS format: Mux or Bunny.net.

HLS (HTTP Live Streaming) breaks a video into small segments (typically 6-10 seconds each) and creates multiple quality versions of each segment: 1080p, 720p, 480p, 360p. The video player on the student's device monitors connection speed and switches between quality levels in real time. Good connection: 1080p. Bad connection: 480p. The student never sees a loading spinner.

Mux charges $0.015 per minute stored and $0.017 per minute delivered. A 10-hour course library with 1,000 student hours of monthly viewing costs about $17 in delivery fees plus $9 in storage. Mux has a clean API, detailed analytics (buffer rate, startup time, quality level distribution by student), and solid documentation. For most platforms, Mux is the right starting point.

Bunny.net is cheaper at roughly $0.009 per minute stored. It is a CDN-first company that added video hosting later. The API is less polished than Mux, but the cost savings are real at high volume. For a platform with millions of monthly viewing minutes, Bunny.net saves money.

The upload pipeline for either service is the same: the instructor uploads a video file to your server (or directly to the video service via a presigned URL), the video service processes it into HLS segments, and returns a playback URL. You store that playback URL in your database. The video player (Video.js or Plyr) reads the HLS manifest and handles the rest.

Student progress tracking

Progress tracking is table-stakes. Students expect to see which lessons they have completed, how far through the course they are, and where they left off.

The data model: a lesson_completion record created when a student marks a lesson complete (or when the video player fires a completion event after 90% of the video plays). A course-level progress_percentage is calculated from completed_lessons / total_lessons * 100.

The "last accessed lesson" redirect on login saves students from hunting for where they stopped. Store the last lesson ID on the enrollment record and update it each time the student opens a lesson.

Certificate unlock triggers on course completion (100% of lessons completed) or on quiz passing (score above the threshold you set). The trigger fires an async job that generates the certificate PDF and emails the download link to the student.

Quizzes and assessments

Quizzes serve two purposes: they reinforce learning (there is strong evidence that retrieval practice improves retention) and they gate certificate access.

Three question types cover most use cases: multiple choice, true/false, and short answer. Multiple choice and true/false are auto-graded. Short answer requires manual review, which adds workflow complexity. For most platforms, start with multiple choice and true/false only.

Per-quiz settings: number of questions, pass threshold (e.g. 80%), number of attempts allowed, and whether answers are revealed after submission. Store each attempt in the database with the answers and score so instructors can see where students are struggling.

Certificates

The auto-generated certificate is a selling point for many course platforms. Students share it on LinkedIn. Employers ask for it. Professional associations issue it as a real credential.

Two generation approaches: Puppeteer renders an HTML/CSS certificate template to PDF using headless Chrome, which gives you full design control. pdf-lib generates PDFs programmatically without a browser, which is faster and cheaper on server resources but harder to design for.

For most platforms, Puppeteer is the right choice. Design the certificate in HTML and CSS, capture it with Puppeteer, and store the resulting PDF on S3. The student gets a permanent download link in their dashboard and an email with the PDF attached.

The certificate needs to include the student's full name (pulled from their profile), the course name, the completion date, and the issuing organization's branding. Add a verification URL if the credential needs to be shareable and verifiable by third parties.

Payments

Course platforms need more payment structures than a simple checkout.

One-time purchase: the student pays once and has lifetime access. Standard Stripe checkout flow with a payment intent.

Subscription: monthly access to all courses or a specific bundle. Stripe Subscription with auto-renewal and webhook handling for failures.

Payment plans: three installments, for example, instead of one lump sum. Stripe handles this natively as a subscription with a limited number of billing cycles.

Bundle pricing: three courses for the price of two. Create a Stripe Product for the bundle and link course access to bundle purchases in your database.

Stripe Connect for multi-instructor platforms: each instructor creates a Connected Account. When a student purchases their course, the payment routes to your platform account. You initiate a Transfer to the instructor's Connected Account for their revenue share, minus your commission. Stripe handles payouts to their bank accounts on the schedule you configure (weekly, monthly). Stripe also manages 1099 generation for US instructors automatically.

Affiliate tracking

Affiliates send students to your courses and earn a commission on each purchase. This is one of the highest-ROI marketing channels for course creators.

The technical implementation: each affiliate gets a unique referral link with a tracking parameter (e.g., ?ref=affiliate_id). When a visitor clicks that link, you set a cookie with a 30-day expiration storing the affiliate ID. When that visitor purchases a course within 30 days, you create an affiliate_conversion record linking the sale to the affiliate.

The affiliate dashboard shows clicks, conversions, earnings pending payout, and historical payouts. Automated payouts on a monthly schedule run through Stripe Transfers to the affiliate's bank account.

A working affiliate system multiplies your creators' distribution without any marketing spend from the platform. Build it in the MVP if your creators are marketing-focused.

Student portal and community

The student portal is the logged-in experience: their enrolled courses, progress on each, certificates earned, and billing management (cancel subscription, update payment method).

Community features are optional but high-value. The simplest version is a discussion thread per lesson, like YouTube comments beneath each video. Students ask questions, instructors respond, and the discussion stays in context with the lesson content.

For full community functionality (spaces, events, member profiles, direct messaging), the fastest approach is integrating Circle. Circle provides embeddable community components and an API for syncing enrollment data. Students who purchase a course get automatically added to the corresponding Circle space.

White-labeling

Custom domain: the platform runs on academy.yourclient.com with no mention of your platform in the URL, footer, emails, or student-facing content. This requires custom SSL certificate provisioning per tenant, which services like Caddy or Let's Encrypt handle automatically.

Branded colors and logo: the interface adapts to each tenant's brand tokens stored in the database. CSS custom properties (variables) make this straightforward at the application level.

Email customization: welcome emails, certificate emails, and payment receipts send from the tenant's domain with their branding, not yours.

Tech stack

Frontend: React for both the instructor course builder and the student portal. Server-rendered Next.js for public course catalog pages that need SEO indexing.

Backend: Node.js API. PostgreSQL for course data, student records, enrollment state, quiz results, and affiliate tracking. Redis for caching progress state and rate-limiting API endpoints.

Video delivery: Mux or Bunny.net, as discussed.

File storage: AWS S3 for downloadable course files, certificates, and course thumbnails.

Payments: Stripe for all payment flows. Stripe Connect for multi-instructor splits.

Certificate generation: Puppeteer running on a job queue (Bull or BullMQ) to avoid blocking the API on PDF generation. Generated certificates stored on S3.

Progress state: stored in PostgreSQL with Redis caching for the student dashboard read path.

Timeline and cost

MVP timeline: 12-16 weeks. Core scope: course builder with video delivery, student progress tracking, quizzes, certificates, Stripe payments, and basic affiliate tracking. Add 3-4 weeks for Circle community integration or advanced white-labeling.

MVP cost: $120,000-$180,000. The range is driven by the video delivery pipeline complexity, the number of payment structures needed at launch, and whether the platform needs multi-tenant white-label support from day one.

The 12-week floor is realistic only if scope is contained. The features that expand timelines: custom video player with closed captioning and playback speed controls, SCORM compliance for enterprise LMS integration, and SSO with SAML or OAuth for corporate clients.

What teams get wrong

Video hosting gets punted. Teams upload videos to S3 thinking they will migrate later. Later never comes. Build the Mux or Bunny.net pipeline from the start. Migrating a video library of 500 hours with live students watching is a production incident waiting to happen.

Certificates get underestimated. Every client says they want certificates. Almost none of them specify what the certificate should look like, whether it needs a verification URL, or how students will share it until development is finished. Nail down the certificate design before the build starts.

Multi-instructor Stripe Connect gets added late. Stripe Connected Account onboarding requires KYC for each instructor (identity verification, tax information). This takes time and requires UI that many teams build as an afterthought. If the platform will support multiple instructors at launch, design the Stripe Connect onboarding flow as a first-class feature.

The course platform itself is a simple product. The complexity lives in the video delivery layer and the payment edge cases. Get those two right and the rest is execution.