Users · Money · Logins. Any stack.

# GOAL
Based on the stack you learned from my answers (or from earlier in this chat), produce a personalized architecture brief for adding auth + DB + payments.

# 🌐 RESEARCH FIRST · web-search before answering
Verify each of these against current docs (June 2026):
- The latest auth method for MY builder tool (e.g. "Lovable + Supabase auth June 2026" OR "Replit Auth current best practice" OR "Clerk + Next.js 15" — whatever matches my stack)
- The current DB option that pairs best with my builder tool
- The current payments provider that fits my country + business model + builder tool

Cite the URL of each source you used.

# OUTPUT
Produce this exact structure as a Markdown document:

## My Stack (confirmed)
- Builder: [...]
- DB: [...]
- Auth provider: [recommended, based on research]
- Payments provider: [recommended, with reason for choice]
- Hosting: [where it runs]

## The 3 systems · how they fit together
A simple ASCII diagram showing user → auth → DB → payments → back to app
Plus 1 paragraph explaining the data flow in plain English (no jargon)

## What we'll build tonight (90-min plan)
- 5:30-5:50 · Setup + accounts (20 min)
- 5:50-6:20 · Auth + first login working (30 min)
- 6:20-6:45 · Database schema + secure data (25 min)
- 6:45-7:10 · Payments + first test transaction (25 min)
- 7:10-7:15 · Verify end-to-end (5 min)

## Decisions I've made for you (and why)
For each "default" choice you're recommending, give 1 sentence of why this option vs alternatives. E.g.:
- "I'm recommending Stripe over Lemon Squeezy because you're in the US — if you're in a country where Stripe is hard to set up, switch to Lemon Squeezy or Paddle."

## Cost projection (June 2026)
What this stack costs:
- Today: $0 (free tiers cover us)
- At 100 paying users: $XX/month
- At 1,000 users: $XX/month

## Sources I checked (with URLs)
List every doc URL you read.

# DELIVERABLE
Save as `architecture.md`. We'll reference it in every subsequent prompt tonight.

# SELF-CHECK
(1) Every recommendation is verified against June 2026 docs · not memory
(2) Every URL cited
(3) Plan fits the 90 minutes
(4) Cost projection is realistic at 100 and 1K users

# GOAL
Wire up working email login + signup in my project. By end of this prompt: I can sign up, get a verification email, log in, see my user object, log out.

# BRANCH BY STACK (you know mine from earlier)
Pick the right path for MY stack:

**If Lovable + Supabase:** use the native Supabase Auth integration. Walk me through enabling email/password in Supabase dashboard, then ask Lovable to add the login UI.

**If Lovable WITHOUT Supabase:** recommend Clerk (cleanest no-code auth in 2026) OR Auth0 — and integrate via Lovable's Connect feature.

**If Replit:** use Replit Auth (built-in, zero config) — easiest path. OR Supabase Auth if I want portability.

**If Claude Code / Cursor + Next.js:** Clerk (5-min setup) OR Better Auth (open source, growing fast 2026) OR Auth.js (formerly NextAuth).

**If v0 + Vercel:** Clerk integrates in 2 clicks · OR Supabase Auth · OR Auth.js.

**If Bolt.new:** Supabase Auth (best Bolt integration) OR Clerk.

**If something else:** web-search "[my builder] auth June 2026" and pick the most mainstream option.

# 🌐 RESEARCH BEFORE YOU EXECUTE
For whichever path you picked:
- Search for the current setup guide (must be 2026 fresh — many tutorials from 2024 are now outdated)
- Read the official Quickstart
- Cite the URLs

# THEN EXECUTE — STEP BY STEP
Walk me through it like I've never done this before:
1. Account signup (if needed) — provide direct URLs
2. Where to find the API keys / credentials
3. EXACTLY where to paste them in my builder tool (be specific: which menu, which field)
4. The first code change to make
5. How to test it works (the curl / browser action that proves login is wired)

After each step, ASK me: "Did that work?" Wait for "yes" before continuing.

# GOTCHAS TO CALL OUT
- Email verification in dev mode (often needs disabling for testing)
- Localhost URLs vs production URLs
- Session storage (cookies vs localStorage debate for 2026)
- The "redirect URL" gotcha — wrong URL = silent failure

