Build and Deploy an Online Course Platform With Claude Code

Choose Your Platform Setup

Open an empty folder — or your existing project — in Claude Code, fill in the fields, then copy the prompt.

Build Your Course Platform Interface

Choose your topic, lesson formats and who can access the courses, and Claude Code builds the whole platform interface with realistic sample courses.

Build the interface for an online course platform. This task builds the screens only, with realistic sample content. Sign-in and real data come later. Platform name: {{PLATFORM_NAME}} What the platform teaches: {{TEACHING_TOPIC}} Example course: {{EXAMPLE_COURSE}} Lesson formats: {{LESSON_FORMATS}} Who can access the courses: {{ACCESS_MODEL}} Visual style: {{VISUAL_STYLE}} 1. INSPECT FIRST Inspect this folder before changing anything. - If it is empty, create a new React + Vite + TypeScript project here, with client-side routing and a simple, well-organised structure. - If a project already exists, keep its framework, styling and components, and add the platform to it. Do not rebuild, rename or restructure working code, and do not touch unrelated pages. Tell me which case applies, then continue. 2. SAVE THE PLATFORM SCOPE Add a "Course platform" section to CLAUDE.md in the project root — create the file if it does not exist. Record the platform name, the topic, the lesson formats, the access model and the visual style. Every later task reads this section, so keep it short and accurate. Never write keys or passwords into it. 3. KEEP THE SCOPE FOCUSED This is one owner's course platform, not a marketplace: one admin manages every course. The core is Course → Sections → Lessons → Student progress. Build only the lesson formats listed above. Do not add payments, subscriptions, certificates, quizzes, assignments, live classes, a community or forum, drip scheduling, multiple instructors or advanced analytics. 4. PUBLIC PAGES - a course library listing the published courses - a course page: title, description, cover image, number of lessons, the full curriculum of section and lesson titles, and a clear Start or Continue action - sign-in and sign-up screens — the design only, they do not need to work yet No fake reviews, ratings, enrollment counts or instructor stats. 5. STUDENT AREA - a dashboard with Continue learning and My Courses, each course with its progress - the course player, the centrepiece of the platform: the lesson content, the curriculum beside it (a drawer on phones) with completed lessons marked, Previous and Next, Mark as complete, and the course progress — for example "8 of 12 lessons complete — 67%". Keep it clean and distraction-free. - a course-complete state — no certificate 6. ADMIN AREA - an overview of the courses - a course list showing draft and published courses - a course editor: the course details, its sections and lessons in order, and a lesson editor for the chosen formats - only if I enroll students manually, a place to enroll students The admin forms can stay local for now. Never pretend that something was saved. 7. ACCESS MODEL Reflect the chosen access model in the interface. With manual enrollment, a student sees the courses they are enrolled in, and other courses clearly show that enrollment is needed. 8. SAMPLE CONTENT Create two or three sample courses for this topic, including the example course, each with two or three sections of lessons in the chosen formats. Use realistic titles and lesson text; for video lessons, use clearly marked placeholder video links. No lorem ipsum. Keep all sample content in ONE clearly named module, separate from the components and shaped like real data — courses, sections, lessons — so a database can replace it later. 9. ADDRESSES Give every course and every lesson its own address, so a lesson can be bookmarked and refreshed. 10. PREVIEW SWITCH Until real sign-in exists, add one small, clearly labelled switch between the visitor, student and admin views. Keep it in one place so it is easy to remove. 11. DESIGN Apply the visual style and the platform name. The platform must work well on phones, tablets and desktops — many students learn on a phone. Keep it calm and focused on learning: no marketing clutter, no decorative gradients or glows and no fake statistics. 12. RUN IT Start the development server and give me the local address. When finished, report: - whether you created a new project or extended an existing one - the public, student and admin screens - where the sample content lives - anything you did not build, and why

What is your platform called?

SkillBase

What will you teach?

Name one example course

Build Websites With AI

Which visual style fits your brand?

Who can access the courses?

Which lesson formats do you need?

Claude Code saves your choices in the project's CLAUDE.md file, so every later prompt builds only what you picked.

Check the Course Platform

Open the local address Claude Code gives you and use the preview switch to look at each side:

The course library shows the sample courses

A course page shows its curriculum and a Start button

The lesson player shows the lesson, the curriculum, and Previous and Next

