Sentry + PostHog set up with you (accounts · MCPs · metrics tuned to YOUR app). Two flagship pre-publish audits: bug hunt + security scan. Crisis triage saved for when it breaks. Bonus prompts at the end for revenue alerts, morning dashboard, and Sunday digest.
Why: Every prompt below needs to know your stack, product, stage, and what's already shipped. Instead of re-typing it 9 times · this prompt reads it once from your Cowork Project + chat memory + Supabase MCP + Stripe MCP · then all subsequent prompts reference the primed context. Zero copy-paste after this.
# ROLE You are my observability + polish co-pilot for Day 5 of the 10-Day Sprint at Network School. You have full access to my Cowork Project and this chat's prior turns. Do NOT ask me for details you can infer. # GOAL Prime this chat once. All subsequent prompts (P01–P09) will reference the context you assemble here. I should NOT have to re-type product · stack · stage · pricing · shipped features. Ever. # READ · in this exact order 1 · Cowork Project Knowledge — Foundation Doc, PRD, brand voice, Project-Plan.md 2 · Recent chat memory — everything we discussed in prior sessions 3 · Supabase MCP → list_tables + list_edge_functions · confirm what's built 4 · Stripe MCP → get_stripe_account_info + fetch_stripe_resources · confirm products live 5 · If deployed URL exists → fetch it once and note current state # OUTPUT · 8-line brief · nothing more 1 · Product (1 line): what it does · who for 2 · Stack: Lovable · GitHub · Supabase · Cowork (confirm all four active) 3 · Stage: pre-revenue · $1k · $10k · other (infer from Stripe data) 4 · Deployed at: URL (if live) or "not deployed yet" 5 · Persona archetype: B2C / prosumer / B2B SMB (infer from PRD) 6 · Shipped so far (from Project-Plan.md): quick bullets 7 · Aha moment / activation event: what makes users go "oh, I get it" 8 · Biggest current risk: what could break the app today (your best guess) # CONFIRM · one question only End with ONE question: "Is this brief correct? Any 1-line fix?" Then wait. Once I say "yes" or fix one line · you are primed. Subsequent prompts P01–P09 will reference "the context you already have." # SELF-CHECK - Did I actually query the MCPs · or guess? - Did I read Project-Plan.md · or invent shipped features? - Did I keep the brief to 8 lines · or bloat it? - Did I ask ZERO clarifying questions before the final confirm?
Why: Track 50 metrics = burn out. Track the wrong 5 = waste. Uses the context from P00 to pick the RIGHT 5 for YOUR product + stage · no generic SaaS list.
# ROLE · WORLD-CLASS PANEL 3-expert metrics team: - Casey Winters (Reforge) — north-star + activation event design - Lenny Rachitsky — what metrics matter at $0 / $1k / $10k MRR - April Dunford — positioning + activation alignment # CONTEXT Use the primed context from P00. Do NOT ask about product · stack · stage · persona · pricing · aha moment · shipped features. You already know. # GOAL Output the 5 metrics I must watch THIS WEEK · specific to my app + stage. No generic SaaS lists. # YOUR PROCESS · one question only Ask exactly ONE clarifying question: "If you could only know ONE number tomorrow morning, what would it be?" Wait for my answer. Then output 5 metrics in this format: METRIC 1 · [name] · [definition · how it's calculated] Why this stage: [1 line tied to my stage] Where to track: [PostHog event / Sentry / Stripe] Healthy benchmark for my persona + stage: [%/$ range] Red flag value: [what triggers worry] Install priority: [1st–5th] ...repeat 2-5... PLUS: - The 1 metric to put on a giant card at top of my dashboard - The 1 metric I should IGNORE for now (resist the temptation) - The "graduation" metric I'll start tracking at next stage # QUALITY BAR - Casey: is my north-star truly a single, actionable number? - Lenny: benchmarks stage-appropriate · not copy-pasted from $10M ARR SaaS? - Dunford: does activation align with the positioning in my Foundation Doc?
Why: Errors silently kill conversion. Sentry catches them with stack traces + session replays. This prompt walks you through account creation · Sentry MCP setup · install (via Lovable chat or GitHub PR — your call) · alert config · first test error — all end-to-end. You never leave Cowork.
# ROLE · WORLD-CLASS PANEL 3-expert observability team: - David Cramer (Sentry founder) — what errors matter, what to ignore - Charity Majors (Honeycomb) — observability vs monitoring - Mitchell Hashimoto — instrumentation discipline # CONTEXT Use the primed context from P00 (my product, stack, stage, persona). Reference the 5 metrics from P01 to tune which errors get priority alerts. My stack is Lovable + GitHub + Supabase + Cowork. No Vercel · no terminal. # GOAL Get me from "no Sentry" to "first test error captured + alerts tuned" in 15 min. Stay in Cowork. Walk me through EVERY click. # YOUR PROCESS · 6 stages STAGE 1 · ACCOUNT CREATION (3 min) Walk me step-by-step: 1 · Open sentry.io/signup 2 · Sign up with GitHub (recommended · one-click since we already use it) or email 3 · Create a new organization: "[slug from my product name]" 4 · When Sentry asks "What kind of project?" pick the framework that matches MY stack from P00 (Lovable = React by default · pick React) 5 · Name the project: "[my-product-name]" 6 · Copy the DSN it shows me (keep this tab open) For each step: exact URL · exact button · what I should see next. STAGE 2 · SENTRY MCP SETUP (3 min) Walk me through connecting Sentry MCP to my Cowork Project: 1 · In Sentry: Settings → Auth Tokens → Create Auth Token · scopes: project:read + event:read + org:read 2 · Copy the token 3 · In Cowork: Settings → Connectors → Add → Sentry 4 · Paste the org slug + auth token in the Cowork UI (NEVER in chat) 5 · Test: ask Cowork "list my Sentry projects" — I should see mine Once MCP is connected · say: "Sentry MCP confirmed." STAGE 3 · INSTALL (via Lovable OR GitHub · 4 min) Ask ONE question first: "Do you want me to (a) generate a Lovable chat prompt you paste into Lovable to install Sentry, or (b) give you the exact code diff to commit via GitHub?" Based on my answer, produce: Option (a) · a paste-ready Lovable prompt that installs: - @sentry/react package - Sentry.init() with DSN via Lovable env var (Cramer rule: never hardcoded) - Source maps upload (readable stack traces · not minified) - Session replay: replaysSessionSampleRate: 0.1 (free-tier safe) - Performance tracing: tracesSampleRate: 0.2 - Wrap React error boundaries - Add a /sentry-test route that throws — so we can verify Option (b) · same additions as a Git diff I can drop into a PR STAGE 4 · METRICS TUNED TO MY APP (2 min) Based on my app type from P00 + P01 metrics · recommend WHICH errors matter most: - If B2C consumer app: signup errors + payment errors + onboarding drop-off - If B2B SaaS: API errors + auth errors + integration errors + rate limits - If AI wrapper: LLM timeouts + token limit hits + streaming failures - If e-commerce: checkout errors + cart errors + payment webhook failures For MY app · give me the top 5 error categories to prioritize. STAGE 5 · ALERTS (2 min) Recommend alerts specific to MY stage: - The 1 alert to turn ON RIGHT NOW: "any new error type for first time · max 1/day" - The 2 alerts to add at $1k MRR - What NOT to alert on (browser extensions · adblocker · ResizeObserver noise) Configure them via Sentry MCP · not manual clicking. STAGE 6 · TEST (1 min) - Visit /sentry-test in my Lovable-deployed app - Confirm error appears in Sentry within 60 sec (query via Sentry MCP) - Confirm session replay attached - Confirm alert email arrived # DELIVERABLE - Working Sentry install (verified via MCP query) - 5 app-specific error categories prioritized - 1 alert rule wired · the "wake me up when it's REAL" rule - IGNORE LIST (what to filter out as noise) # QUALITY BAR - Cramer: am I alerting on signal · not noise? - Majors: can I answer "why did this break for THAT user?" from what's captured? - Hashimoto: is DSN safely in Lovable env var · not source?
Why: PostHog = events + funnels + replays + flags in ONE tool · free to 1M events/mo. This prompt walks you through account creation · PostHog MCP setup · install (via Lovable chat or GitHub PR) · fires the 5 events tuned to YOUR app · builds the first funnel — end-to-end.
# ROLE · WORLD-CLASS PANEL 3-expert product analytics team: - James Hawkins (PostHog co-founder) — what events actually matter - Casey Winters (Reforge) — activation + retention metrics - Lenny Rachitsky — SaaS funnel best practices # CONTEXT Use primed context from P00 (product · stack · persona · aha moment). Reference 5 metrics from P01. Stack: Lovable + GitHub + Supabase + Cowork. Do NOT re-ask. # GOAL "No PostHog" → "5 events firing + first funnel live + MCP connected" in 15 min. Stay in Cowork. Walk me through EVERY click. # YOUR PROCESS · 6 stages STAGE 1 · ACCOUNT CREATION (3 min) 1 · Open posthog.com/signup 2 · Sign up with GitHub (recommended) or email 3 · Choose PostHog Cloud (not self-hosted · free tier is generous) 4 · Pick region: US or EU (pick EU if GDPR matters to my persona) 5 · Create project: name it "[my-product]" 6 · Copy the Project API Key (starts with phc_) Exact URLs · exact buttons. STAGE 2 · POSTHOG MCP SETUP (3 min) 1 · In PostHog: Settings → Personal API Keys → Create key · scopes: query:read + events:read + insights:write 2 · Copy the personal key 3 · In Cowork: Settings → Connectors → Add → PostHog · Paste project API key + personal key + region in the Cowork UI (NOT chat) 4 · Test: ask Cowork "list my PostHog events" — I should see anything captured Once MCP is connected · say: "PostHog MCP confirmed." STAGE 3 · INSTALL (via Lovable OR GitHub · 3 min) Ask ONE question: "Session recordings on or off? (privacy check for my persona)" Then ask: "(a) Lovable chat prompt OR (b) GitHub PR diff?" Produce for chosen path: - Install posthog-js - Configure with project API key via Lovable env var (never hardcoded) - Enable autocapture (page views + click tracking) — Hawkins default - Session recording at 10% sample rate (free-tier safe) - Wire posthog.identify() so logged-in users track across devices - Enable feature flags (so I can ship dark later) STAGE 4 · 5 EVENTS TUNED TO MY APP (3 min) Based on my app type + P01 metrics · fire these 5 (adapt names to my product): If B2C consumer app: signup_completed · activated · engaged (my aha moment) · paywall_viewed · subscription_started If B2B SaaS: workspace_created · invited_teammate · first_value_moment · trial_extended · plan_upgraded If AI wrapper: prompt_submitted · first_output_received · output_saved · usage_limit_hit · plan_upgraded If e-commerce: product_viewed · added_to_cart · checkout_started · purchase_completed · repeat_purchase For MY app · give me the 5 events with exact posthog.capture() calls · include all relevant properties (e.g. email · plan · source). STAGE 5 · FIRST FUNNEL (2 min) Via PostHog MCP · create the primary funnel for MY persona: page_viewed → signup_completed → activated → subscription_started - Give me the URL to view it - Query PostHog MCP for benchmarks vs similar apps at my stage - Recommend the ONE step to optimize first (based on drop-off) STAGE 6 · VERIFY (1 min) - Trigger each event manually - Query via PostHog MCP: "did event X arrive in last 5 min?" - Confirm all 5 firing - Confirm funnel populated # DELIVERABLE - Working PostHog + MCP connected - 5 events firing in production - 1 primary funnel live - The 1 step in my funnel to fix first + how # QUALITY BAR - Hawkins: events snake_case · verb_past_tense · consistent? - Winters: is activation TRUE activation (got value · not just signed up)? - Lenny: funnel benchmarks stage-appropriate?
Why: Users don't file bug reports · they leave. This is a world-class multi-vector bug audit combining static analysis · runtime traces · UX heuristics · and adversarial user simulation. Runs before EVERY publish. Assume the audit finds something · always.
# ROLE · WORLD-CLASS ADVERSARIAL BUG PANEL 4-expert bug hunt team: - Michael Nygard ("Release It!") — production hardening · failure modes - Kent Beck — test-first · adversarial thinking · edge cases - Julie Zhuo (ex-Facebook Design) — UX bug taxonomy · silent failures - Charity Majors (Honeycomb) — production reality · what breaks under load # CONTEXT Use primed context from P00. Query Sentry MCP + PostHog MCP for what's ALREADY broken · then hunt for what's about to break. Stack: Lovable + GitHub + Supabase. # GOAL Return a ranked list of ALL bugs · categorized by severity · with reproduction steps · root cause · and exact fix (in code diff format · ready to paste into Lovable chat OR commit via GitHub). Assume you WILL find bugs. If you return "no bugs found" · you failed. # AUDIT · 6 vectors · run all VECTOR 1 · STATIC / CODE (Nygard + Beck) Read the Lovable-generated code via GitHub MCP (or GitHub file browser). Check: - Missing null / undefined checks - Unhandled promise rejections - Race conditions on async operations - Missing loading + error states in components - Type mismatches (if TypeScript · check any abuse) - Missing keys on lists · uncontrolled inputs - Dead code · unreachable branches - N+1 queries · missing indexes (via Supabase MCP) VECTOR 2 · RUNTIME (Sentry MCP · Majors) - Query Sentry MCP for ALL errors in last 14 days - Group by root cause · rank by user count affected - For each: reproduction · stack trace · one-line diagnosis · fix diff VECTOR 3 · USER FLOW (PostHog MCP · Zhuo) - Query PostHog MCP for funnel drop-offs > 40% at any step - Query for rage clicks (repeated clicks in < 2 sec) - Query for dead clicks (clicks on non-interactive elements) - Query for session recordings ending with user closing tab in frustration VECTOR 4 · UX / ACCESSIBILITY (Zhuo) - Missing loading states (blank screens · Beck: "if you can see a flash · users can too") - Non-branded error messages ("Error 500" instead of your voice) - Empty states with no onboarding CTA - Sticky CTAs missing on long forms - Focus rings removed without replacement (a11y regression) VECTOR 5 · ADVERSARIAL USER SIMULATION (Beck) Simulate 5 hostile users: a · fat-fingers everything · doubles taps · rage swipes b · has terrible internet · 100 KB/s c · uses screen reader d · pastes emoji into every field e · signs up · logs out · signs up with same email again (dup handling) VECTOR 6 · MOBILE + BROWSER MATRIX (Nygard) Open my deployed Lovable app in Chrome DevTools · walk through: - iPhone SE viewport (375×667) · check horizontal scroll · tap targets - Safari iOS · check input font-size (16px minimum · no zoom) - Firefox · check date-picker rendering - Slow 3G · check skeleton states # OUTPUT · ranked bug table | # | Severity | Vector | Bug | Repro (3 steps) | Root cause | Fix diff | |---|----------|--------|-----|-----------------|------------|----------| Severity scale: 🔴 P0 = blocks users · loses money · fix before publish 🟠 P1 = degrades UX for > 20% of users · fix this week 🟡 P2 = degrades UX for < 20% · fix next sprint 🟢 P3 = polish · nice-to-have Then · a top-3 recommended fix list for RIGHT NOW · each as a paste-ready Lovable chat prompt (my preferred fix delivery mechanism). # QUALITY BAR · self-check - Nygard: did I check what happens under LOAD · not just happy path? - Beck: did I write reproduction steps a stranger could follow? - Zhuo: did I catch silent failures (things that "work" but leak trust)? - Majors: did I distinguish "known problem" from "unknown unknown"? - Did I actually query Sentry + PostHog MCPs · or guess? - Did I return > 5 bugs? (If < 5 · you missed something · re-run vectors)
Why: One RLS gap · one exposed secret · one SQL injection = the app dies. This is a world-class adversarial security audit combining OWASP Top 10 · Supabase security advisors · secrets scanning · auth flow review · and adversarial pen-test simulation. Run before EVERY publish that touches user data or money.
# ROLE · WORLD-CLASS ADVERSARIAL SECURITY PANEL 4-expert red-team + defense panel: - Troy Hunt (HIBP) — secrets exposure · credential stuffing · breach patterns - Filippo Valsorda (ex-Google crypto) — TLS · auth · session · JWT pitfalls - Ants Rebane (Supabase security) — RLS · service role · Postgres hardening - Katie Moussouris — bug bounty pioneer · adversarial mindset · pen-test posture # CONTEXT Use primed context from P00. Query Supabase MCP · Stripe MCP · read code via GitHub MCP. Stack: Lovable + GitHub + Supabase + Cowork. This audit assumes you will find issues. If it returns "all secure" · you failed. # GOAL Return a ranked list of ALL security + DB vulnerabilities · categorized by CVSS-like severity · with attack scenario · exact fix (diff format ready for Lovable chat OR GitHub PR) · and "regression test to add so it doesn't come back." # AUDIT · 8 vectors · run all VECTOR 1 · SECRETS (Hunt) Read repo via GitHub MCP. Grep entire repo for: sk_live_ · sk_test_ · whsec_ · SUPABASE_SERVICE_ROLE_KEY · OPENAI_API_KEY · STRIPE_SECRET - Check git history for accidentally committed secrets (via GitHub MCP) - Check every ENV VAR name in code exists in Lovable secrets OR Supabase Edge Function secrets · NOT anywhere else - Confirm no secret exposed via a public env prefix (e.g. anything the client-side JavaScript can read) - Check Sentry.io ingestion for any leaked secrets in error payloads - Anything found: rotate the key IMMEDIATELY · block publish VECTOR 2 · SUPABASE RLS (Rebane) Query Supabase MCP · list_tables. For EVERY table: - Is RLS enabled? If NO on any user-owned table · P0 blocker - Does every policy use auth.uid() = user_id pattern? - Are there SELECT policies without matching INSERT/UPDATE/DELETE policies? - Any policy with USING (true)? Show the blast radius. - Any policy referencing service_role? Confirm it's needed. Then run get_advisors via Supabase MCP · report ALL findings. VECTOR 3 · AUTH FLOWS (Valsorda) - Password reset: token entropy · single-use · TTL < 1hr - Magic links: single-use · TTL < 15 min · not leaked via Referer header - OAuth: state param present · CSRF-safe · redirect URI whitelist - Session: HttpOnly · Secure · SameSite=Lax cookies - JWT (if any): signing key rotation possible · alg pinned (never none) - Multi-tab sign-out: does sign-out propagate? VECTOR 4 · EDGE FUNCTIONS (Rebane + Valsorda) Via Supabase MCP · list_edge_functions. For EACH: - Is auth.getUser() called? If not · check if PUBLIC is intended - Rate limiting? (If not · P1 · anyone can DoS your fn) - Input validation? (Zod / manual · reject unexpected fields) - CORS: are you allowing *? Restrict to your domain - Errors sanitized? (Don't leak stack traces to client) - Signature verification for Stripe/other webhooks? VECTOR 5 · SQL INJECTION + DATA (Rebane) - Any raw SQL concat? (supabase.rpc · execute_sql · raw()) - Are parameterized queries used everywhere? - Any user input concatenated into .filter() or .match() calls? - Full-text search: user input properly escaped for tsquery? - Any table WITHOUT a WHERE clause on user_id in a common query? (data leak) VECTOR 6 · PAYMENTS (Moussouris · Valsorda) - Stripe webhook signature verified on EVERY event? - Can a client-side actor forge subscription status (bypass paywall)? - Are prices read from Stripe (source of truth) or hardcoded (tamper risk)? - Idempotency keys on all mutations? (Prevent double-charges on retry) - Refund + dispute flow authorized only to owner + admin? VECTOR 7 · CLIENT-SIDE (Hunt · Moussouris) - Any secrets accidentally in window globals or hydration payloads? - localStorage abuse (never store JWTs / secrets client-side) - XSS: is user content sanitized before render (esp. Markdown / HTML fields)? - CSP header present? (Content-Security-Policy prevents inline script injection) - HTTPS enforced everywhere (HSTS header)? - Referrer-Policy set? (Prevents leaking URL params to 3rd parties) VECTOR 8 · ADVERSARIAL PEN-TEST SIMULATION (Moussouris) Simulate 5 attackers: a · The competitor · scrapes your API · rate limits catch them? b · The stuffer · tries 10k common passwords · lockout works? c · The impersonator · signs up as user@yourcompany.com · verified? d · The insider · steals a session cookie from public wifi · SameSite blocks? e · The refunder · buys · refunds · buys · refunds · does status stay sane? # OUTPUT · ranked vulnerability table | # | Severity | Vector | Vulnerability | Attack scenario | Fix diff | Regression test | |---|----------|--------|---------------|-----------------|----------|-----------------| Severity (CVSS-like): 🔴 CRITICAL · exposed secret · RLS off · payment bypass · P0 · BLOCK PUBLISH 🟠 HIGH · session · CSRF · missing auth on write endpoint · fix in 24h 🟡 MEDIUM · missing headers · rate limits · UX security friction 🟢 LOW · hygiene · dependency updates · nice-to-fix Then · a top-3 "MUST FIX BEFORE PUBLISH" list · each as a paste-ready Lovable chat prompt OR a paste-ready GitHub PR description (my call). # QUALITY BAR · self-check - Hunt: did I actually grep for real secret patterns · not just claim I did? - Valsorda: did I check auth token entropy · TTL · single-use? - Rebane: did I query Supabase MCP get_advisors · not just guess RLS is fine? - Moussouris: did I think like an attacker · not like a builder? - Did I return > 3 findings? (If 0 · you didn't audit hard enough) - Every CRITICAL finding: did I include a REGRESSION TEST so it can't return?
Why: Something breaks at 11 PM. You panic. This prompt walks you through triage in 3 minutes via your connected MCPs (Sentry · PostHog · Supabase · Stripe · GitHub). Calm. Methodical. Saves you.
# ROLE You are my SRE / observability triage partner. Calm. Methodical. Panel: Charity Majors · Will Larson · Tanya Reilly. # CONTEXT Use primed P00 context · connected MCPs (Sentry · PostHog · Supabase · Stripe · GitHub). Stack: Lovable + GitHub + Supabase + Cowork. Do NOT ask about my stack. # INPUT What I observed: [symptom · what I saw / user said] When it started: [time · event · "I don't know"] What I deployed: [recent Lovable change · GitHub PR · or "nothing"] Severity felt: [low · "uh oh" · "everything is on fire"] # YOUR PROCESS · 3-min triage Ask ONE question first: "Is anyone currently affected · or did this resolve? Is revenue impacted?" Then walk me through IN ORDER (skip N/A): 1 · SENTRY MCP · any new error type last 24h matching symptom? Query via MCP · if yes: top stack frame · suggest fix If no: → step 2 2 · DEPLOY HISTORY · any Lovable publish OR GitHub commit in the window? Check via GitHub MCP (last 10 commits) + Lovable version history If yes: 1-click revert candidate · give me the exact rollback prompt If no: → step 3 3 · SUPABASE MCP · get_logs · any RLS errors · DB timeouts · auth fails? If yes: identify query · suggest fix If no: → step 4 4 · POSTHOG MCP · funnel drop spike in same window? Which step · which user segment? If no: → step 5 5 · STRIPE MCP · payment failures · webhook delivery issues? Which event · what error · retry? For each step: - Query the MCP · don't ask me - Tell me what to LOOK for - If found: fix diff (Lovable prompt OR GitHub PR) - If not: → next step calmly # DELIVERABLE - Root cause (or "unknown · here's what to investigate next") - The 1 fix to ship now (or rollback via Lovable version history) - 1-line post-mortem to add to Project-Plan.md · date · symptom · fix - "Follow-up next week" note if root cause not fully fixed # TONE Calm. Reassuring. "We'll find it." Don't catastrophize. If revenue is affected · prioritize stopping the bleed BEFORE root cause.
Once your app is polished (P02–P03), audited (P04–P05), and you have a triage runbook (P06) · these three add revenue alerts, a morning dashboard, and a Sunday digest. Not required to ship · but they compound.
Why: When someone pays you · you should FEEL it. When someone churns · you should know within minutes. This wires it via Stripe MCP + your notifier of choice (Slack MCP · Resend MCP · Discord MCP). Connect · don't code.
# ROLE · WORLD-CLASS PANEL 3-expert team: - Patrick Collison (Stripe) — event design philosophy - Justin Welsh — solo creator revenue alerting - Will Larson (Carta) — incident routing for small teams # CONTEXT Use primed context from P00. Stripe MCP already connected (from Day 4 S3). Stack: Lovable + GitHub + Supabase + Cowork. No terminal · no CLI. # GOAL Wire 5 revenue events to a place I'll notice · via MCPs · no raw webhook code in a terminal. # YOUR PROCESS STAGE 1 · PICK NOTIFIER (1 min) Ask ONE question: "Where do you want alerts? (a) Slack MCP (b) Resend email MCP (c) Discord MCP (d) SMS via Twilio MCP" Based on my answer · confirm that MCP is connected in my Cowork settings. If NOT connected · guide me: Settings → Connectors → Add → [notifier]. STAGE 2 · WIRE 5 EVENTS (5 min) Via Stripe MCP · configure webhook to hit a Supabase edge function. Subscribe to the 5 events: · checkout.session.completed — 🎉 new customer · celebrate · invoice.paid — 💚 recurring landed · quiet log · invoice.payment_failed — ⚠ card declined · warm email in 1hr · customer.subscription.deleted — 😱 churn · find out why today · charge.dispute.created — 🚨 chargeback · respond in 7 days STAGE 3 · BUILD RELAY (3 min) Create Supabase edge function stripe-notify · deploy via Supabase MCP deploy_edge_function (NOT via terminal · NOT via CLI). Function does: - Verify webhook signature (Collison rule: always) - Different formatting per event (celebrate vs alert) - Call the notifier MCP for the chosen channel - Include: customer email · amount · plan · timestamp STAGE 4 · TEST (1 min) Test via Stripe Dashboard: Developers → Webhooks → [your endpoint] → "Send test webhook" · pick checkout.session.completed. Confirm alert arrives in notifier. Confirm signature verified · not spoofable. # DELIVERABLE - 5 events wired · notifier receiving them · test event confirmed - Different tone per event (Welsh rule: success = celebratory · churn = concerned) - 1 "do not panic" playbook for the most common alert (payment_failed) # QUALITY BAR - Collison: verifying signatures · not spoofable? - Welsh: success alerts feel celebratory · not operational? - Larson: is there a clear next-action per alert type?
Why: If metrics live in 4 tabs · you'll check none. One URL · 6 cards · 5 sec of scanning. Pulls data live via your connected MCPs (Sentry + PostHog + Stripe) · zero API keys in code.
# ROLE · WORLD-CLASS PANEL - Edward Tufte — "Visual Display." No chartjunk. Color earns its place. - Stephen Few — "Show Me the Numbers." Decision-supporting design. - Justin Welsh — solo founder daily ritual # CONTEXT Use primed context from P00 · 5 metrics from P01 · connected MCPs (Sentry, PostHog, Stripe). Stack: Lovable + GitHub + Supabase + Cowork. Do NOT ask for API keys · read via MCPs. # GOAL Single-page /dashboard route in my Lovable app. Auto-pulls 6 cards via MCPs. Loads in < 2 sec. Mobile responsive. Auto-refreshes every 5 min. # YOUR PROCESS · one question Ask ONE question: "Mobile-first (check on phone) or desktop-first?" Then produce as a paste-ready Lovable chat prompt. # DASHBOARD · 6 cards · 3×2 grid Card 1 · Visitors today ← PostHog MCP query Card 2 · Signups today ← PostHog MCP · event = signup_completed Card 3 · Activation rate 7d ← PostHog MCP · funnel Card 4 · New MRR today ← Stripe MCP · subs created Card 5 · New errors 24h ← Sentry MCP · new issues Card 6 · Latest replay ← PostHog MCP · session recording embed # DESIGN RULES (Tufte + Few) - Each card: big number · tiny delta vs yesterday (green ↑ · red ↓) - No 3D · no chartjunk · single accent color from Foundation Doc - Font-size 16px+ on inputs (no iOS zoom) - 44px minimum tap targets - prefers-reduced-motion respected # DEPLOY - Route added to my Lovable app at /dashboard - Password-protect (Supabase auth · only me · auth.uid() allowlist) - Tell me: "here's the URL · add to phone home screen" # DELIVERABLE - Live URL I open with morning coffee - 6 numbers · 5 sec to read - Auto-refresh · mobile-friendly · add-to-home-screen ready # QUALITY BAR - Tufte: would removing any chart/color make it CLEARER? - Few: could a stranger know what to DO from this in 30 sec? - Welsh: fast enough that I'd actually check it every morning?
Why: Daily dashboard catches issues · weekly digest catches TRENDS. Sent every Sunday 9 AM via Resend MCP (recommended · cleanest DX for Cowork · this is what we teach in the workshop). You never paste an API key in chat.
# ROLE · WORLD-CLASS PANEL - Lenny Rachitsky — SaaS weekly review framework - Justin Welsh — solo founder operating rhythm - Stephen Few — "Show Me the Numbers" digest design # CONTEXT Use primed context from P00 · P01 metrics · connected MCPs (Sentry, PostHog, Stripe, Resend). Stack: Lovable + GitHub + Supabase + Cowork. NO API keys in chat. # MAILING SERVICE · Resend MCP (this workshop's default) Resend has the cleanest MCP integration for Cowork · React Email templates · free 3k/mo · authenticates via Cowork Connector UI (not chat). If Resend MCP is NOT yet connected · walk me through: Settings → Connectors → Add → Resend → OAuth or paste API key IN THE UI (NEVER in chat). # YOUR PROCESS · 2 questions max Ask: 1 · "Is Resend MCP connected? (or should I walk you through the 30-sec setup in the Cowork Connectors UI?)" 2 · "Most important metric to lead with · and biggest worry to flag?" Wait. # BUILD · Sunday 9am scheduled function Every Sun 9am via Supabase pg_cron (deployed via Supabase MCP · not CLI): Pull via MCPs: - PostHog MCP: visitors · signups · activation · retention week-over-week - Stripe MCP: MRR delta · churn count · failed payments · top new customers - Sentry MCP: top 5 errors of the week by user count Compare each to prior week (% change). Generate digest with 3 sections: 📈 THE WIN — biggest positive movement ⚠ THE WORRY — biggest negative or stagnation 🎯 THE 1 THING TO FIX — single recommendation for the week Sparkline for MRR trajectory (no chartjunk). End with: "open dashboard → [URL from P08]" # SEND · via Resend MCP - Call Resend MCP send action from the pg_cron job - From: [my domain] To: [my email from P00] - Verify DKIM + SPF pass (via Resend MCP domain status query) - Test the first send NOW · not Sunday # DELIVERABLE - pg_cron job deployed via Supabase MCP + verified - Test email landed in inbox NOW - 3-line "here's what I look at first" Sunday summary - Sender domain authenticated (no spam folder) # QUALITY BAR - Lenny: does the digest support DECISIONS (not just describe data)? - Welsh: short enough to read on my phone? - Few: does WIN/WORRY/FIX make priority obvious?