# DELIVERABLE
At the end:
1. Confirm we can sign up · log in · see user · log out
2. Save what we did as `auth-wired.md` so we can rebuild if needed
3. Tell me what's NOT done yet (e.g. password reset, social login, magic links) — we'll decide what's tonight vs later

# GOAL
Design the minimal database schema for my project + lock it down so each user can only see their own data.

# MY PROJECT
(You know this from earlier. If unclear, ASK me 1 question.)

# BRANCH BY DB
- Supabase / Postgres: generate SQL with RLS policies. Search "Supabase RLS June 2026 best practices" first.
- Firebase / Firestore: generate Firestore security rules.
- Convex: generate Convex schema + access functions.
- Replit DB: generate key namespacing + auth-check helpers.
- Vercel Postgres / Neon: SQL + Drizzle ORM schema + middleware checks.
- Other: web-search current docs.

# 🌐 RESEARCH FIRST
Search for the June 2026 security best practice for my chosen DB. Cite URLs. Don't reuse 2024 tutorials — RLS patterns have evolved.

# OUTPUT FORMAT

## Tables (or collections) I need
List each one with: name · 4-7 columns · what it stores. Keep it MINIMAL.
At minimum tonight: `profiles` (links to auth user). Plus 1-2 product-specific tables.

## The schema (paste-ready)
[The actual SQL / Firestore rules / Convex schema · ready to copy-paste]

## Security policies (paste-ready)
[RLS policies / security rules · per table]

## Where to paste this
EXACTLY where in my builder tool. E.g. "Lovable: Project settings > Connected services > Supabase > SQL Editor > paste."

## Test query (to verify security works)
A curl or SQL snippet I can run to prove: as user A, I see only user A's data.

# GOTCHAS
- The "auth.uid() returns null in service-role context" trap
- The "I forgot to enable RLS on the table" silent-data-leak trap
- The "INSERT doesn't trigger auth check on the row" gotcha

# DELIVERABLE
Save as `schema.sql` (or `firestore-rules.json` / `convex-schema.ts` etc). After applying, test the security with the test query.

# GOAL
Get my FIRST test transaction working end-to-end. By end of this prompt: I can click "Subscribe" or "Buy" in my app, enter a test card, and see the subscription/purchase show up in my DB.

# BRANCH BY PROVIDER (based on my country + business model)

**Stripe (default — US/EU/UK/most countries):**
- Best general purpose · most docs · cheapest fees at scale
- Requires: bank account in supported country, ID verification

**Lemon Squeezy (Merchant of Record · easiest for indies):**
- Handles VAT/sales tax for you (huge win for solo founders selling globally)
- Higher fees than Stripe but no compliance headache
- Best for: digital products, courses, SaaS without complex billing

**Polar.sh (indie SaaS · 2026 rising star):**
- Built for indie devs · clean API · MoR like Lemon Squeezy
- Cheapest MoR option in 2026
- Best for: simple subscriptions

**Paddle:**
- Enterprise MoR · stronger compliance
- Better for B2B SaaS · weaker for digital downloads

**Razorpay (India / Asia):**
- If your bank account is in India

**If unsure:** web-search "best payment provider for [my country] [my business model] June 2026" and recommend.

# 🌐 RESEARCH FIRST
- The current "Quickstart for [provider] + [my builder tool]" docs (June 2026)
- Current fee structure
- Current test card numbers
Cite URLs.

# EXECUTE — STEP BY STEP
1. Sign up for [provider] · provide direct URLs · note "ID verification can take 24-48 hours so use test mode first"
2. Get API keys · EXACTLY where to find them in their dashboard
3. Where to paste them in my builder tool (specific menu paths)
4. Create my first product / price in the provider's dashboard
5. Add the "buy" or "subscribe" button to my app — give me the exact code or builder-tool prompt
6. Test card numbers I can use (4242 4242 4242 4242 for Stripe, etc.)
7. Run the test purchase

After each step: "Did that work?" Wait.

# GOTCHAS
- Test mode vs Live mode (most common mistake: using live keys in test, or vice versa)
- The "redirect after payment" URL gotcha
- Subscription vs one-time price types
- Currency setting (if not USD)
- 3DS / SCA requirements for EU customers

