Courses, professors, payments and pages: the build plan (5 November 2026)

This plan covers everything in three inputs, and we build all of it:

• The CEO's build spec of 4 October: all 52 pages and panels.
• The wireframe set made from that spec: 46 frames, readable copy in notes/screens/courses-wireframe-2026-10-04.html.
• The founder's email of 5 November. Where it differs from the spec, we follow the email. Where the two simply add up (the spec's invite-only checks and the email's ten-minute setup, for example), we build both.

The open product questions left from October are decided here too, and built.

Nothing is cut, nothing is left for later, and nothing waits on a launch date. Three rules make that possible:

• Policy numbers are settings, not questions. Refund rules, how long recordings are kept, what counts as finishing a course, and so on, each get a sensible default and can be changed in a staff screen. Nobody has to answer anything before we build.
• Every outside supplier sits behind an adapter. Each one can be swapped for the best alternative without touching the database or the screens.
• We run every role ourselves while testing: professor, teaching assistant, student, parent, school, course admin, moderator, Child Safety Lead, Safety Admin and partner. John is the Safety Admin.

The wireframe is the design base. Every screen is aligned with how LinkedIn does it, or, where LinkedIn has nothing similar, with Maven, Outschool, Coursera, Google Classroom and Google Meet. Those are design references only; nothing connects to them.

Related notes:

• QUESTIONS-FOR-LATER-2026-11-05.md: things that don't affect building.
• COMMUNITY-GUIDELINES-DRAFT-2026-11-05.md: our draft, for John to review.
• WHERE-THINGS-STAND-2026-11-05.md: what's live and what's waiting today.

Nothing is built yet: no branches, no code.

The one-minute version

Courses are how Thnkrr makes money. A professor gets a personal invite and sets up a profile and a course in about ten minutes. Meanwhile, our team clears them:

• the background check, done under contract and recorded in the app, or run through a check company
• the signed agreement
• payout details

Once all three are done, the Verified badge goes on and the course can be published.

Each course can be "open" (students enrol straight away) or "by application" (our team picks, with a waitlist). A place is paid for in one of three ways:

• by a school, which buys a block of places on one bill
• by a parent, through a simple checkout and their own parent account
• by a free-place code after a hardship check

The parent always agrees to the classes being recorded.

Live classes run inside Thnkrr on Amazon's Chime video service. That covers host controls, breakout groups, polls, Q&A and live captions. Every recording stays on our own storage.

Students also get:

• coursework, including files and short videos
• peer feedback from their group
• a group workspace
• a class discussion and Q&A board
• surveys
• a certificate in the "Verified achievements" section of their profile
• a fast-track code for the partner's own programme

Partners see a read-only page of outcomes. It never includes messages, work or names.

The email's page and profile changes are built too:

• follower counts, behind switches
• page posts to followers, newest first
• classmates connecting across schools
• college pages that build themselves from the professors and mentors who join
• a "Programs and courses" tab that comes first on pages
• committed colleges linking to their college page
• Verified badges for professors and mentors

What people pay for: Thnkrr before and after

