How to build a course platform with AI

These are the parts a course platform needs before it is useful. Each one is something the plan covers.

• Course catalog and landing pages: Browse, search and sell courses with SEO-friendly pages.
• Course content tree (modules and lessons): Structured, ordered, versioned content: text, embedded video, files, quizzes, assignments.
• Enrollment and access control: Decide who may open which lesson: free, paid, cohort-gated, drip-scheduled.
• Payments and checkout: One-time purchase, bundles, subscriptions to a catalog, coupons and refunds.
• Progress tracking: Resume where the learner left off; show completion and next lesson.
• Quizzes and assignments with grading: Check learning: auto-graded quizzes, file/text assignments graded by instructors, rubrics.
• Certificates: Proof of completion that a third party can verify.
• Instructor revenue share and payouts: Pay instructors their share with no manual spreadsheets.

• Video lessons: Deliver instructor video reliably and cheaply.
• Cohorts and drip schedules: Run group classes with start dates and release lessons on a schedule.
• Discussion and Q&A: Per-lesson and per-course threads with instructor answers.
• Email and in-app notifications: Welcome, drip release, deadline reminders, grade posted, certificate ready.

Each table below becomes part of the Postgres database that belongs to your app.

• courses: status: draft|in_review|published|archived; price in integer minor units; rating and enrolled counters are maintained by batched rollups, never COUNT(*) at request time; publishing bumps published_version atomically.
• modules: position uses gaps (1000, 2000...) so reordering is a single-row update; deleting a module with progress archives it instead.
• lessons: kind: text|video|file|quiz|assignment; video_ref is an embed URL or object key in phase 1; body is sanitised JSON/markdown; file_keys point into the private course-files bucket; edits create a new version row, published_version selects what learners see.
• cohorts: seats_taken is incremented atomically in the enrollment transaction (UPDATE ... WHERE seats_taken < seat_cap RETURNING) so overselling is impossible.
• course_orders: status: pending|paid|refunded|failed; enrollment is created only from the verified webhook; price is copied from the course at order time so later price edits do not change history.
• enrollments: status: active|completed|refunded|revoked|expired; source: purchase|free|invite|admin; progress_pct is a cached projection updated with lesson completion.
• lesson_progress: client posts at most every 15 s; writes are upserts, so playback of a 2 hour lesson is not 480 rows; completion is monotonic (never un-completed by a late write).
• assessments: kind: quiz|assignment|exam; quiz answers are never sent to the client with the questions; versioning protects past attempts when an instructor edits questions.
• assessment_questions: kind: single|multi|short|file; answer_key is read only by the grading function on the server and stripped from every learner-facing response.

• No self-hosted adaptive video pipeline in phase 1 (embedded provider or single MP4; video-streaming playbook in phase 2).
• No SCORM, xAPI or LTI in phase 1.
• No proctoring or anti-cheat claims beyond server-side timing and attempt limits.
• No accredited credentials: certificates attest completion only.
• No live classes in phase 1.
• SCORM / xAPI / LTI: plan for it, build it later.
• Live classes and proctoring: plan for it, build it later.

Forge64 matches your description to one of 12 reference architectures, writes the plan and data model into the project, generates the app, and runs a quality gate over the code before you see it. Each app gets its own Postgres database and sign-in with no per-user fee. Hosting on Forge Cloud and Forge Payments are rolling out.

This is a reference design for the category, not a promise that every item is generated today. Built-ins such as email, background jobs, file uploads and search are coming soon, so anything here that needs them is something you add yourself for now.

What does a course platform need first?

Course catalog and landing pages, course content tree (modules and lessons), enrollment and access control, payments and checkout, progress tracking and quizzes and assignments with grading. The plan for a course platform covers all of these before it generates code.

What should I leave out of the first version of a course platform?

No self-hosted adaptive video pipeline in phase 1 (embedded provider or single MP4; video-streaming playbook in phase 2). No SCORM, xAPI or LTI in phase 1. No proctoring or anti-cheat claims beyond server-side timing and attempt limits.

Which products define the course platform category?

Well-known examples include Udemy, Coursera, Teachable, Thinkific and Moodle. Use them to decide which features your users expect, then describe your own version.

• Course platform architecture
• Example prompt for a course platform
• Course platform security checklist
• Course platform scaling checklist
• Often combined: video streaming app
• Often combined: marketplace
• All app types