# FinStack IQ — Demo Day Design Brief **Audience:** Val Chapman, Lisa Love, and design review (including NotebookLM) **Author context:** Engineering review of the existing proof of concept, November 2026 **Demo Day:** Wednesday, December 9, 2026 (Kapor Center) **Time available:** about 30 days **Status:** Direction is clear. The exact lesson scenario and a few product choices are still open. This is a proof of concept, not a production school product. --- ## 1. The one sentence we should all be able to say By Demo Day we will show this: **A student answers a short personal-finance question. That answer is saved. The teacher, on another screen, sees almost immediately that the class is missing a concept and needs a reteach.** That is the product proof. Everything else is supporting material or a later phase. Investors should leave believing two things at once: 1. Students actually do something (they engage with a real lesson). 2. Teachers get something useful from that activity (they can see what the class does not understand). Teachers and districts decide whether to adopt. The teacher insight is the point of the demo. Student engagement is how we generate that insight. --- ## 2. What “done” looks like on December 9 A guided demo, about three to five minutes, along these lines: 1. A teacher has a class and a join code. 2. A student opens the grades 9–12 course, joins that class, and works through one short scenario (one unit or one check, not the whole semester). 3. The student answers at least one question incorrectly. 4. The teacher view updates without a manual refresh. 5. The teacher sees a class-level signal: this concept or question is being missed, so it is a candidate to reteach. 6. The numbers on the teacher screen come from saved data, not from a fake sample class. **The story we tell:** “Students do the work. Teachers see what to teach next.” **The story we do not center:** XP, streaks, badges, levels, or “gamification points.” Those can remain visible in the student interface because they already exist. They are not the reason a district would buy this. ### Acceptance in plain language | Check | Pass means | | ---------------------- | ------------------------------------------------------------------------------------------------------------ | | Student action is real | Someone clicks an answer in the course | | Data is saved | Closing the browser and opening it again does not erase that answer | | Teacher sees the class | The teacher screen shows that student and the miss, not 24 made-up names | | The insight is useful | A non-technical viewer can say, in under ten seconds, “the class is stuck on this idea” | | It is honest | We say this is a proof of concept. We do not say it is ready for real student records or district compliance | --- ## 3. Who this is for in the demo | Person | What they do in the demo | What they care about | | ------------------------- | ---------------------------------------------------- | ------------------------------------------------------ | | Student (grades 9–12) | Joins a class and answers a short money question | The lesson feels real | | Teacher | Watches the class result and decides what to reteach | “Where is my class confused?” | | Investor / Demo Day guest | Watches the loop once | Proof of engagement plus a reason a school would adopt | | District admin | Not the star of this demo | Adoption, compliance, and rollout come later | We will use **scripted demo accounts and nicknames**, not real students. Do not use real names, emails, essays, photos, or voice recordings in this proof. --- ## 4. What already exists (so we are not starting from zero) FinStack IQ already has two web pages, built in Claude and now stored in GitHub: ### A. The Course (`FinStack-IQ-Course.html`) This is the grades 9–12 semester experience. - Students move through units (banking, budgeting, credit, and so on), answer checks, and see progress. - Teachers already have an **Educator dashboard** with overview, student list, writing, and pacing materials. - The teacher dashboard already has the _idea_ we need: first-try accuracy, most-missed questions, and who needs attention. **This is the app we will use for Demo Day.** ### B. The Platform (`FinStack-IQ-Platform.html`) This is a separate educator shell: Studio tools, Student Rooms, a District view, and Training. - It looks like a broader product vision (planning tools, AI helpers, district dashboards). - Its “live class” table is sample students. It does not currently read what students do in the Course. - Sign-in, rostering, learning-management systems, and billing are not connected. The page itself says so. **For Demo Day, the Platform can be a short product tour if we want to show the vision. It is not the proof.** ### C. The middle-school game (separate Vercel app) A different pilot for younger students. **Out of this build.** We will not connect it before December 9. --- ## 5. The problem in the current build The screens are far along. The shared memory is not. Today, when you open the Course on a normal website: - A student’s answers are saved **in that browser only**. - The teacher dashboard shows a **sample class of 24 fictional students** (names like Falcon and Otter) unless the page is running inside Claude’s special hosting. - The Platform and the Course **do not share data**. So a teacher cannot yet sit on another computer and see what a student just missed. That gap is the engineering work between now and Demo Day. Claude was useful for building the pages quickly. Moving the product onto FinStack IQ’s own hosting means replacing three Claude-only services over time: 1. Knowing who is logged in 2. Saving student progress in a shared place 3. AI features (optional for this demo) --- ## 6. Target design for the proof of concept ### Plain-language picture ``` Student browser Teacher browser (Course lesson) (Course teacher dashboard) | | | "I answered this question wrong" | "Show me the class" v v One shared database (Supabase) classes, who joined, each answer ``` Two pieces. No custom server for the proof of concept. | Piece | What it is | Analogy | | ------------------- | -------------------------------------------------------------------------------------------- | ------------------------------ | | **Course web page** | The screens we already have, hosted as a normal website (for example GitHub Pages or Vercel) | The storefront | | **Supabase** | A managed database plus a built-in door for the website to save and read rows | The filing cabinet with a lock | The website **writes** when a student answers. The website **reads** when the teacher opens the dashboard and the page adds up misses for the class. There is no separate FinStack “application server” in this first version. The page talks to the database directly. Access rules live in the database (who may see which class). That is an intentional shortcut so we can finish in about 30 days. ### What we save from day one Each student answer becomes one small record: - Which class - Which student (demo nickname or demo account, not a real school ID) - Which unit and which question or concept - Whether the answer was correct, and whether it was the first try - When it happened From those records the teacher view can show: - How much of the class missed a concept - Which questions are the best candidates to reteach - That a specific demo student is stuck We do **not** need to save XP, full essays, chat transcripts, photos, or voice for this proof. ### What “almost real time” means When a student submits an answer, the teacher screen should update within a few seconds without someone clicking refresh. Supabase can push that update. If the live push hiccups, a short automatic refresh is an acceptable backup for Demo Day. ### What we are explicitly postponing | Later | Why it waits | | ------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | | Our own API server that validates every action | Extra build. Useful when rules get strict. Not required to prove the loop. | | Connecting the Platform so it shows the same class data | Right long-term goal. Second product surface. Not required to prove the loop. | | District dashboards, LMS, Clever, ClassLink, billing | Vision screens. Sample data today. | | AI lesson generators and the in-lesson coach | Nice for a later beat. Needs a server so API keys never sit in the website. | | Real school logins and real student records | Privacy and compliance work. Demo uses fake identities. | | Rewriting the Course into a new frontend framework | The current page is rough engineering, but the lesson and teacher screens are the asset. We adapt them. | --- ## 7. How this grows up later (so founders know we are not stuck) Today’s shortcut: **Website → database** A later, more controlled version: **Website → our own small API → database** That API is where we would put rules the browser should not be trusted to enforce: stricter validation, audit logs, AI calls, and shared logic for both the Course and the Platform. Supabase can host that API later (Edge Functions) without throwing away the database. We are not painting ourselves into a corner. We are choosing the smaller door for December. The Platform reading the same answers as the Course is the natural next milestone **after** the Course loop is reliable. --- ## 8. Design principles for the 30 days 1. **One loop, done credibly.** Student answer → saved attempt → teacher reteach signal. 2. **Reuse the Course screens.** Do not rebuild the curriculum UI. 3. **Real data only in the live demo path.** If nobody has joined, the teacher sees an empty class, not fictional students. 4. **Teacher insight over game points.** Lead the teacher screen with “what to reteach.” 5. **Demo honesty.** Label simulated areas if we show them. Do not imply district-ready privacy compliance. 6. **Protect the original files.** New work stays on a branch. The Claude originals on the main branch stay as the baseline. 7. **No real student data** until privacy, access control, and agreements are in place. --- ## 9. Suggested demo script (content still flexible) Until Val and Lisa lock the exact scenario, engineering can keep using any existing Course check (for example a quick question inside Unit 1, Banking). The _mechanism_ does not depend on which question we pick. The _story_ does. Ideal scenario shape: - One situation a 9–12 student recognizes (first paycheck, a scam text, a credit choice, and so on). - One or two questions with a clear right idea and a common misconception. - A teacher line we can say out loud: “Half the class missed how apprenticeships work. That is tomorrow’s five-minute reteach.” When the scenario brief arrives, we point the demo at that question. We do not need a new course. --- ## 10. Thirty-day plan (engineering view) Rough order. Dates are planning anchors, not promises. | When | Outcome | | --------------------------- | ------------------------------------------------------------------------------------------------------------------- | | Now (started) | Local database and Course wiring so a real miss can show up for a teacher. Branch: `init-db-migration`. | | Week of Nov 3 | Lock the scenario, the demo format, and demo identity with founders. | | Next | Put the Course on a stable public web address, and put the database in hosted Supabase (not only on a laptop). | | Following | Tighten who can see which class. Seed demo teacher and students. Make the teacher screen lead with reteach signals. | | Before Dec 4 pitch practice | Full rehearsal with a backup plan if Wi-Fi fails. | | Dec 9 | One guided loop. Platform only if we have time and we label it as vision. | ### Already decided by engineering unless founders object - Prove the loop in the **Course** teacher dashboard. - Use **Supabase** as the shared database for the proof. - Host the pages as a **static site** (GitHub Pages or Vercel). No new AWS API is required for December. - Leave the middle-school game alone. - Leave AI off the critical path. ### Still needs a founder decision on Tuesday 1. **Which short student scenario** we perform. 2. **Demo format:** we drive it from our laptop, or guests can also open a link. 3. **How demo users sign in:** pre-made demo logins (more reliable on stage) or class code plus nickname (lighter, easier to mix up). 4. **Whether the Platform appears at all** in the five minutes, or we stay entirely inside the Course. 5. **Comfort with Supabase** for demo data (fictional students only). A move to AWS is possible later and would cost calendar time now. --- ## 11. Risks to say out loud | Risk | What it means | How we handle it for the demo | | --------------------------------------------------- | ------------------------------------------ | ----------------------------------------------------------------------------- | | The pages are one large file each | Harder to maintain, fine to demo | We change as little UI as possible | | Shared saving does not exist outside Claude yet | This is the main build | Database spike is already underway | | Open security rules in the local experiment | Fine on a laptop, not fine on the internet | Hosted version gets real access rules before any public URL | | Demo could be mistaken for a finished school system | Trust risk with educators | We say “proof of concept” every time | | Student privacy (COPPA and school rules) | Real classrooms need a fuller design | Architecture note now. Real students later. Nicknames and demo accounts only. | | Wi-Fi or a cloud blip on stage | Demo fails live | Rehearse. Keep a local backup. Pre-seed the class. | | Scope creep into Platform, AI, and district tools | We miss the one loop | Those items are explicitly after the loop works | | Thirty days is short | We will not finish the whole vision | We finish one believable loop | --- ## 12. Glossary (for a non-technical read) | Term | Meaning here | | ---------------------- | ---------------------------------------------------------------------------------------------------------------------------------- | | **Course** | The student lesson app plus the teacher dashboard already built | | **Platform** | The separate educator website (studio, rooms, district). Vision, not the proof | | **Attempt** | One saved answer: who, which question, right or wrong, when | | **Reteach signal** | A class-level clue that a concept needs another explanation | | **Supabase** | The hosted database we recommend. The website reads and writes it directly | | **Row-level security** | Database rules so a teacher sees their class and a student does not see everyone else’s work | | **Static hosting** | Putting the web page on the internet (GitHub or Vercel) without building our own server | | **API server** | A middle layer we are _not_ building for this proof. It would validate actions before they touch the database. We can add it later | | **Claude artifact** | The original way these pages were hosted, with login and saving that only work inside Claude | | **Sample data** | Fake students used to show the layout. We turn this off when a real class is connected | | **Proof of concept** | A narrow working slice to learn and to show. Not the full product and not compliance-ready | --- ## 13. Questions this brief is meant to help a design review answer 1. Is the reteach story clear enough for a teacher who has never seen the product? 2. Does the five-minute script prove both student engagement and teacher value? 3. Is anything in the current teacher dashboard distracting from “what should I reteach”? 4. What should the empty state say before any student has joined? 5. Which one misconception makes the best on-stage “aha”? 6. What must be labeled “sample” or “coming later” if it appears on screen? 7. What would make a district buyer trust this demo, and what would make them discount it? --- ## 14. Bottom line **Goal by December 9:** one grades 9–12 student scenario, answers saved in a real database, teacher sees what the class missed and what to reteach. **How:** keep the Course screens, add Supabase, host the page normally. **Not the goal:** a finished platform, AI, district analytics, the middle-school game, or a production privacy program. **Already in motion:** local database and a first wiring of student answers into the teacher view, on branch `init-db-migration`. The remaining calendar is for making that loop reliable on a shared URL, choosing the scenario, and rehearsing it honestly.