The student dashboard shows Continue learning and course progress

The admin screens show your courses and the course editor

Only the lesson formats you chose appear

Everything works at phone width

Ask Claude Code for any change now — the interface is easiest to adjust before real data arrives.

Expected result

You should now have a complete course-platform interface running locally with realistic sample courses and lessons.

Connect Supabase

If this project is already connected to the right Supabase project, reuse it — don't create a second one.

Open Supabase

https://supabase.link/r4gdwhi

Create a new project if you don't have one Open the project's Connect panel Copy the Project URL and the Publishable key Ask Claude Code which environment variable names this project uses, then add both values locally

IMPORTANT

The browser app only needs the Project URL and the Publishable key. A Secret key belongs only in a trusted server environment, and only where one is genuinely needed — never in browser code and never committed to GitHub.

Create Your Test Accounts

Create three accounts: one for you with your real email address — it becomes the admin — and two test students, Student A and Student B.

Supabase Authentication Users

Click Add user, then Create new user Enter the email address and a password Keep Auto Confirm User on, then create the user Repeat until all three accounts exist

Use email addresses you control for the test students.

Add Sign-In and Course Data

Use this prompt in Claude Code. It gives you one SQL block to review and run.

Add Real Accounts and Course Data

Add sign-in, the admin and student roles, and real course, section and lesson data, with lesson content protected from the start.

Turn the course platform into a real app with Supabase: real accounts, an admin and real course data. Read the "Course platform" section of CLAUDE.md first. It records the lesson formats and the access model — follow them, and do not ask me about the access model again. Inspect the project first. If it is already connected to Supabase, reuse that project and its client — do not create a second one. Use the current Supabase terms: the Project URL and the Publishable key. Never put a Secret or service-role key in browser code, and never print secret values. 1. ENVIRONMENT Read the Project URL and the Publishable key from environment variables, using this framework's naming. Tell me the exact names, list them in .env.example without values, and make sure .env is git-ignored. 2. SIGN-IN Add email and password sign-up, sign-in and sign-out with Supabase Auth. Protect the student area and the admin area. Signed-out visitors can still browse the course library and course pages. Remove the preview switch. From now on, the signed-in account decides what appears. 3. ADMIN AND STUDENTS This platform has exactly two kinds of account: the admin (me) and students. Do not build a general roles-and-permissions system. - Store the role in a profiles table keyed by the auth user id. Create a profile automatically for every new account, as a student, and backfill profiles for the accounts that already exist. - Nobody can change their own role. Never decide the role from user_metadata, local storage, the URL or anything else the browser controls. - Make MY account the admin with ONE reviewed SQL statement — never through sign-up or the app. - Hiding the admin link is not protection: the database must refuse admin actions from everyone else. 4. COURSE DATA Use related tables, not one large JSON document, so content is easy to edit, order and track: - courses: title, a URL slug, summary, description, cover image and a draft or published status - sections: belong to a course, with a position for their order - lessons: belong to a section, with a position, a title and — when more than one format was chosen — a lesson type such as video or text - lesson content: only the fields the chosen formats need, such as a video URL or the lesson text - lesson resources, only if downloadable resources were chosen: the file details, with the files in a PRIVATE Storage bucket - enrollments: which student can access which course - lesson progress: which student completed which lesson and when, one row per student and lesson Use generated ids. Create nothing unrelated. 5. WHO CAN READ WHAT Turn on Row Level Security on every table immediately. - Anyone can read PUBLISHED courses and their curriculum: course details, section titles and lesson titles. Drafts are visible only to the admin — the database enforces this, not a frontend filter. - Lesson content and resources are protected. With "anyone with an account", any signed-in student can read the content of published courses. With manual enrollment, only a student enrolled in that course can. - Row Level Security works per row, so keep lesson content where these rules can actually protect it — for example in its own table — never in a row the public curriculum can read. - Students can read only their own enrollments and progress. - The admin can read and manage everything. Use one trusted database check for "is this account the admin". 6. REAL DATA Replace the sample content with real queries, and remove the sample-content module. Give me ONE reviewed SQL seed that recreates the sample courses in Supabase, plus one draft course. If I chose manual enrollment, enroll Student A in the first course and leave Student B unenrolled. Ask me for the three test accounts' email addresses — never their passwords. Do not seed resource rows without real files; the admin uploads those later. Show loading, empty and error states, and never show raw database errors. Give me: 1. The environment variable names 2. The tables and what each holds 3. How the admin role is stored and protected 4. The read rules, table by table 5. ONE reviewed SQL block to run in the Supabase SQL Editor: the tables, the rules, the private bucket if needed, the profile backfill, the admin statement and the seed 6. Anything that blocks the next step Do not use destructive DROP statements. If a table with the same name already exists, warn me instead of replacing it. Do not connect the admin forms or progress saving yet — they come next.