# DELIVERABLE
1. A working test transaction visible in [provider] dashboard
2. Save what you did as `payments-wired.md`
3. Tell me what's still needed before going live (webhooks · production keys · refund flow · etc) — we handle webhooks next in Prompt 06

# GOAL
When a customer pays, my DB needs to know — automatically. This means a webhook endpoint that listens to payment events and updates the user's `subscription_status` or `plan` field.

# BRANCH BY HOSTING + BUILDER
- Lovable + Supabase: use Supabase Edge Functions (Deno · TypeScript)
- Replit: Replit Deployments · custom endpoint
- Claude Code / Cursor + Next.js: API Route or Server Action
- v0 + Vercel: Vercel API Route
- Bolt.new: Cloudflare Workers or Supabase Edge Function
- Other: web-search for current pattern

# 🌐 RESEARCH FIRST
The June 2026 webhook signature verification pattern for MY payment provider. This is security-critical — don't use 2024 tutorials. The official "Verify webhook signatures" docs.

# EXECUTE
1. Create the endpoint URL (where it lives)
2. Add signature verification (paste-ready code)
3. Handle the 2-3 most important events:
   - `checkout.session.completed` (or equivalent) → set user's subscription_status to "active"
   - `customer.subscription.updated` → update plan
   - `customer.subscription.deleted` → set to "canceled"
4. Register the webhook in [provider] dashboard
5. Use [provider]'s webhook test feature to fire a test event and watch the DB update

# GOTCHAS
- Always verify the signature · NEVER trust webhook payloads as authentic
- Idempotency (you may get duplicate webhook fires — handle gracefully)
- Local testing: use ngrok OR the [provider] CLI to forward events locally during dev

# DELIVERABLE
A working webhook that updates the DB when payment events fire. Test it with [provider]'s "send test event" feature before considering it done.

# GOAL
Walk through my app as a brand-new user. Verify every step works.

# THE TEST FLOW
Open an incognito browser. Go to my live URL. Then:

1. Sign up with a test email · email verification (if enabled)
2. Log in
3. Confirm I see ONLY my own data (open another incognito as user B · confirm B doesn't see A's data)
4. Click "subscribe" / "buy" · enter test card · complete checkout
5. Return to app · confirm I see "Premium" / "Paid" status
6. Check the DB · confirm subscription_status = "active"
7. Log out · log back in · confirm Premium status persists
8. Cancel subscription (in [provider] dashboard) · confirm app shows "Free" within a minute

# EXPECT TO FIND 2-3 SMALL BUGS
That's normal. For each:
- What broke
- The smallest fix (don't refactor · just fix)
- Whether it's "fix now" or "fix later"

# DELIVERABLE
- ✅ Each step passing
- A bug list (2-3 items) with fix priority
- A 1-line celebration · we just built a real product

# GOAL
Flip my app from test mode to production. Real users · real payments.

# PRE-FLIGHT CHECKLIST (audit before flipping)
1. ✅ Auth: production redirect URLs added (replace localhost)
2. ✅ DB: RLS policies tested with non-trivial data
3. ✅ Payments: live API keys swapped in (NOT pushed to git in plaintext)
4. ✅ Webhooks: registered against production URL with production signing secret
5. ✅ Email: production sender verified · not going to spam
6. ✅ Error tracking: Sentry or similar wired (10x easier to debug live bugs)
7. ✅ Backups: DB has daily auto-backups
8. ✅ Monitoring: uptime alert (UptimeRobot free tier works)
9. ✅ Privacy + Terms: even a minimal one. Required for Stripe live mode in most countries.
10. ✅ A test payment with YOUR card (live mode) · then refund yourself

# EXECUTE
Walk me through each item · ask "done?" before moving on. Use my builder tool's specific deployment process.

# GOTCHAS GOING LIVE
- Forgot to swap test keys for live keys (10% of launches)
- Forgot to register webhooks on production URL (15% of launches)
- Privacy policy required by payment provider but not yet drafted

# DELIVERABLE
Your project is LIVE and can take real money. Congratulations is in order.