Thnkrr stays free. Nobody pays to use the network, and there is no premium tier, no ads and no paid features. Money buys exactly one thing: a place for one student in one course. A place is $249 for the first course (the default from the CEO's outline; staff can change any price). It covers the whole course.

Who pays:

• A parent pays for their own child.
• A school pays for a group of its students.
• A free-place code covers a student who qualifies after a hardship check.

The money goes to Thnkrr, and Thnkrr pays the professor and the teaching assistants through the app. Card details stay with Stripe, the payment company, and never touch Thnkrr.

How students get a place:

• A school that pays chooses which of its students get its places.
• In an "open" course, other places go to whoever signs up first.
• In a "by application" course, our team picks from the applications, and the rest join the waitlist.

Recording is separate from paying. Every class is recorded, for safety and so students can catch up. However the place is paid for, a parent agrees to recording before the student's first class.

Settings instead of questions

Every policy number lives in one staff "Settings" screen with a default. Changing one is a click, recorded in the audit trail, and never needs a code change. Some settings can be set per course or per partner, where that makes sense.

Who does what while we test

We run the whole thing ourselves, first on the laptop and then on dev.thnkrr.com:

• Adarsh and Naman play professor, teaching assistant, course admin, moderator and Child Safety Lead.
• John is the Safety Admin: he sees every case and gets the missed-deadline emails.
• Students, parents and school staff are test accounts on the team Gmail with + addresses, as today.
• A partner viewer is a test account too.

None of this needs anyone outside the team, and every outside service has a test mode we set up ourselves:

Every AWS step (turning on Chime, Transcribe, texting, and the new recordings storage) is done with Adarsh's go-ahead for each command, as always.

We also add a pnpm db:seed:courses command, on the same pattern as the rich demo data. It fills dev with:

• professors at two universities, plus teaching assistants
• a published course with two class groups
• a school order, and parents who have paid
• free-place codes
• an application course with a waitlist
• past classes with recordings and coursework
• certificates
• a partner viewer

Decisions we've made

These are ours to make, and easy to change. Each becomes a numbered decision (D-93 onward) when it's built.

1. Professors and teaching assistants join by personal invite from the team screen (D-89), then set themselves up in about ten minutes. There is no public sign-up.

2. New account kinds: "professor" and "partner viewer". A teaching assistant is a "professor" account with the teaching-assistant role on a course, or an existing mentor account added as course staff. A person's account kind stays fixed for good (D-64).

3. A professor is cleared by four steps, which staff track in the app:

   • identity
   • background and registry checks, including state clearances such as Pennsylvania's Act 153
   • a signed agreement and the code of conduct
   • payout details

   The founder's "we handle verification under contract" is the built-in way to clear the checks: staff record the result. A check company can do it instead, through its adapter.

4. The Verified badge is a shield next to the name, separate from the school tick students already have. Clicking it says "Verified by Thnkrr: background and identity checked, [month year]". It never says "safe". It goes on when every step is clear, and comes off by itself when the re-check is due. It's for professors, teaching assistants and mentors.

5. Professors can draft before they're cleared, but can't publish, see students or teach until the badge is on.

6. The professor submits a course and a course admin publishes it (the wireframe's open question 18). The course admin sets price, places, class groups, free places and the partner tag.

7. A partner tag ("Curriculum by [partner]") shows once staff have approved that partner. It's the university name in text, with no logo.

8. Parents get accounts. They sign in with an emailed link or a passkey and have a dashboard. Parents who never sign in still get everything they need by email, with single-use links, as the consent email works today (D-68).

9. Live video runs on Amazon Chime, behind our own adapter. Chime carries only sound and picture. Chat, raised hands, polls, Q&A and breakout moves go through our own server, so every message is checked before anyone sees it. That needs a new live connection from the browser to our server; today the app only checks for updates every 30 seconds.

10. Breakout groups are separate Chime rooms, each one recorded. Our server only lets a group open with at least 4 students, or 1 student with a teaching assistant. A student can never be alone on video with one adult.

11. Captions:

    • Recordings get captions from our own speech-to-text (already running) as a WebVTT file.
    • Live captions use Amazon Transcribe. Naman to OK: D-70 says every AI model we deploy runs on Bedrock, and Transcribe isn't Bedrock. With it, we switch on AWS's account-wide setting that stops Amazon keeping or learning from the audio. The accessibility standard (WCAG AA) asks for live captions.

12. Recordings go to their own locked storage, encrypted with their own key, and expire on the settings above. The video company keeps no copy.

13. Payments, all through Stripe behind adapters:

    • Hosted checkout for parents.
    • Invoices from the app for schools.
    • Stripe Connect for paying professors and teaching assistants.
    • Stripe Tax, switched on per state when needed.
    • Codes kept in our own tables.

14. School places are given out by a teacher choosing students from the class list, with a seat counter. A school can also hand out single-use place codes, if it prefers.

15. Free places and scholarships: the student uploads a hardship document with the application; staff review it and issue a code. The document is kept only until the review is done.

16. Coursework answers can be written, a file (PDF or images, up to 25 MB) or a 2-minute video.

    • Files go through a new document check. Each page is turned into a picture and run through the picture checks, and its text through the writing check.
    • Videos go through the existing video pipeline, where a person reviews every one.
    • Only the course staff and our team ever see a submission.

17. Peer feedback: two groupmates give feedback using set prompts, and it's checked like any comment. It's anonymous to the student who receives it, but never to our team.

18. Each course gets a class discussion, a separate Q&A board (questions, upvotes, answered and unanswered filters, the professor's answers highlighted) and surveys (before the course, a two-question check-in after each class, and an end-of-course survey).

19. Group workspace for each group of five:

    • a shared plan document that everyone can edit at once
    • a task list
    • a group chat
    • a slot for their presentation

    Everything in it is checked, and the screen says that course staff can read it (the wireframe's open question 15).

20. Certificates go into "Verified achievements" on the profile, with an "Add to your profile?" prompt where Add is the main button. Each one has a check page.

21. Fast-track codes: staff generate them per partner and give them to students who finish. Redemptions are tracked.

22. Partner reports show totals only:

    • enrolled, finished, applications, and joining the partner's programme
    • by area and by household-income band, where the student chose to answer an optional question on the application
    • a safety summary

    Any group smaller than 10 is hidden. Messages, coursework and recordings are left out by how the report is built, not by a filter.

23. Following:

    • Anyone can follow a page or a professor.
    • A student's followers are their connections, so strangers can't follow a child.
    • Students follow their own school's page automatically, and can unfollow.

24. Follower counts: three switches (pages, adults, students), with numbers rounded the LinkedIn way. Students start off until Obsinto answers; the switch is one click.

25. Page posts:

    • A school page's admins can post.
    • College pages are posted to by our team.
    • Posts are checked, and shown to followers newest first, with no ranking.

26. "Programs and courses" is the first tab on every page. It lists that school's Thnkrr courses and any outside programmes our team adds, such as a college's summer programme.

27. A college page appears by itself once at least one verified professor or mentor lists that university.

    • Title: "Professors and mentors from [School] on Thnkrr".
    • The name in text on an optional accent colour, with no logo.
    • Staff can hide one, or set its colour.

28. Our two college lists are merged into one, so mentors, professors, committed colleges and college pages all point at the same college.

29. Classmates can see each other's basic card and connect across schools, during the course and for 30 days after. The invitation shows the reason, adults are never suggested, and the usual rule holds: no messages until both accept.

30. Courses becomes the fifth item in the student menu (after Feed, Mentors, Network and Messages). Mentors, teachers, professors and parents get it in their own menus.

31. The open October questions, decided:

    • A student's account is marked "graduated" after high school, and they can switch to a mentor account when they start college, checked like any new mentor.
    • Teachers need a school email, or to be vouched for by their school's page admin.
    • A mentor's unlisted college is added when we verify the mentor.
    • Someone under review is hidden from suggestions and search, and can't like or accept requests.
    • The occasional-bully check and the video settings are as in the Settings table.
    • A school's students join through the school's own join link (D-89), a few classes at a time.
    • A person checks every photo and video before anyone else sees it (D-9, as today).
    • Only the Child Safety Lead and the Grievance Officer can ban. A moderator can suspend for up to 7 days. The person is always told why, except in child-safety and intimate-image cases (as built).

32. Every outside supplier sits behind an adapter, and nothing in our database or screens depends on one (next section).

Every outside supplier is replaceable

Chime, Stripe, Transcribe and anything else we bring in are suppliers. We plug them in, and we can unplug them. Swapping one for the best alternative must never need a database change, a new screen, or a rewrite outside one folder.

The app already works this way for files, email, the AI writing check, picture checks and video captions. Each has one small interface in our own words, one file per supplier, and a fake that the tests run every day:

• the interface and supplier files: src/lib/image-screen.ts with image-screen-rekognition.ts, and storage.ts, mailer.ts, transcriber.ts
• the tests: test/unit/seams.test.ts
• the write-up: PLUG-AND-PLAY-AUDIT-2026-10-10.md

The courses work follows the same pattern, with six rules.

1. One interface per job, in our words. Code outside the adapter never loads a supplier's library, and that includes the website. The classroom screen talks to our own VideoRoom interface, and only the Chime adapter loads Chime's library. We draw our own classroom screens rather than using Chime's ready-made kit.

2. No supplier names in the database.

   • Tables are named for our things: payments, class_rooms, recordings, background_checks.
   • Where we must find the supplier's copy again, a row carries provider (plain text, such as "stripe") and provider_ref (the supplier's ID, as opaque text). Nothing else.
   • Amounts are our own cents and currency, and statuses are our own words.
   • Raw supplier messages go in a short-lived log for fault-finding only.

3. Our own records are the truth. Our tables hold:

   • who is enrolled
   • holds, refunds and payouts owed
   • attendance and grades
   • when a recording expires
   • each check's result
   • who has the Verified badge

   A supplier only confirms that something happened, and its messages are translated at the door into our own events: "payment succeeded", "refund done", "school bill paid", "payout sent", "class ended", "recording ready", "check clear", "agreement signed".

4. We keep our own copy, in open formats:

   • recordings as MP4
   • captions as WebVTT
   • certificates and partner reports as PDFs we make ourselves
   • calendars as standard .ics files
   • signed agreements as a PDF with our own evidence log
   • our own copy of every bill

5. Every adapter has a fake, and one shared test every real adapter must pass. The laptop, the dev demo data and the automatic tests use the fakes. Choosing a supplier is one setting.

6. The swap test. Replacing a supplier touches only its adapter file, one setting, and at most a one-off copy of files. It never touches a table, a screen or another module.

What a swap really costs. No data moves and no tables change, but the new adapter still has to be written: about one to two weeks for video, about a week for payments, a few days for the rest. The fakes and shared tests add about a week up front, and they save time straight away, because nobody needs a real Chime room or a real card to work on the app.

Where this changes our own safety rules

Thnkrr's founding rules (docs/13, docs/03, docs/04) were written to keep children safe. Several of these features cross them. We build each one deliberately, with its own protection, and the lawyer and Obsinto get the list. All of it goes into the decision log.

• Public numbers. Our rule was "if it makes a number go up publicly, it doesn't ship". Follower counts and Q&A upvotes reverse that. Protection: the three switches, rounding, and students' counts off by default.
• Students across schools. Thnkrr promised "your school, not strangers". Protection: classmates connecting is limited to people in the same course, for a fixed time, with the reason shown.
• Adults teaching children. Our rule is that an adult never reaches a child who didn't reach out first. Protection:
  • professors and teaching assistants speak to the class or the group, never privately
  • no direct messages in the courses part of the app at all
  • feedback is only on work the student handed in
  • our team can see everything
  • no breakout room with one student and one adult unless it's recorded and the rule above allows it
• Group spaces. The class discussion, Q&A, group chat, shared document and live chat are Thnkrr's first group spaces. Protection: everything is checked before it shows, with the stricter bar used where an adult is present, and Report is one tap away everywhere.
• Files and videos from children. Protection: the new document check plus the existing video review, and only course staff and our team can see them.
• Partner access. Protection: totals only, small groups hidden, and messages, work and recordings left out by how the reports are built.
• Roster downloads. The spec lets professors download their class list. Protection: no contact details in it, and every download logged.

The build, in order

Each part is finished and tested (laptop first, then dev.thnkrr.com) before the next one leans on it. The video work starts in parallel with parts 2–6, because it's the biggest piece.

Part 0 · Foundations

• Merge the team screens (D-89).
• The adapter pattern and fakes for every supplier above.
• The Settings screen.
• The live connection.
• New roles: professor, teaching assistant as course staff, course admin as a staff role, partner viewer, parent account.
• The courses data model.
• The db:seed:courses demo data.

Part 1 · Professors and teaching assistants (wireframe D1, E6)

• Invite.
• Ten-minute setup: account and agreement, then profile (photo, title, university from the merged list, bio of up to 600 characters with a paste box, preview), then "create your first course".
• Clearance tracker: identity; checks (submitted, clear, action needed, expired); registry and state clearances; agreement signing; code of conduct; payout setup.
• Verified badge and its expiry, with the re-check reminder.
• Deactivate.
• Professor profile page in LinkedIn's top-card style.

Part 2 · Building and publishing a course (D2, D3, E1)

• Professor dashboard with the set-up checklist, next class, marking to do, unanswered questions and announcements.
• Course builder, in Teachable and Udemy style, with the publish checklist blocking publish until it's complete:
  • settings: title, summary, description, syllabus file, subject, grades, partner tag, eligibility, places, dates, class groups
  • session editor: plan, materials, reading, assignment, ready-made polls
  • rubric editor
  • survey builder: single, multiple, scale, open
  • group tool: automatic groups of five, drag to adjust
• Course admin catalogue: create or copy a course, assign professor and teaching assistants, price and partner terms, free places, approve the partner tag, publish and unpublish.

Part 3 · Finding and joining a course (A1–A6, E2)

• Courses page: LinkedIn Learning-style cards, filter pills (subject, format, partner, price, start date, eligible for me), and open, waitlist and closed states.
• Course page: Maven layout, with the box that stays in view.
• Application, for "by application" courses: a three-step LinkedIn Easy Apply-style form with a goal (140 characters), a paragraph (600 characters), school filled in, grade, an optional income question, a free-place request with document upload, and the parent's email. It autosaves.
• Application status, with every state.
• Staff application review: filtered list, applicant card, accept, waitlist or decline with templates, bulk accept, audit trail.
• Enrolling:
  • direct for open courses
  • school places via the teacher's picks or codes
  • parent checkout: consent, refund rule, recording consent and data notice, then Stripe (card, Apple Pay, Google Pay), then a receipt
  • free-place version with no payment
  • 18-year-olds paying for themselves
• Confirmation: next class, "Add to calendar" (Google, Apple, .ics), what to prepare.

Part 4 · Parents (C1, C2)

• Sign-in by email link or passkey.
• Dashboard:
  • each child, their courses and next class
  • attendance
  • assignment names and status only
  • receipts
  • consent records with the re-confirm date
  • withdraw and ask for a refund
  • notifications, including texts
• The email-only route for parents who never sign in.

Part 5 · Money (E3, E7)

• School orders and bills from the app: quote, invoice, places used, paid or not, "mark paid" for cheques.
• Parent payments: refunds with a reason, disputes.
• Codes: coupons, free places, partner referral tracking.
• Payouts to professors and teaching assistants through Stripe Connect, with a payout summary.
• Stripe Tax, switched on per state.

Part 6 · Taking the course (B1–B3, B5–B9, D4, D6, D8)

• My Courses, in LinkedIn Learning "My Library" style, with progress and certificates.
• Course home, with Google Classroom-style tabs: Home, Sessions, Coursework, Discussion, Q&A, Group, People.
• Session page: plan, reading, materials, and Join or the recording with its expiry, captions, and chapter jumps.
• Assignments: written, file or video answers; peer feedback; the teaching assistant's rubric score and feedback; release, with approval if the course requires it; bulk release; a late filter.
• Boards: the class discussion and the Q&A board.
• Surveys: before the course, after each class, and at the end.
• The group workspace.
• Class list for course staff: class group, group, consent, attendance, coursework, flags, and a download.
• Announcements: write, schedule, choose who gets them, delivery log.

Part 7 · The live classroom (B4, D5, X2)

• "Ready to join?" screen: camera, microphone, the recording notice and consent check. It opens 15 minutes before the class.
• The professor starts the class and the room is created. Only enrolled, consented students and the course staff get in.
• Layout, Google Meet style:
  • video stage
  • one right-hand panel with Chat, Q&A, People (raised hands in order) and Polls
  • a recording dot with the consent line
  • a breakout marker
  • a bottom bar of controls
• On phones: tabs for Chat, Q&A and Poll.
• Host controls:
  • start and end
  • recording on by default, paused only with a logged reason
  • launch a poll
  • breakouts by group
  • mute all
  • spotlight
  • lower hands
  • remove someone
  • hide, warn or escalate a chat message
  • answer and mark questions
• Attendance is taken automatically.
• States: offline, reconnecting, camera blocked, video service down, no consent.
• Live captions, and fully usable by keyboard.

Part 8 · Finishing (B10, E7)

• Certificate: a PDF with a check link and a check page, and an "Add to profile?" prompt. It shows in Verified achievements and as a milestone on the student's own profile.
• Fast-track codes: per partner, given to finishers, redemptions tracked.
• The end-of-course survey.

Part 9 · Reports and partners (D7, E5, F1)

• Course reports: attendance, finishing, coursework rates, poll and survey results, Q&A activity, and downloads.
• Partner reporting: the totals in decision 22, as PDF and spreadsheet downloads, plus a preview of the partner's own view.
• The partner's read-only page, with the fixed line: "No student messages or submissions are shared with partners."

Part 10 · Moderation for courses (E4)

• New sources go into the existing review list:
  • class chat, discussion, Q&A, group chat, the shared document
  • peer feedback and teacher feedback
  • files and video answers
  • bios and course text
• A "response time" measure is added.
• Escalation goes to the Child Safety Lead, as today.

Part 11 · Pages and profiles

• Follow, the count switches, and page posts.
• The "Programs and courses" tab.
• Auto-built college pages, on the merged college list.
• Committed-college links.
• Classmates finding each other.
• Verified achievements.
• The Verified badge everywhere a name appears.

Part 12 · The October decisions

• Graduation, and switching from student to mentor.
• Teacher vouching.
• Adding a mentor's college when we verify them.
• Hiding someone under review.
• The occasional-bully check.
• The video settings.

Part 13 · Across everything (X1, X3–X5, K1)

• Empty, error and loading states on every list.
• Notifications for every event in the spec, with no "come back" nudges.
• The .ics calendar feed.
• Times stored once and shown in each person's own time zone.
• WCAG 2.2 AA throughout.
• No third-party tracking on any course page.
• No streaks or autoplay on course pages.
• The landing page wording fixed: it still promises "XP, streaks and badges".

Part 14 · Community Guidelines in the app

• The draft in COMMUNITY-GUIDELINES-DRAFT-2026-11-05.md becomes a page in the app, linked from sign-up, the footer and every removal notice. John reviews it.

The wireframe, screen by screen

Changes to every screen:

• Dates and room size come from the course settings, not fixed text. The frames show November 2026 and one room of 60.
• The LinkedIn top bar: icon-and-label items, search, a "Me" menu, a dot (not a number) on notifications, and Courses in the menu. Drop the "STUDENT" role tag and the "Milestones" item.
• A bottom tab bar on phones, instead of "MENU".
• One safety notice per course, instead of "AI-SCREENED" tags on every panel. Each place you write keeps one helper line.
• Phones: labels of at least 12 points, and 44-pixel tap targets. "Report" is an icon you can reach in one tap.
• No partner seals or logos. The partner and university are plain text, linking to the college page.
• The Verified shield next to every professor's, teaching assistant's and mentor's name.
• Add an error colour (open question OQ-08).

Screens to draw that the wireframe doesn't have:

• the professor's public profile
• the college page
• Follow and counts
• the class People tab
• Verified achievements
• the Settings screen
• school orders and the teacher's place picker
• payouts
• the fast-track codes screen (E7)
• the clearance tracker from the staff side

Testing

Each part is tested as it's built:

• Every test suite runs once on the laptop for each part, plus new stress tests and checks that nothing old broke.
• The laptop run is the gate before any merge or release; GitHub's tests aren't needed.
• Then we test by hand on dev.thnkrr.com, as every role, before anything goes to the live site.

End-to-end journeys we run on dev with real test-mode suppliers:

• A professor is invited, sets up in ten minutes and is cleared, and their course is published.
• A school order is billed and paid, and the teacher picks students.
• A parent pays with a test card and then gets a refund.
• An application course: accept, waitlist, an offer from the waitlist.
• A free-place code is used.
• A live class with six browsers and two phones: breakouts, a poll, Q&A, live captions, a reconnection, and the recording and captions arriving.
• Coursework is handed in as text, file and video, with peer feedback and marking.
• A certificate and a fast-track code are issued.
• The partner report is run.
• Something is reported in each new space, and the case reaches the Child Safety Lead.
• John, as Safety Admin, gets the missed-deadline emails.

How big it is

Rough sizes, in person-weeks of work, to help plan who does what. Not a launch date.

What it costs to run

For scale: one course of 60 places at $249 brings in $14,940. Stripe takes about $450 of that if every place is paid by a parent.

Reply to the founder on video (draft)

Agree it with Naman before sending.

Video. We recommend keeping it inside Thnkrr using Amazon's Chime, as you suggested. There are no outside links. Only enrolled students and the course's teachers can get in, the professor starts and ends the class, and every recording, including small-group breakouts, goes straight to our own storage. Nobody else keeps a copy.

Cost. About $5 for each hour-long class of 30 students plus the professor and two assistants, including recording and live captions. Our AWS credits cover it. At 10 courses a month it's roughly $600 a month; at 50, about $3,000.

Effort. The full classroom, with host controls, breakout groups, polls, Q&A, captions and phones, is the biggest single piece of the courses work. It's about 12–16 weeks of one person's work, and we start it alongside everything else.

What else we looked at. Zoom keeps recordings on its own servers first. Two smaller video companies would be billed as real money, not covered by AWS credits, and would add another company handling children's video. Amazon's other video service can't fit a class of 30.

Can we change it later? Yes. We're building it so the video company can be swapped without changing anything students or professors see.

Risks

• The classroom is the biggest piece and the newest kind of work for us. A two-day Chime trial comes first (join from a phone, recording lands in our storage, the no-keeping setting is on), then the full build.

• Chime gets less attention from Amazon than it used to. The service itself is supported, and the adapter keeps LiveKit one swap away.

• Checking chat takes 2–4 seconds today. The spec wanted under a second; students see "checking…" briefly. We measure it in the trial.

• A shared document that everyone edits at once is fiddly to build and to check. Each saved change is checked before others see it.

• Checking children's files needs the new document check before file answers can go to the live site.

• The college-list merge touches mentors and committed colleges that already exist. It's a careful data job with its own dry run.

• Things only the company can do before real money and real students:

  • Stripe live mode with the company's details
  • the lawyer's review of everything new
  • Obsinto's answer on counts and cross-school classmates
  • each school's data agreement
  • the partner's approval of its name

  None of these blocks building or testing; they're listed in QUESTIONS-FOR-LATER-2026-11-05.md.

Sources

Inputs

• CEO build spec, "The Courses page: build spec", 4 October 2026 (Downloads/Thnkrr Courses Page Build Spec - Summary (1).docx).
• Wireframe set, 4 October 2026 (Downloads/Thnkrr Pre-College Program Courses (1).html), readable copy in notes/screens/courses-wireframe-2026-10-04.html, including its 18 open questions.
• Founder's email, 5 November 2026.
• notes/WHERE-THINGS-STAND-2026-11-05.md, notes/FOUNDER-MEETING-PREP-2026-10-28.md, notes/POST-PILOT-2026-10-29.md, notes/ROLES-AND-JOURNEYS-2026-10-27.md, notes/PLUG-AND-PLAY-AUDIT-2026-10-10.md.
• thnkrr-api docs 02 (LinkedIn product research), 03, 04, 06, 08, 09, 11, 13, 15, 22, 25 and 26, and the decision log (D-4, D-5, D-18, D-21, D-36, D-38, D-64, D-68, D-69, D-70, D-73, D-74, D-76, D-89).

Video

• Amazon Chime SDK pricing: https://aws.amazon.com/chime/chime-sdk/pricing/
• AWS price list for Chime, us-east-1: https://pricing.us-east-1.amazonaws.com/offers/v1.0/aws/AmazonChimeServices/current/us-east-1/index.json
• Amazon Transcribe pricing: https://aws.amazon.com/transcribe/pricing/
• Update on support for Amazon Chime: https://aws.amazon.com/blogs/messaging-and-targeting/update-on-support-for-amazon-chime/
• Chime meeting transcription: https://docs.aws.amazon.com/chime-sdk/latest/dg/meeting-transcription.html
• Chime media pipelines and limits: https://docs.aws.amazon.com/chime-sdk/latest/dg/media-pipelines.html and https://docs.aws.amazon.com/chime-sdk/latest/dg/media-pipelines-limits.html
• Managing several Chime meetings (breakouts): https://aws.amazon.com/blogs/business-productivity/multi-meeting-management-with-the-amazon-chime-sdk
• Chime React components: https://github.com/aws/amazon-chime-sdk-component-library-react
• Amazon IVS limits: https://docs.aws.amazon.com/ivs/latest/RealTimeUserGuide/service-quotas.html
• Daily pricing: https://www.daily.co/pricing/video-sdk/
• LiveKit pricing: https://livekit.com/pricing
• Zoom Video SDK pricing: https://www.zoom.us/pricing/developer
• AWS credits and Marketplace: https://repost.aws/questions/QU4Y95rs6UR96952zNb3pnaQ/aws-credits-for-purchases-on-the-aws-marketplace

Payments

• Stripe Checkout sessions (24-hour limit, reference ID): https://docs.stripe.com/api/checkout/sessions/create
• Stripe pricing: https://stripe.com/pricing
• Stripe Invoicing pricing: https://stripe.com/invoicing/pricing
• Creating invoices: https://docs.stripe.com/api/invoices/create
• Marking an invoice paid outside Stripe: https://support.stripe.com/questions/marking-an-invoice-paid-out-of-band
• Bank transfers: https://docs.stripe.com/payments/bank-transfers
• Stripe Connect pricing and Express accounts: https://stripe.com/connect/pricing and https://docs.stripe.com/connect/express-accounts
• Connect 1099 forms: https://docs.stripe.com/connect/1099-NEC
• Stripe Tax pricing: https://stripe.com/tax/pricing
• Stripe Managed Payments eligibility: https://docs.stripe.com/payments/managed-payments/eligibility
• Paddle's restricted list: https://www.paddle.com/help/start/account-verification/what-am-i-not-allowed-to-sell-on-paddle
• Washington tax on live presentations: https://dor.wa.gov/taxes-rates/live-presentations
• Are online classes taxable (Avalara): https://www.avalara.com/us/en/blog/are-online-classes-subject-to-sales-tax.html
• SOPIPA at a glance: https://fpf.org/wp-content/uploads/2016/03/SOPIPA-At-a-Glance.pdf

How big platforms do it

• LinkedIn Learning search: https://www.linkedin.com/learning/search?keywords=leadership
• Coursera search: https://www.coursera.org/search?query=leadership
• Maven course page and student home: https://maven.com/maven/course-accelerator and https://help.maven.com/en/articles/9081204-student-home
• Outschool teacher launch steps: https://outschool.com/educators/handbook/launch-your-first-class-step-by-step
• Outschool parent and learner profiles: https://support.outschool.com/articles/1481632-parent-and-learner-profiles
• Outschool class buyouts: https://support.outschool.com/en/articles/15863060-a-guide-to-class-buyouts-on-outschool
• Outschool time zones: https://support.outschool.com/articles/2400577-time-zones-and-time-changes
• Outschool learner safety: https://outschool.com/educators/handbook/the-5-steps-to-protecting-learner-safety
• Udemy course goals: https://support.udemy.com/hc/articles/229604888-Adding-Course-Goals
• Teachable curriculum tool: https://teachable.com/ai-curriculum-generator
• Google Meet controls: https://support.google.com/meet/answer/13584351
• Google Classroom: https://support.google.com/edu/classroom/answer/9582854
• LinkedIn Learning for Teams: https://www.linkedin.com/help/learning/answer/a768297
• LinkedIn Add to Profile: https://addtoprofile.linkedin.com
• LinkedIn verification: https://www.linkedin.com/help/linkedin/answer/a1492056
• LinkedIn Pages tabs: https://www.linkedin.com/help/linkedin/answer/a567083
• Khan Academy under-13 accounts: https://support.khanacademy.org/hc/en-us/articles/202487460-If-my-child-is-under-age-13-what-login-options-are-there-