Review the SQL, then run it in your Supabase project. It creates the course tables, makes your account the admin and adds the sample courses.

Supabase SQL Editor

Visitor: the library shows the published sample courses

Visitor: the draft course does not appear

Student A: sign in and see the student dashboard

Student A: the admin area is refused

Admin: sign in and see the admin dashboard

Refresh a page — you stay signed in

Expected result

The app now loads real courses and lessons from the database and recognizes signed-in students.

Make the Course Player Work

Build the Learning Experience

Make course access, the lesson player, saved progress and Continue learning work for real students.

Make the student learning experience fully work. Read the "Course platform" section of CLAUDE.md first. Build only the lesson formats it lists, and follow its access model. Every read and write goes through the database rules. No Secret or service-role key in the app. 1. COURSE ACCESS - Anyone with an account: a signed-in student can start any published course. Starting it adds the course to My Courses — an enrollment students may create only for themselves, and only for published courses. - Manual enrollment: only students the admin enrolled can open lessons, and students cannot enroll themselves. Everyone else sees the course page with a clear "enrollment needed" state. Guessing a lesson address must never reveal its content. The database refuses it, not just the screen. 2. COURSE PLAYER A student can open a course, open any lesson they have access to, see the curriculum with completed lessons marked, move with Previous and Next, and continue to the next lesson. Every lesson keeps its own address and survives a refresh. 3. VIDEO LESSONS — only if chosen Store a normal video URL from a host such as YouTube, Vimeo or Bunny Stream — never pasted embed HTML — and show it in an embedded player. Accept only links you can embed safely, and show a clear message for anything else. Do not build video hosting or processing. The platform only hides the link from people without access. Say plainly in your report that anyone who has an unlisted video link can share it, and that the video host's own privacy settings control that. 4. TEXT LESSONS — only if chosen Keep it simple and reliable — for example Markdown written in a plain text area and rendered safely, with no raw HTML. No heavy rich-text editor. 5. RESOURCES — only if chosen Keep the files in the private bucket, in a folder per course. Students with access download them through short-lived signed URLs that expire within a few minutes; nobody else can, even with a guessed path. Students never upload, replace or delete files. 6. PROGRESS - Mark as complete saves one progress row for this student and lesson, and the student can undo it. - The database lets a student write only their own progress, and only for lessons they can access. The student comes from the signed-in account, never from a value the browser sends. - Calculate course progress from real rows: completed published lessons divided by the course's published lessons — for example "8 of 12 lessons complete — 67%". Never store a percentage on its own. - The curriculum, the course page and the dashboard show the same numbers, and they survive a refresh and a new sign-in. 7. CONTINUE LEARNING Remember the lesson each student last opened in each course. Continue learning returns to it if it is unfinished, and otherwise to the next unfinished lesson in curriculum order — never simply to lesson 1. 8. COURSE COMPLETE When every published lesson in a course is complete, show a clean course-complete state. No certificate. Give me ONE reviewed SQL block for any new rules or columns, to run in the Supabase SQL Editor. Never drop tables, columns or data. When finished, report: - how access is checked for the chosen access model - how progress is saved and calculated - how Continue learning chooses a lesson - how each chosen lesson format is shown - the video-link limitation, in plain words

Review the SQL it gives you, then run it in the SQL Editor.

IMPORTANT

Video lessons use a link from a host such as YouTube or Vimeo. Students without access never see it, but anyone who has an unlisted link can share it. If that matters, use your video host's privacy settings — for example allowing embeds only on your own domain.

Test Learning as a Student

Sign in as Student A:

Open a course and its first lesson

Move through the lessons with Next and Previous

Mark a lesson complete — the curriculum shows it

The course progress updates, such as 1 of 12 lessons complete

Sign out and back in — your progress is still there

