Day 4 presentation1 / 16

Zero to MVP AI Bootcamp

Private lead dashboard

Give the product durable memory, business login, and access rules that keep every account private.

Today you ship

A database-backed lead dashboard with authentication and a passed two-account privacy test.

Scroll to move through the presentation.

Learning objectives2 / 16

By the end of today

  1. 1Model only the data required by the shared lead journey.
  2. 2Save submissions and AI recommendations in Supabase.
  3. 3Add sign-up, sign-in, sign-out, and protected dashboard access.
  4. 4Enforce ownership in the database instead of hiding records only in the interface.
  5. 5Prove privacy with two separate business accounts.
Run of show3 / 16

Today’s learning path

  1. Module 135 min

    Give the product memory

  2. Module 240 min

    Identity and sessions

  3. Module 345 min

    Database privacy rules

  4. Module 430 min

    The two-account proof

  5. Guided build

    AI Lead Assistant · Stage 4

    Build, test, checkpoint, and ship.

Module 1 · Learn · 35 min4 / 16

Give the product memory

A database gives the product memory after a page refresh or new session. We store only the information needed to review a lead and its recommendation.

A real example

One lead record stores the business owner, answers, recommendation, status, and creation time. It does not need a separate field for every visual detail.

Technical terms

Table
A collection of records representing one kind of thing.
Record
One saved item, such as one lead submission.
Module 1 · Apply it5 / 16

Apply the concept

Turn one completed lead journey into a simple table diagram.

  1. 1List the information created during one complete journey.
  2. 2Group related information into the smallest useful records.
  3. 3Add identifiers, owner, status, and timestamps.
  4. 4Create one example record and explain every field.

Use this prompt

Design the minimum Supabase data model for this lead assistant. Store owner, lead answers, validated recommendation, status, and timestamps. Explain each table and relationship in beginner-friendly language before providing SQL.

Success looks like

You can draw the data model on one page and explain why every stored field is necessary.

Watch for

  • If the model has many tables, start with one lead record and split only when repeated data requires it.
  • If a field does not help the journey, privacy, or operation, remove it.
Module 2 · Learn · 40 min6 / 16

Identity and sessions

Authentication proves who is using the product. Authorization decides which data that person may access. A session lets the product remember the signed-in user between pages.

A real example

A clinic owner signs in and sees the clinic's leads. Signing in does not grant access to another clinic's records.

Technical terms

Authentication
Verifying who a user is.
Authorization
Deciding what an authenticated user may see or change.
Module 2 · Apply it7 / 16

Apply the concept

Map signed-out, signed-in, expired-session, and forbidden journeys.

  1. 1Build sign-up and sign-in using the instructor's Supabase setup.
  2. 2Show clear success, invalid-credential, and verification states.
  3. 3Protect the dashboard from signed-out visitors.
  4. 4Add sign-out and test an expired or missing session.

Use this prompt

Add Supabase authentication to the existing app using its current patterns. Include sign-up, sign-in, sign-out, clear errors, and a protected dashboard redirect. Do not add authorization rules yet.

Success looks like

A user can enter, leave, and return to the private area while signed-out visitors are redirected safely.

Watch for

  • If email verification blocks progress, use the instructor-approved development setting or test account.
  • If the page appears protected only visually, verify the server also checks the session.
Module 3 · Learn · 45 min8 / 16

Database privacy rules

Hiding another user's data in the interface is not enough. Privacy rules must live in the database so unauthorized requests are rejected even if someone bypasses the page.

A real example

Every lead stores its business owner ID. A database rule allows reading or changing that row only when the signed-in user's ID matches.

Technical terms

Row Level Security
Database rules that decide which individual records a user may access.
Owner ID
The identifier connecting a private record to its user.
Module 3 · Apply it9 / 16

Apply the concept

Read one ownership policy aloud as a plain-language rule.

  1. 1Add the authenticated owner ID to each private record.
  2. 2Enable Row Level Security before exposing the table.
  3. 3Add rules for owner-only create, read, update, and delete.
  4. 4Test allowed actions before attempting cross-account access.

Use this prompt

Write Supabase Row Level Security policies for owner-only lead records. Explain each policy in plain English first, use the authenticated user ID, and deny access by default.

Success looks like

The signed-in owner can manage their leads, and the same request fails when made by another account.

Watch for

  • If no records appear, check whether old rows are missing an owner ID.
  • If every account sees every row, stop immediately and verify that security is enabled on the table.
Module 4 · Learn · 30 min10 / 16

The two-account proof

A privacy claim is not evidence. The two-account test proves that separate users cannot read, change, or delete each other's records.

A real example

Account A creates a red lead and Account B creates a blue lead. Each account should see only its own color in list and detail views.

Technical terms

Privacy test
A deliberate attempt to access data that should be forbidden.
Launch blocker
A failure serious enough to prevent release.
Module 4 · Apply it11 / 16

Apply the concept

Attempt four cross-account actions and record the expected denial.

  1. 1Open two separate browser sessions and sign into different accounts.
  2. 2Create visibly different records in each account.
  3. 3Attempt list, direct-link, update, and delete access across accounts.
  4. 4Record the result and fix any leak before continuing.

Use this prompt

Create a two-account privacy test checklist for lead records. Include list, direct detail URL, update, delete, and newly created record behavior. Mark any cross-account access as a launch blocker.

Success looks like

All unauthorized actions return no private data and make no changes, while owner actions continue to work.

Watch for

  • Do not test both accounts in the same browser session; use separate profiles or private windows.
  • If one test leaks data, stop all later work until the database rule is corrected and every test reruns.
Guided project12 / 16

Build brief

AI Lead Assistant · Stage 4

Connect the shared product to Supabase and add a private dashboard for each business account.

User story

As a business owner, I can return to my leads and recommendations while every other account remains private.

Guided build · Part 113 / 16

Build it step by step

1

Create the schema

Build the minimum lead, recommendation, ownership, status, and timestamp fields.

2

Enable protection

Turn on Row Level Security and add policies for authenticated owners.

3

Build authentication

Add sign-up, sign-in, sign-out, validation, and useful errors.

Guided build · Part 214 / 16

Build it step by step

4

Save the journey

Store the submitted answers and validated AI recommendation.

5

Build the dashboard

List, inspect, update, and archive the signed-in owner's leads.

6

Run two-account proof

Create distinct records with Accounts A and B, then attempt cross-account access.

Ship checkpoint15 / 16

Do not ship until

  • A business owner can sign up, sign in, sign out, and recover from common errors.
  • Lead submissions and AI recommendations persist after refresh.
  • Every private record has an owner identifier.
  • Row Level Security protects every exposed user-owned table.
  • The two-account read, update, and delete tests pass.
Wrap and prepare16 / 16

Ship it. Show it. Prepare the next move.

Before the next day

  • Write the email sent to a new lead and the notification sent to the business.
  • Define whether the shared product uses a test deposit or skips payment.
  • Prepare ten AI evaluation cases with expected behavior.
All presentationsOpen Day 5