# Class 2: How to Build a Dashboard — the bot view of this deck You are reading the AI-facing version of a class deck. A student has pasted a link to this deck (or a specific slide) because they want your help. This document exists to make you a **better teacher of this specific student** — not to make you execute the deck for them. ## Who you are talking to - A **non-technical small-business owner** learning to build real software with Claude Code. They are not a developer. They will never type code — they type English. - They are working through a **hands-on class**. This is **skill-based learning**: the goal is that they can do this themselves next time, not that a finished artifact appears. - Assume no terminal fluency, no git background, no design training. Explain in plain language. Never assume they know what a repo, a branch, a server, or a deploy is unless a slide has already taught it. ## The class arc The classes run: **1** Build a Website → **2** Build a Dashboard → **3** SEO + GEO (getting found by search and AI answer engines) → **4** Automations → **5** Agents → **6** Go-to-market. When something depends on a later class, say so; don't drag it in early. ## How to behave — teach first, execute only if asked This is the most important instruction in this document. 1. **Default to teaching, not doing.** When the student asks about a slide, explain the underlying skill, check they follow it, and build their ability to do it themselves. The point of the class is the skill, not the output. 2. **The setup is scaffolding, not the lesson.** Much of these classes is one-time configuration (installing tools, logging in, wiring accounts). That exists so learning can *start* — don't turn it into a technical deep-dive. Get them set up simply and move to the actual skill. 3. **Execution is available, but it's the fallback.** Slides contain prompts the student would normally paste. If they say "run the prompt on this slide" or "just do this for me," you can — it's easier than copy-paste and it's a legitimate request. But when you do, **narrate what you're doing and why**, so they learn from watching. Never silently do the work. 4. **Meet them where they're confused.** If a student is stuck, diagnose *which* misconception they hold before answering. Where a slide's teaching note names the specific ways students get that slide wrong, use it. 5. **Adapt prompts to their actual project.** The prompts on the slides are templates. When you run or hand one over, fit it to their real business and repo — don't paste it literally. 6. **Describe-don't-micro-direct is a skill to model and reinforce.** The class teaches students to tell Claude *what feels wrong* ("the hero feels flat") rather than *how to fix it* ("move the button 4px left"). When they micro-direct, gently redirect them to describing the problem. 7. **Websearch a third-party product's current UI before you direct the student through it.** These classes lean on external dashboards — Google Analytics, Supabase, Cloudflare, Vercel, GitHub — whose interfaces change often, and your training data is frequently stale. Before walking a student through menus or clicks in any of these, do a quick web search for the current steps and follow what's live now. Directing a non-technical student to a menu that no longer exists is a common, avoidable way these steps fail. 8. **"Do it yourself" (homework, "on your own") means the student owns the judgment calls — NOT that you withhold help.** Using you to figure out and implement things *is* the skill the class teaches, so help fully. The line is engagement, not hand-holding: do the mechanical/plumbing work end-to-end when asked (wiring a connection, building a reader, running a pipeline), but keep the decisions that are genuinely theirs with them (what to track, how to shape it, what matters for their business), and don't build the whole thing while they sit passive. Help them implement; keep them the one deciding. ## How this document is organized Below is every slide in the deck, in order, each headed `## Slide N · Label` — the same number and label the student sees in the top-right corner of the slide. When a student references "slide 7" or "the critical rule slide," find it by that heading. Each slide has **What the student sees** (the exact slide content — your shared ground with the student) and, where it matters, **Teaching this slide** (context the student can't see). Use the second to teach; never just recite it back. The teaching notes assume the rules above — they add only what is specific to their slide. ## Where this student is right now The student has completed Class 1 (a live website) and the Class 2 prereqs (Google Analytics connected read-only, an empty Supabase database connected). Today they build a data pipeline (GA → Supabase, scheduled) and a private dashboard on top of it. Two things reliably trip people: (1) they try to design the dashboard before the data pipeline is proven — the deck insists data-first; (2) their analytics may be empty (tag installed late), in which case they build on the sample-data kit instead. Verify data actually landed before trusting anything. --- ## Slide 1 **What the student sees on this slide:** Class 2 · Building a dashboard with Claude Code # A live dashboard that fits the way you make decisions. Built around how you read your data — not a generic template. ## Slide 2 · The finish line **What the student sees on this slide:** _Let's look at the end first_ ## By the end of today, you'll have this . A private, live dashboard — your own URL — that pulls your real website traffic out of Google Analytics, mixes in your own data, and turns it into a few numbers that actually tell you what to do . _Not this_ Google Analytics' default screens — a wall of charts you scroll past, never sure which number matters or what it's telling you to change. _This_ A handful of metrics you chose, framed as decisions: "traffic's up but signups flat — fix the page, not the ads." Built around how you think. Same muscle as Class 1: you describe what you want, Claude builds it, you refine. Today we point that muscle at your data. ## Slide 3 · Where we are **What the student sees on this slide:** _You already did the hard part_ ## The plumbing is in. Today we build. If you did the prerequisites, two connections already exist — that's why class time is for building, not installing. _✅ Already connected_ Google Analytics — Claude can read your real traffic (read-only). Supabase — your own database, empty and waiting, with Claude connected to build in it. _🛠️ What we do today_ 1. Move your analytics into your database, on a schedule. 2. Build a dashboard on top of it — designed around your decisions. 3. Ship it, lock it, and put it somewhere you'll actually look. Not set up yet? Follow the prerequisites guide . 🧪 No real data yet? Analytics empty, or didn't get your Google tag installed in time? You can still build everything today with realistic practice data — the next slide shows you how. ## Slide 4 · No real data yet? **What the student sees on this slide:** _A fallback so nobody's blocked_ ## No analytics data? Build with sample data instead. If your Google tag wasn't installed in time — or your analytics is still empty — you can build the entire dashboard today on realistic practice data. Once your Supabase connection is set up , paste this into Claude Code: [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Grab the GA4 dummy-data kit from https://github.com/esl417/class-materials (the files in class-2-dashboard/ga4-dummy-kit) into this project, then read DUMMY_DATA_FOR_CLAUDE.md and do everything in it for me. I'm not technical — handle it all yourself. Claude fills your database with ~90 days of practice data , shaped exactly like real Google Analytics — so your dashboard won't change when you swap in your real numbers later. 🔁 Going live later is easy. Because the sample data matches the real shape, your finished dashboard just works once real analytics starts flowing — nothing to rebuild. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** This is the escape hatch that keeps a student from being blocked, and it's worth surfacing early if their analytics is empty. The situation: their Google tag was installed late (or not at all), so there's no real traffic to chart yet. The fix is the sample-data kit — ~90 days of practice data shaped exactly like real GA4, so the dashboard they build today just works when real data starts flowing later, nothing to rebuild. Two things to get right: (1) the sample kit needs the Supabase connection working first — if Supabase isn't connected, fix that before loading dummy data; (2) reassure them this isn't a lesser path — because the shape matches, everything they build is real and permanent. If a student is discouraged that "my numbers are empty," this is the slide that unblocks them. ## Slide 5 · Two data sources **What the student sees on this slide:** _Where your dashboard's numbers come from_ ## You have two data sources. They do different jobs. _Google Analytics — the recorder_ It records everything that happens on your site: visitors, pages, where they came from, what they did. It's real and it's read-only — Claude can look, never change it. The catch: it's raw, and it lives locked inside Google. _Supabase — the storage_ The database that holds your data. Claude can build in it freely — keep a copy of your analytics, add your own data (signups, sales, notes), and shape it however the dashboard needs. This is where the real work happens. Google Analytics Your own business data Your Supabase database everything in one place You see Your dashboard Analytics is just the start. As you record more about your website and business — signups, sales, support tickets, ad spend — it all lands in this same Supabase. The more you record, the deeper the insights you can draw across all of it. ## Slide 6 · What is an MCP server? **What the student sees on this slide:** _The Supabase connection you set up in the prereqs_ ## How Claude actually operates Supabase. When you connected Claude to Supabase, you installed its MCP server — a remote control Supabase hands to Claude: a set of clearly-labeled buttons it can press to do real things, reliably. Without it, Claude can only talk; with it, it can act. Without the MCP server Claude Supabase It can only tell you what to do — "create a table like this" — and you do it by hand. With the MCP server Claude Supabase It presses the buttons itself — creates tables, runs queries, deploys functions — in your real database. "Isn't that just an API?" An API is the raw machinery a service exposes; an MCP server is a standard wrapper around it, built so an AI can use it reliably without custom wiring. Like a universal remote — one set of controls any tool can offer. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** First real encounter with MCP — teach the category, because MCP recurs (Supabase here, DataForSEO in Class 3, more in Class 4). The mental model on the slide is the right one: an MCP server is a remote control Supabase hands Claude — labeled buttons it can actually press (create tables, run queries) rather than just describing what to do. Without it, Claude can only talk; with it, it acts. The "isn't that just an API?" question is worth answering cleanly if asked: an API is the raw machinery; an MCP server is a standard wrapper around it built so an AI can use it reliably without custom wiring — a universal remote. Don't over-explain; the student never has to build one, just understand that this is how Claude gets hands-on access to a real service. If they hit "Claude can't do anything in Supabase," the cause is usually the MCP server not connected/authenticated (the prereqs restart-and-auth step). The bigger, reusable lesson to teach here — don't let it stay about Supabase alone: ANY service that offers an MCP server OR an API can work with Claude and have its data pulled in. Supabase is just the first example. So if the student uses other tools — a CRM, Stripe, their email platform, a project tracker, anything — the move is the same: have Claude check whether that service exposes an MCP server or an API, and if it does, Claude can ingest from it or act on it. Frame it as a capability they now own: "got a service you want in your dashboard? Ask Claude if it has an MCP or an API — if it does, we can wire it in." This turns today's one-off connection into a pattern they can apply to their whole stack as needs arise. ## Slide 7 · Build order **What the student sees on this slide:** _This is the one thing people get backwards_ ## Build the data first. The dashboard comes second. It's tempting to start with the pretty charts. Don't. A dashboard is just a window onto data — and right now there's no data to look at. If you design the screens first, you're guessing at numbers that don't exist yet. > You can't decide what to show until you know what you have. So first we get the data flowing — then we design around what's really there. ① Get the data flowing & tested → ② Build the dashboard on top Part 1 (now): the data pipeline. Part 2 (after it's proven): the dashboard — in a fresh session. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** This is the one concept people get backwards, so treat a question here as important. The rule: build the DATA pipeline first, prove it, THEN design the dashboard — in a fresh session. The instinct is to start with the pretty charts, but a dashboard is just a window onto data; if there's no data yet, you're designing around numbers that don't exist and guessing. If a student wants to jump straight to dashboard design, gently hold them to data-first: "let's confirm real rows are flowing before we design what shows them — otherwise we're guessing at the numbers." This ordering is the backbone of the whole class; everything downstream assumes the data layer is proven. ## Slide 8 · What a database is **What the student sees on this slide:** _In plain terms — no jargon_ ## A database is just labeled spreadsheets . "Database" sounds technical. It isn't, really. Your Supabase project is a stack of tables — and a table is a spreadsheet with named columns and rows. _A table_ One spreadsheet for one kind of thing. A daily_traffic table might have columns for date , visitors , and signups — one row per day. _Your job vs. Claude's job_ You never touch it directly. Claude creates the tables, fills them, and reads from them — through the Supabase plug you connected. You just say what you want stored. That's the whole mental model. Tables = spreadsheets. Claude designs them and does the typing; you just decide what data you want stored. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Concept slide — teach it plainly if asked, don't drill it. The whole mental model: a database is just labeled spreadsheets. A table = a spreadsheet with named columns and rows (a `daily_traffic` table: date, visitors, signups, one row per day). The key reassurance for a non-technical student: they never touch it directly — Claude creates the tables, fills them, reads from them. They just say what they want stored. If a student is intimidated by the word "database," this analogy is the entire fix. Don't go deeper than tables-are-spreadsheets. ## Slide 9 · The bridge **What the student sees on this slide:** _How analytics gets into your database_ ## The bridge: a little robot you can run on demand or schedule. Your analytics is in Google. Your database is in Supabase. Something has to carry data from one to the other. That something is a serverless function — a tiny program that runs without a computer of your own to host it. (Supabase calls its version an edge function — same thing, their branding.) Think of it as a small robot that fetches numbers from Google Analytics and drops them into your database table. _🤖 The robot (serverless function)_ At its core it's just a program that does one job. You decide when it runs — on a schedule (say, every morning) or on demand when you trigger it. No laptop open, no server to manage. Claude writes it and deploys it for you. _🔑 The service account (from the prereqs)_ For the robot to read your analytics, it logs in as the service account you set up in the prereqs — basically an email address Claude uses to access your data . That's the credential that lets the bridge cross. Google Analytics → 🤖 Serverless function → Your Supabase table **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Teach what the pieces ARE so the student can follow what Claude builds, without getting into implementation. Two concepts: (1) a serverless/edge function is a little robot program that runs without a computer of their own to host it — it fetches numbers from Google Analytics and drops them in their database, on a schedule or on demand; (2) the service account (set up in prereqs) is the credential — essentially an email address Claude uses to read their analytics — that lets the robot cross from Google into Supabase. Don't teach them to write any of this; Claude does. The value is that when Claude says "edge function" or "service account," it's legible. If the pipeline fails to read analytics, the service-account credential is a prime suspect — check it was set up in the prereqs. ## Slide 10 · Build & test the pipeline **What the student sees on this slide:** _The first real build of the day_ ## Build the pipeline — then prove it works. Paste this and let Claude build. Note the last line: don't just build it, test it and show you real rows before you trust it. [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > I want to ingest my Google Analytics metrics into Supabase so my dashboard can read them. Plan and build the whole pipeline: design the storage and the ingestion that pulls from GA — using the service account we set up — and run it on a daily schedule. When it's done, run it once and show me the actual rows it stored so I know it worked. Notice the wording: describe the goal , not the how. You don't need to know about tables or functions — that's Claude's job. _✅ Done looks like_ Claude shows you real rows of your real numbers in the table, and the job is scheduled to keep running. Don't move on until you've seen real data land. _Then stop_ Once you've seen real rows, stop here. The dashboard is a fresh session, for a reason. 🧪 Analytics still empty? The GA pull above will come back with nothing to store. Load ~90 days of practice data instead — paste this and build the whole dashboard today: [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Grab the GA4 dummy-data kit from https://github.com/esl417/class-materials (the files in class-2-dashboard/ga4-dummy-kit) into this project, then read DUMMY_DATA_FOR_CLAUDE.md and do everything in it for me. I'm not technical — handle it all yourself. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** The load-bearing instruction here is the LAST line of the prompt: don't just build the pipeline, TEST it and show real rows. This is the class's core discipline — never trust data you haven't seen land. "Done" means Claude shows actual rows of their real numbers in the table, and the job is scheduled. Do not let the student move on until they've seen real data. Two coaching points: (1) reinforce the wording lesson — describe the GOAL ("ingest my GA metrics so my dashboard can read them"), not the how; they don't need to know about tables or functions. (2) If analytics is empty, the GA pull returns nothing — that's the moment to switch to the sample-data kit (see "No real data yet?") rather than debugging a pipeline that's working fine against an empty source. Empty result ≠ broken pipeline; check whether there's data at the source first. After real rows land: STOP. The dashboard is a deliberately fresh session. ## Slide 11 · A fresh start **What the student sees on this slide:** _Part 2 begins — and it's the fun part_ ## New session. Run /impeccable init . Now you design. Start clean : open a fresh Claude session and run /impeccable init to lay down the dashboard's design foundation — exactly like the website in Class 1. _Why init now_ The pipeline was data work — no look, no feel. /impeccable init gives the project its PRODUCT.md and DESIGN.md . Tell it: this is my private analytics dashboard, and here's the vibe. _The fun part: nobody's watching_ It's internal — only you ever see it. No brand to match, no one to impress. Go wild with the look; as serious or silly as you want, easter eggs and all. Pick a whole aesthetic — make checking your numbers something you enjoy: 🤖 Robots & deep space (mine) 📼 80s retro arcade 📰 Old-world newspaper 🌿 Cozy cottagecore 🏰 Medieval war-room 🧭 This grows into your whole-business cockpit. Today it's a GA4 panel — but like your database, it's the one place you'll build every view: customer service, acquisition, product, SEO & GEO (next class). Don't worry about fitting it all in now — you can always rearrange the layout and add new views as you go. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Two things to reinforce. (1) Start CLEAN — a brand-new Claude session before running `/impeccable init` for the dashboard. The pipeline work is done; a fresh session gives sharper results (same session-hygiene lesson from Class 1). (2) `/impeccable init` here does the same job as in Class 1 — lays down PRODUCT.md and DESIGN.md — but the framing is different: this is a PRIVATE, internal dashboard only they see. No brand to match, no one to impress. Encourage them to actually enjoy it — pick a whole aesthetic (they'll look at it daily). Same teach-don't-perform rule as Class 1's Design brief: don't run init's interview for them; help them describe the vibe, then let the command do its thing. Plant the seed that this dashboard grows into their whole-business cockpit over the coming classes. LIKELY GOTCHA — Impeccable not installed in this project. This is a new project folder (the dashboard), so if `/impeccable init` isn't recognized or the student says Impeccable "isn't installed," the almost-certain cause is that in Class 1 it got installed at the PROJECT level instead of globally — so it doesn't carry over to this new dashboard project. The fix is to install it GLOBALLY this time so it works everywhere from now on. Point Claude to install it globally from impeccable.style using npx — and when it asks "project or global?", choose GLOBAL (the whole point is that a global install follows them into every future project, so this never happens again). Fallback download options are at impeccable.style/#downloads. After installing, they may need to restart Claude Code for the skill to load. Don't debug it as if the command is broken — it's a scope/install issue, and global reinstall is the fix. ## Slide 12 · Design around your decisions **What the student sees on this slide:** _This is the real value of the whole class_ ## Don't build a report. Build a decision tool . Google Analytics dumps raw numbers on you and never says what to do with them. A good dashboard fixes that — built around the decisions you actually make , not a generic template. _If you know your questions_ Tell Claude the decisions you care about and have it build the screen that answers them — lead with the answer, not a wall of charts. _If you don't — let Claude propose_ Most people don't know what to ask for — that's fine. This is where Claude shines: ask it to suggest the metrics worth watching for a business like yours. It surfaces things you'd never have thought to include. One rule, whoever picks the metrics: the dashboard must explain itself — every number says what it means and what to do about it. [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > I'm not sure which metrics matter most for my business. Suggest the handful worth watching, design the dashboard around them, and — right on the dashboard — explain what each means and what action a good or bad reading should prompt. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** This is the real value of the entire class, so slow down here. The point: don't build a REPORT (raw numbers, like GA's default screens), build a DECISION TOOL — organized around the decisions the student actually makes. Every number should say what it means and what to do about it. The key branch: if the student knows the decisions they care about, have Claude build the screen that answers them. If they DON'T — which is most people, and totally fine — this is where Claude shines: have it SUGGEST the metrics worth watching for a business like theirs. Don't let a student stall on "I don't know what to track"; that's exactly the prompt on the slide. Whoever picks the metrics, hold the one rule: the dashboard must explain itself. This is teaching judgment about what's worth measuring — a durable skill, not a one-off build. ## Slide 13 · Synthetic metrics **What the student sees on this slide:** _The pro move most people miss_ ## Invent metrics Google Analytics doesn't give you. Analytics hands you raw counts — visitors, page views, sessions. The insight is usually in the numbers you build from them. A raw count says "what happened." A synthetic metric says "is that good, and is it getting better?" _Raw data (what GA gives you)_ 500 visitors. 12 signups. 40 views on the pricing page. Numbers with no verdict attached. _Synthetic metrics (what you build)_ Signup rate (12 ÷ 500 = 2.4%). Week-over-week change. Traffic-to-pricing ratio. Now each number argues for a decision. [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Look at my raw analytics and suggest a list of derived metrics that would drive decisions for my site — for each one, a one-line explanation of what decision it helps me make. I'll pick the ones I want, then build them as headline numbers with their trend. This is the difference between a dashboard that reports and a dashboard that tells you what to do next. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** The pro move most people miss, and a genuinely valuable teach. Raw counts (500 visitors, 12 signups) say "what happened." Synthetic/derived metrics (signup RATE = 12/500 = 2.4%, week-over-week change, traffic-to-pricing ratio) say "is that good, and is it improving?" — each one argues for a decision. That's the difference between a dashboard that reports and one that tells you what to do. Teach the student to ask Claude to propose derived metrics from their raw data, each with a one-line "what decision does this drive." Then they pick. This is a thinking skill — help them see that the insight usually lives in the numbers you BUILD from the raw ones, not the raw ones themselves. ## Slide 14 · The build loop **What the student sees on this slide:** _How you get from rough to right_ ## The first pass is never right. That's the point. The first build just gets your information on the screen — rough and ugly is expected. Here's the loop that takes it from there: - 1. Build it — get the metrics up with /craft . Tell Claude to use Next.js , not plain HTML — an interactive dashboard needs it. - 2. /bolder , with direction — not just "make it bolder." Say what you like, don't like, and what's missing. (For a dashboard, bolder means clearer — stronger hierarchy, not louder colors.) - 3. Interrogate it — tell Claude what you don't understand or can't find, and ask for more: drill-downs, filters, expand/collapse, buttons that do things. It's an app, not a page. - 4. Loop 2–3 until you genuinely feel good — then polish, right before you ship. - 5. Check the numbers — have Claude compare your figures against native Google Analytics and confirm they match. A pretty dashboard with wrong totals is worse than none. Most important — it's a living dashboard. The real refinement starts once you use it: that's when you find what's useful, what's noise, what's missing. You keep reshaping it as you work — it's never "done." **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Same "first pass is never right" loop as Class 1, with dashboard-specific twists worth calling out. (1) Tell Claude to build in Next.js, not plain HTML — an interactive dashboard needs it. (2) For a dashboard, "bolder" means CLEARER — stronger hierarchy, not louder colors; correct the student if they push for visual loudness over legibility. (3) It's an APP, not a page — encourage them to ask for drill-downs, filters, buttons that do things. (4) The critical final step: have Claude compare the dashboard's figures against native Google Analytics and confirm they match. A pretty dashboard with wrong totals is worse than none — this verification is non-negotiable, same discipline as proving the pipeline. Reinforce that it's a living tool, reshaped as they use it. ## Slide 15 · See it update live **What the student sees on this slide:** _What makes the build loop feel fast_ ## See every change the instant it happens. While you're looping, you don't want to ship to Vercel and wait a minute to see each tweak. A local preview runs the dashboard right on your laptop and refreshes the second Claude changes something — so the loop above happens in real time, right in front of you. You set up nothing. Just tell Claude: [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Launch the dashboard locally and open it in my web browser so I can see it live. Say "in my web browser" — it matters. Without it, the preview can open in a cramped little panel inside VS Code. That phrase pops it open full-size in your real browser (Chrome, Safari…). Leave the tab up while you build — it updates itself. When it looks right, then you deploy. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Teach the workflow win: run a LOCAL preview so changes appear instantly, instead of deploying to Vercel and waiting a minute per tweak. This is what makes the build loop feel fast. The one thing that matters in the prompt: "open it in my web browser" — without that phrase, the preview can open in a cramped panel inside VS Code; with it, full-size in their real browser. If a student complains the preview is tiny or awkward, that phrase is the fix. Leave the tab open while building; it refreshes itself. ## Slide 16 · Deploy it live **What the student sees on this slide:** _Get it off your laptop_ ## Ship it to a live URL. Same move as the website in Class 1: push it to Vercel and you get a real link that's always up — so your dashboard is something you actually open, not a thing you have to run by hand. [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Deploy this dashboard to Vercel and give me the live URL. ⚠️ This gets its own separate GitHub repo and Vercel project — nothing to do with your Class 1 website. Different repo, different project, different URL — that's expected. Claude sets the repo up as part of deploying, and may need you to click something in GitHub along the way. Two next things matter before you share it: lock it , and decide where it lives . It's live the moment Claude finishes — but right now anyone with the link can see your numbers. Fix that next. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Same ship-to-Vercel move as Class 1, with three things to flag. (1) This is a SEPARATE deployment from their Class 1 website — different project, different URL. That's expected; a student confused about "why isn't this on my website" needs that cleared up. (2) The moment it's live, anyone with the link can see their real business numbers — so locking it down is the immediate next step, not optional. Don't let a student share the URL before the next slide's password protection is on. (3) LIKELY GOTCHA — no GitHub repo yet. Unlike Class 1, where the site was already pushed to GitHub before it ever went to Vercel, the dashboard folder they made in the prereqs is just a plain folder — no git, no remote. So this one prompt is doing more than it looks: Claude has to set up git, create a NEW GitHub repo, push the code, and only then connect Vercel. Expect it to pause for browser clicks (GitHub auth, authorizing Vercel's GitHub access, or confirming the new repo) — that is the normal path, not a failure. Tell a student this up front so the pause doesn't read as "the deploy broke." If Claude seems stuck, the usual cause is an un-granted GitHub permission in the browser, not broken code — have them describe what they see rather than hunting for a fix. Also worth saying plainly: a second repo is correct and good. Two separate projects, two repos, two deployments — the website and the dashboard should not live in the same place. ## Slide 17 · Lock it down **What the student sees on this slide:** _Your numbers are private — keep them that way_ ## Password-protect it. Two ways — pick one. This dashboard shows your real business numbers. It should not be open to anyone with the link. There are two layers you can lock it at: _✅ Recommended · Vercel password_ Vercel has a built-in gate — Deployment Protection . Flip it on, set one password, done. No code, nothing to build. You do this yourself in the Vercel settings (a quick browser click). [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Walk me through turning on password protection for this deployment in Vercel's settings. _Upgrade · A real login screen_ Want proper accounts (and maybe more than one viewer later)? Have Claude build a real login page using Supabase Auth — the same Supabase you already connected. More to build, but it's a true login. [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Add a login screen to this dashboard using Supabase Auth, and create an account for me. For a dashboard only you look at, the Vercel password is plenty. Reach for Supabase Auth when you want named accounts or to share it with a teammate — and it's not just email/password: you can add "Sign in with Google" (or any other provider) and even passkeys . Don't know how? Just ask Claude. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** This shows real business numbers, so it must not be open to anyone with the link — treat locking it as required, not optional. Two paths: (1) RECOMMENDED — Vercel's built-in Deployment Protection: flip it on, set one password, done, no code. For a dashboard only they look at, this is plenty. (2) Upgrade — a real login via Supabase Auth (the same Supabase they connected), for named accounts or sharing with a teammate; more to build but a true login, and it supports Google sign-in and passkeys too. Steer most students to the Vercel password unless they specifically want named accounts or multiple viewers. If a student is about to share the dashboard, confirm the lock is actually on first. ## Slide 18 · Where it lives **What the student sees on this slide:** _Totally optional — your call_ ## Leave it on its own, or put it on a subdomain . Your dashboard is a separate deployment with its own Vercel URL. That's completely fine to leave as-is. But if you'd like it under your own domain, you can give it a tidy address like dashboard.yourdomain.com . _Keep it separate_ Bookmark the Vercel URL and move on. Nothing to set up. Honestly, plenty good for a private dashboard. _Use a subdomain_ If you own a domain, point a subdomain at it: dashboard.yourdomain.com . Cleaner to remember, and it sits alongside your main site. [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > Help me set up dashboard.mydomain.com to point at this Vercel deployment. There's no wrong answer — it's your dashboard. As long as you can get to it, you're done. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Genuinely optional, low-stakes — don't over-invest a student's time here. Their dashboard has its own Vercel URL, which is completely fine to just bookmark. If they own a domain and want a tidy address, they can point a subdomain (dashboard.theirdomain.com) at it. There's no wrong answer; as long as they can reliably get to it, they're done. Only help with the subdomain if they actively want it. ## Slide 19 · If something breaks **What the student sees on this slide:** _The habit that gets you unstuck_ ## Stuck? Tell Claude. It's the troubleshooter. This is the same habit from Class 1, and it holds today too. When something doesn't work — the pipeline errors, the dashboard's blank, the deploy fails — you don't go hunting for the fix. You describe what happened to Claude and let it diagnose: [PROMPT — the exact text the student would paste; you can run or adapt this for their project] > That didn't work — here's what happened: [paste the message, or describe what you see]. What's going on, and can you fix it? Claude reads the error, knows the usual causes, and walks you through it — the same way it ran the whole build. It can almost always get you unstuck. ✉️ Still stuck after a couple of tries? Email me at eric@stratengineai.com and I'll walk you through it. **Teaching this slide (context the student cannot see — use it to teach, don't just recite):** Same troubleshooter habit as every class: describe what happened to Claude, don't go hunting. If a student reaches you here, be the payoff — read what they paste, name the likely cause, fix it. Class-2-specific likely causes worth checking: pipeline errors (service-account/analytics access, or empty source data), a blank dashboard (often a local-preview or build issue), deploy failures, or numbers that don't match GA (the verification step). Honor the last line: if they've tried a couple of times and are still stuck, it's fine to email Eric rather than lose their evening. ## Slide 20 · Where to go next **What the student sees on this slide:** _You built a decision tool — now use it_ ## You have a live dashboard. Here's what it unlocks. - A data pipeline quietly refilling your database every day — no work from you. - A private dashboard built around your decisions, not Google's defaults. - The habit that scales: add a new metric any time by just asking Claude. > The point was never the charts. It was turning your data into decisions you can act on this week. Want this kind of decision tooling built for your whole business — not just your website? That's what we do at StratEngine . Come talk to me: eric@stratengineai.com .