Open a later lesson, go back to the dashboard — Continue learning returns to it

Student B: a course they aren't enrolled in stays locked — only if you enroll students manually

Expected result

A student can open a real course, complete lessons, leave the app, come back, and continue from saved progress.

Build the Course Manager

Build the Course Admin

Create, edit, order and publish courses, sections and lessons from your own admin dashboard instead of Supabase.

Make the admin dashboard manage the whole course library. I must never need the Supabase dashboard to manage content. Read the "Course platform" section of CLAUDE.md first, and build only for the lesson formats it lists. Reuse the admin screens you already built. Every write goes through the database rules, which allow admin actions only. No Secret or service-role key in the app. 1. ADMIN ONLY Only the admin account reaches the admin area. Any other account sees a "no access" page, and the database refuses its requests anyway. 2. COURSES - See every course with its status and number of lessons. - Create a course and edit its title, summary, description and cover image. - Publish and unpublish a course. Warn before publishing a course with no lessons. Upload cover images to a separate public bucket — they are shown publicly anyway. Never put lesson resources there. 3. COURSE BUILDER Show the course structure the way a student sees it: sections, with numbered lessons inside them. Let me: - add, rename, reorder and delete sections - add, edit, reorder and delete lessons - move a lesson to another section Use simple Move up and Move down controls unless this project already has reliable drag-and-drop. Ask for confirmation before deleting, and say plainly that deleting a lesson also removes students' progress on it. 4. LESSON EDITOR Manage only what the chosen formats need: the title, the lesson type, the video URL, the lesson text and the resources — uploaded to and deleted from the private bucket. Add a draft or published state for single lessons only if it stays simple. 5. FORMS Validate required fields, prevent double submission, show clear success and error messages, and never show raw database errors. Keep every screen usable on a tablet and a phone. Give me ONE reviewed SQL block for any new rules or buckets, to run in the Supabase SQL Editor. Never drop tables, columns or data. When finished, report: - the admin routes - how the admin check works in the app and in the database - how the order of sections and lessons is stored and changed - what happens to progress when a lesson is deleted

Run any SQL it gives you in the SQL Editor. Then, as the admin:

Create a course with two sections

Add a lesson of each format you chose

Reorder two lessons

Publish the course

Delete a test lesson — the app asks you to confirm first

Manage Students and Access

Add Student Management

See each student's progress and, if you enroll students manually, give and remove course access from the admin dashboard.

Add student management to the admin dashboard. Read the "Course platform" section of CLAUDE.md first, and follow its access model. 1. STUDENTS Show a simple list of students, with each student's courses and progress — for example "Sara — 8 / 12 lessons complete". Show names or email addresses through an admin-only path. No analytics, charts or student CRM. 2. ENROLLMENT — only with manual enrollment - Find a student by the email address they signed up with. Only confirmed accounts can be enrolled. - Enroll them in a course. - Remove their access. Keep their progress, so enrolling them again restores it. - See who is enrolled in each course. Enrollment writes are admin-only in the database. 3. ANYONE WITH AN ACCOUNT Skip enrollment management, and show which students started each course instead. Give me ONE reviewed SQL block for any new rules or database functions, to run in the Supabase SQL Editor. When finished, report: - what the students page shows - how enrollment works, if it applies - where the admin-only checks are enforced

Run any SQL it gives you, then check. Skip the enrollment checks if anyone with an account can learn.

Admin: see Student A's progress, such as 3 / 12 lessons complete

Admin: enroll Student B in the new course

Student B: the course now opens

Admin: remove Student B's access — the course locks again

Admin: edit a lesson in a course Student A can open — Student A sees the change

Expected result

You can create and edit a course in the app and publish it, and students see the change.

Test as a Visitor and a Student

Sign out first, then use Student A — and Student B where a check says so. Skip any check for a setup you didn't choose.

Visitor: published courses appear in the library

Visitor: draft courses stay hidden, even by their address

Visitor: a course page shows its details and curriculum

Sign in and sign out work

Student A: the dashboard opens after sign-in

Student A: the right courses are available

Student B: a course they aren't enrolled in stays locked, even by its address — manual enrollment only

Student A: lessons load correctly

Student A: Previous and Next work

Student A: completing a lesson is saved

Student A: the course percentage updates correctly

Student A: progress survives a refresh

Student A: progress survives signing out and back in

Student A: Continue learning opens a useful lesson, not always the first one

Student A: finishing every lesson shows the course-complete state

Test the Admin and Course Content

Sign in as the admin, then check the student side. Skip any check for a setup you didn't choose.

Admin: create a course

Admin: add sections

Admin: add and edit lessons

Admin: reorder sections and lessons

Admin: publish the course

Student A: sees the published changes

Admin: enroll a student, then remove them — manual enrollment only

Student A: download a resource from a course they can open

A copied resource link stops working after a few minutes

Video and text lessons display as intended

Test Security and Quality

Run these by hand, then let Claude Code check the database directly:

Student A: the admin area is refused, even by typing its address

Empty states look intentional, such as a course with no lessons yet

Loading states appear while lessons load

Errors are easy to understand

Refreshing a lesson or an admin page keeps you there

Learning works well on a phone

Verify and Fix the Platform

Prove the access rules directly in the database as two students and a visitor, then fix only the checks that failed.

Verify this course platform at the database level, then fix what failed. Read the "Course platform" section of CLAUDE.md first, and test only the features and the access model it records. These manual checks failed: {{FAILED_CHECKS}} 1. DATABASE CHECK Use a temporary LOCAL-ONLY script with the project's normal Supabase client and the Publishable key. Do NOT use the Secret or service-role key: it skips every access rule, so the test would prove nothing. Ask me to put the test accounts' passwords in local, uncommitted environment variables. Never commit passwords, never put them in source code and never print them. As STUDENT B, try to: - read, create, change or delete Student A's progress - save progress with another student's id - create, edit, publish or delete a course, section or lesson - read a draft course or its lessons - with manual enrollment: read lesson content or resources of a course they are not enrolled in, or enroll themselves - change their own role As a SIGNED-OUT visitor, try to read lesson content, resources, draft courses and anyone's progress. Expected: refused — an error, no rows returned or zero rows changed. Re-read afterwards to confirm nothing changed. As STUDENT A: read an allowed lesson and save their own progress. Expected: it works. As the ADMIN: edit and publish a course. Expected: it works. 2. SECRETS Search the source code and the built files. Only the Supabase Project URL and Publishable key may appear. 3. FIX Find the real cause of each failed check — mine and yours — and fix it at its source. Keep every fix small: no redesign, no new features and no rewrites of working code. Run the database check again after any fix. Remove the script afterwards and do not commit it. Return exactly one: PLATFORM READY or: NEEDS ATTENTION If NEEDS ATTENTION, give me any corrected SQL to run, list what still fails, and test again once I confirm the SQL has run.

Which checks failed?

Progress disappears after signing out. The lesson sidebar covers the video on a phone...

Continue when Claude Code reports PLATFORM READY. Its report confirms:

Student B can't change Student A's progress

No student can save progress for someone else

No student can create, edit or delete courses

Direct database requests can't get around these rules

No secret keys reach the browser

Expected result

The admin can publish real course content and students can securely learn and save their progress.

Prepare and Deploy the Platform

Prepare the Platform for Production

Build the platform for production, remove development leftovers, keep secrets out, and make every lesson page survive a refresh on Hostinger.

Prepare this course platform for production on Hostinger, as a Node.js Web App deployed from GitHub. Read the "Course platform" section of CLAUDE.md first. Do not add features, and never print secret values. 1. BUILD Run the production build and fix anything that fails. 2. REMOVE DEVELOPMENT CODE Remove anything left from development: sample-content leftovers, the preview switch, test-only scripts, debug logging and any hard-coded test account. 3. NO SECRETS IN THE APP Search the source code and the built files. Only the Supabase Project URL and Publishable key may appear — no Secret or service-role key and no passwords. Make sure .env is git-ignored and never committed, and that .env.example lists the variable names without values. 4. ENVIRONMENT VARIABLES List the exact environment variable names Hostinger needs, and whether this framework needs them at build time. 5. LIVE ADDRESSES Nothing may point at localhost in production. Build every sign-in, sign-up and email-confirmation redirect from the live address, never a hard-coded URL. 6. PAGE REFRESH Course, lesson and admin pages use client-side routes. Refreshing or directly opening any of them on Hostinger must load the app, not a 404. Set this up the way Hostinger's Node.js Web App serves this framework — for example a small production server with a fallback to the app. 7. HOSTINGER SETTINGS Tell me what to confirm on Hostinger's deploy screen: the framework, build command, output directory, Node version and, if one is needed, the entry file. Do not commit or push — I will review first. Report: - the build result - what you removed - the environment variable names - how page refresh is handled - the Hostinger settings - anything that blocks deployment

Push the project to GitHub with Claude Code or your normal GitHub workflow. If it already has a repository, use it.

Deploy on Hostinger

Recommended plan: Business

USED IN TUTORIAL

https://www.hostg.xyz/SHK1P

Hostinger Websites Add Website Node.js Web App

Choose Import Git repository Connect GitHub and select the platform's repository Confirm the framework and build settings Claude Code gave you Add the environment variables with your project's exact names Click Deploy and wait for the result

IMPORTANT

Add the Supabase Project URL and Publishable key under the names your project already uses. Private server keys stay private — never rename one to a VITE_ or NEXT_PUBLIC_ variable to make the deployment work.

Fix a Failed Website or Web App Deployment with AI

Use this if the Hostinger deployment fails.

/video/fix-a-failed-website-or-web-app-deployment-with-ai

Set Up Production Sign-In

Students can only sign in on your live address once Supabase knows it, and they need real confirmation emails.

1. Add your live address

Set the Site URL to your live Hostinger address and add it to the Redirect URLs.

Supabase Authentication URL Configuration

2. Keep Confirm email on

Open Email and make sure Confirm email is on, so every student account belongs to a real inbox — and you only ever enroll the person who owns it.

Supabase Authentication Sign In / Providers

3. Send emails from your own domain

Supabase's built-in email only reaches your own team's addresses, two emails an hour, so real students would never receive their confirmation email. Choose a provider such as Resend, Postmark, Amazon SES or Brevo, verify your domain there and create SMTP credentials. Then turn on Enable Custom SMTP and enter the sender email, sender name, host, port, username and password.

Supabase Authentication Emails SMTP Settings

Keep SMTP credentials in Supabase

Your SMTP password lets anyone send email as your domain. Enter it only in Supabase's SMTP settings — never in the app, an environment file, the repository or a Claude Code conversation.

Test the Live Platform

Open your live address and check:

The course library loads on your Hostinger address

New student: sign up with a real email address and confirm it from the inbox

Student: open a course they can access — enroll them first if you enroll manually

Student: move between lessons

Student: complete a lesson — the progress saves

Student: refresh — the progress is still there

Admin: sign in

Admin: update a course and publish the change

Student: sees the change

Restricted and draft courses stay locked

A copied resource link stops working after a few minutes

The platform works on a phone

Verify the Live Course Platform

Check the deployment, production sign-in, course access and secrets on the live platform.

Perform a focused production check of this course platform, now live on Hostinger. Read the "Course platform" section of CLAUDE.md first. Do not add features and never print secret values. Do not claim to inspect Hostinger or Supabase settings you cannot see — ask me for the live address, and ask me to confirm specific settings. 1. DEPLOYMENT - the deployment succeeded from the intended repository and branch - the required environment variables are set - no secret files are in the repository 2. SIGN-IN - the Supabase Site URL and Redirect URLs use the live address - Confirm email is on, and custom SMTP sends the confirmation emails - sign-in, sign-out and email-confirmation links use the live address, never localhost - refreshing a lesson or an admin page keeps the session and never shows a 404 3. ACCESS - run the Student A and Student B database checks against the production Supabase project, with the Publishable key — never the Secret or service-role key - draft courses, restricted lessons and resources stay protected - only the admin reaches the admin area 4. SECRETS - no secret key appears in the live site's code or network requests Return exactly one: PLATFORM LIVE or: NEEDS ATTENTION If PLATFORM LIVE, summarize the live address, sign-in, the course library, student progress, the admin area and access protection. If NEEDS ATTENTION, list only launch blockers.

Continue when Claude Code reports PLATFORM LIVE, confirming:

No secret keys appear in the live site's code or network requests

Before real students join

Unpublish or delete the sample courses you don't want students to see, then delete the Student A and Student B accounts in Supabase. Keep your own admin account.

Supabase Authentication Users

Expected result

Your online course platform is live on Hostinger with real courses, student accounts, saved learning progress, and a protected admin dashboard.