Everything connected, once
The minimum stack that powers your business. Set it up once. It works from here.
After this module: Your infrastructure is live. Domain, hosting, payments, email delivery. All connected.
This week's pack
Module 5 pack: your infrastructure
Skills, guides, database migrations and edge functions for your back end.
See what's inside (33 files)
Skills (8)
/automation-health · /deploy-edge-functions · /email-gate · /security-audit · /setup-resend · /setup-stripe · /setup-supabase · /system-health
Database migrations (8)
Apply these to set up your back end tables and jobs.
Edge functions (8)
Server-side functions you deploy to your own back end.
Build guides (9)
Step-by-step, one per piece: Root system overview · Homebrew and cli · Supabase setup · Resend setup · Edge function deployment · Stripe setup · Dashboard upgrade · Kanban · Hosting options
👇 After this module
Your infrastructure is live. Database, payments, email delivery, dashboard. All connected.
What you'll do this week
- Where does everything live? Pick your path. Storefront or Studio.
- How the four tools connect, what each one does and why we use it
- Where to host (and register your domain), hosting plus domain registrar choice
- Set up your database with Supabase, free tier, EU region available
- Choose your email home, when to keep your platform vs send through your own system
- Brand your emails for the inbox, fonts, images, logos, and what email clients actually render
- Set up email delivery with Resend, branded transactional from your domain
- Deploy your edge functions, lead magnets, waitlists, event RSVPs
- Set up payments with Stripe, payment links plus webhooks for auto-onboarding
- Upgrade your dashboard to live data, real-time queries on your business
What you'll leave with
- Your path chosen: Storefront or Studio
- Supabase database running in the EU region you chose, free tier
- Branded emails sending from your domain via Resend
- Edge functions deployed for any web signup
- Stripe connected with webhook auto-onboarding
- Dashboard reading live data, not static files
Why this matters
Until now, your system has lived on your laptop, just for you. This week it stops being personal. It becomes the back end of your business. Database, email, payments, forms. Set up once, runs from here. The next three modules build on what you set up this week.
Start here
Lesson 1: Where does everything live? →
The shape of a solo business online
Before you set anything up, here is the bigger picture. There are two ways most solo businesses run online today. One is what you are probably doing already, or about to do. The other is what this course teaches. Neither is wrong. They have different costs, different ceilings, different ways of breaking. Understanding the difference helps you pick on purpose.
The way most solopreneurs run today: a grove of separate trees
Notion is its own tree. Airtable is its own tree. ConvertKit is its own tree. Stripe is its own tree. Squarespace is its own tree. Each one has its own roots in its own soil, its own gardener, its own seasons. They do not share sap.
To get information from one tree to another, you stretch a cable between them. Zapier and Make are the cables. Each cable carries one message: this person paid, tell that tree to send the welcome. The more trees, the more cables. The cables tangle. Sometimes a cable snaps and you do not notice until a customer tells you the welcome never arrived.
Each cable between trees is a separate paid workflow inside Zapier. Cables tangle. Sometimes a cable snaps and you find out from a customer.
You pay a separate bill for each tool. You learn five different interfaces. When one of them changes their pricing or redesigns their layout, you adapt. The roadmap is theirs.
What this course teaches: one tree, deep roots
One set of roots underneath: Supabase, your data. One trunk: your Claude setup, the central nervous system that decides what goes where. Branches and leaves growing on top: your website, your dashboard, your emails, your sequences, your skills. Sap flows freely through the whole tree. No cables between separate trees. No tangles. What grows on top and what stores below are one organism.
Cut a leaf, the tree regrows. Cut a branch, you replace it. The roots stay.
They are products. Supabase is yours.
Notion, Airtable, Zapier, ConvertKit are products. Each one is owned by a company with its own roadmap. They redesign their interfaces. They change pricing tiers. They sometimes remove features you depend on. They decide how you can interact with your own data, and when their rules change, you change with them.
Supabase is a different shape. There is no "Supabase interface" you build your business around. The dashboard is there for setup and the occasional spot-check, but the day-to-day way you see and use your data is the one you build with Claude. A dashboard for yourself. A skill that pulls a contact's history when you ask. A daily summary in your morning protocol. A weekly view in whatever shape suits the week. If Supabase redesigned their dashboard tomorrow, your interface would stay exactly as it was. You built it. You control it.
You stop visiting your data
This is the part that surprises people. After setup, you do not open your "CRM page" anymore. You do not browse rows. The data lives inside the daily flow of your system. The morning protocol pulls relevant contacts when you ask about today. The evening reflection summarises what happened. The dashboard surfaces what needs attention. Your skills read and write through Claude on your behalf. The data is searchable, accessible, structured, but it is the system that touches it for you.
Notion and Airtable were designed to be visited. Their whole purpose is the experience of clicking around your own information. Supabase was designed to be invisible. The data is there when something needs it. You only go and look when you choose to.
Notion vs Airtable vs Supabase, side by side
| Notion | Airtable | Supabase | |
|---|---|---|---|
| What it is | A notes and docs app, with databases as a feature | A spreadsheet styled like a database | A real database, with a setup dashboard on top |
| Who designs the interface you use | Notion's design team | Airtable's design team | You (you build it with Claude) |
| Free tier capacity | Generous for personal use | A few thousand rows per workspace | Hundreds of thousands of rows |
| Different team members can see different rows | Paid plan only | Limited, paid plans | Built in, free |
| Powers your live website signup form directly | Not really, slows down quickly | Yes, with slowdowns at busy moments | Yes, by design |
| Behaves under busy automations | Slows down past a few asks per second | Slows down past a few asks per second per workspace | No documented limit |
| Day-to-day pattern | You log in to look | You log in to look | The system reads and writes for you |
| Leaving with your data | Export to spreadsheet or markdown | Export to spreadsheet | Standard database export, fully portable |
When the patchwork is the right choice
Not every solo business needs to consolidate. The patchwork is a fair shape if either of these is true:
- You run entirely on 1:1 invoicing (Wise links, manual payments, no digital products that auto-deliver after purchase). The consolidation buys you very little.
- You specifically love the Notion or Airtable interface and want to keep paying for that experience. Both are real products you can run a business on. If the interface is what you are paying for, that is a fair trade.
When consolidating pays off
- You run automations. Sequences that go out over weeks. A weekly digest. A nightly cleanup. A score that decays over time. Notion and Airtable both slow down past a few asks per second. Supabase does not.
- You sell digital products that auto-deliver after purchase. Stripe to your code to your database to a welcome email is a few lines. Stripe to Zapier to Notion to Zapier to ConvertKit is six paid workflows that can break.
- You handle EU client data. Five separate products mean five separate data protection agreements, five privacy notices, five vendors to track for compliance. One hub means one.
- You want one bill for the foundation, not five. Supabase, Resend, and Stripe all have free tiers that comfortably cover small business volume. The patchwork tiers usually do not.
Now, which path are you on this week?
Now that you understand the shape, the practical question for the next four weeks: how far does your version of the system step outward?
Tap the statements that are true for you. Your answers tell you which path fits.
What this means for the next four weeks
Storefront 🏪 · Set up the infrastructure that runs without you. Supabase, Resend, Stripe webhooks, edge functions, sequences. Build only the pieces that match your situation. The remaining lessons in this module are your map.
Note: the actual pages and forms people meet (sales pages, /start/ pages, sign-up forms) get built next week in Module 6. This week is the plumbing they'll connect to.
Studio ✨ · Push your root system to GitHub, wire your connectors (Notion, Gmail, Calendar, Drive), and set up your first cloud routine. Your daily work, automated, no database. The Storefront-only lessons later in this module are skippable for you.
Pick one. Build it well. Once you know what you actually use, you can pull pieces from the other path later. Don't try to learn both at the same time.
Next: How the four tools connectHow the four tools connect
Before you set anything up, here is what you are about to build. This module connects four tools to your root system. Each one has a specific job. Together, they handle every form, payment, and email your business runs on.
The four tools, in plain language
1. Supabase
Your database, login system, and the place where your automations live. You pick the hosting region at setup (EU available); the compliance work stays yours either way. Free tier covers a small business.
2. Edge functions
Small pieces of code that wake up when something calls them. The bridge between your website forms, your database, and outside services. The only place keys are safe.
3. Resend
Every automated email leaves through here. Welcome emails, guide downloads, sequence sends, daily briefings. Comes from your domain. Tracks opens and clicks.
4. Stripe
Payments. The customer pays Stripe, Stripe pays you. After every purchase, Stripe pings your edge function so the welcome email goes out and the customer is provisioned without you doing anything.
Four real flows in your business
Flow 1: Someone downloads your free guide
Form on your site → edge function writes them to Supabase → Resend sends the guide → a database trigger enrolls them in your welcome sequence → the hourly cron picks up the next email and sends it.
Flow 2: Someone signs up for your event
Form → edge function → Supabase insert → Resend sends confirmation → trigger enrolls them in your event nurture sequence.
Flow 3: Someone buys your course
Stripe handles payment → pings your edge function webhook → that creates a Supabase auth user, writes to course_purchases, asks Resend to send a welcome with magic password link, and creates an email_tracking row. All in under a second.
Flow 4: Your sequences run on their own
There are two ways to schedule emails that go out over days or weeks. You will use both, depending on the sequence.
Pattern A · Resend holds the calendar
When the trigger fires (someone confirms, buys, signs up), the edge function calls Resend once per email with a scheduled_at for each. Resend holds them and sends each at the right hour.
Use for: short fixed sequences (welcome series, lead-magnet courses). Few moving parts. The whole calendar is set the moment the user confirms.
Pattern B · Supabase cron polls a queue
An enrollments table tracks where each subscriber is in a sequence. Once an hour, Supabase pg_cron calls your edge function. The function reads who is due now, sends through Resend, advances each enrollment to the next step.
Use for: long-running nurture, conditional branches, sequences you might pause or rewrite mid-flight. You can change next week's email today.
Rule of thumb: if the sequence is short and fixed, Pattern A. If it lives on for months and might change, Pattern B. Your free Root System course is Pattern A. Your monthly newsletter cadence is Pattern B.
The non-negotiable: Action, Receipt, Detection
Every automation you build has three layers, and you ship all three or you ship none. Skip any one and you'll find out something is broken when a customer tells you.
1. Action
The code that runs. The function, the cron, the trigger.
2. Receipt
A row in Supabase that says "we tried, here's what happened." For emails: email_sends.
3. Detection
A daily query that surfaces drift. A morning email if anything went wrong yesterday.
When you design any new automation, the FIRST question is "what's the receipt, and what query catches the failure?", not "what's the code that runs?" That's the difference between an automation that runs the business and one you have to babysit.
The pattern
Your website never talks to your database directly. It always goes through an edge function. Edge functions are where your secrets live, where webhooks land, and where scheduled work happens. Supabase is the engine. Resend is the voice. Stripe is the till. Read the rest of the lessons to set them up one at a time.
A moment with this
Of the four flows above, which one is most alive in your business right now? Lead magnet downloads? Event signups? Course purchases? Pick one. The week ahead becomes much simpler if you build for that flow first.
Go deeper
Want the full architecture overview before any setup? Tell Claude: "give me the root system overview". It will read the overview from your starter and walk you through how every piece connects.
📖 Glossary — tap to expand the words you will see this week
None of them are complicated. Skim once, refer back when you forget.
API
A way for one program to ask another program for something over the internet. When your edge function "calls the Resend API", it sends Resend a message that says "send this email." Resend's servers do it and send back a result. You don't see this happening. APIs are how every tool on the internet talks to every other tool.
Edge function
A small piece of code that lives inside your Supabase project. It sleeps until something calls it (a form submission, a webhook, a scheduled time), then wakes up, does one job, goes back to sleep. Your website never talks to your database directly. It always goes through an edge function. That's where your secrets live safely.
Webhook
A message one service sends to another when something happens. When someone pays you on Stripe, Stripe immediately sends a webhook (a tiny POST request) to your edge function saying "this person just paid." Your function reads it and reacts: send the welcome email, create the login. You're not asking Stripe "did anyone pay?". Stripe is telling you, the moment it happens.
Secret
A string of random characters that proves you are you. API keys (Resend's re_xxx, Stripe's sk_live_xxx) and signing secrets (whsec_xxx) are all secrets. Keep them out of git. Out of the browser. Only inside Supabase's secret vault. If one leaks, anyone who finds it can pretend to be you.
Signing secret (and "HMAC")
A specific kind of secret used to PROVE a webhook actually came from Stripe (or Resend, or whoever) and not a stranger pretending. The sender uses the secret to make a signature attached to the message. Your function uses the same secret to recompute the signature. If they don't match, it rejects the request. "HMAC" is the math that does it. You don't need to understand the math. Just know that without it, anyone could fake a purchase.
Environment variable (env var)
A configuration value the code reads at runtime instead of being hardcoded. Your sender email, your domain, your Stripe keys are all env vars. The same code can run on your laptop with one set of values and in production with another. The functions that ship with this starter read every brand-specific value from env vars, so nothing about you is hardcoded.
CORS
A safety check browsers do. Without it, any random website on the internet could call your edge function from someone's browser. CORS lets you say "only my own website is allowed to POST to this function." If your form stops working with a browser error mentioning "CORS" or "Access-Control-Allow-Origin", that's the allowlist not matching your domain.
RLS (Row Level Security)
A Supabase rule per table that says "only show me rows for my user." With RLS on, even if someone steals your public anon key, they cannot read other people's data. With RLS off, anyone with that key can read everything. Tables in your starter ship with RLS on by default. Don't turn it off without thinking carefully.
GDPR
European Union privacy law. Applies if you operate from the EU or sell to anyone in the EU (which is most online businesses). The basics: get explicit consent before emailing people, give them a one-click unsubscribe, store their data in a place you can find and delete on request, log every consent change. Hosting your database in an EU region, double opt-in, the unsubscribe, and the consent_log functions you deploy give you the building blocks. You still set them up and stay responsible for compliance yourself. None of it is compliant by default.
CLI (command-line interface)
A tool you run by typing in your terminal instead of clicking in a UI. The Supabase CLI is what Claude uses to deploy functions and run migrations. You don't need to memorize commands. Claude does that for you.
Where to host (and register your domain)
Before any of the rest of this module works, you need two things: a place to put your website, and a domain name pointing at it. Most students fold both decisions into a single afternoon. The choices below cover both.
The fork in the road
There are two fundamentally different ways to put a website online. The course teaches one of them. If you are already using the other, the rest of this module will not apply to you.
🚨 Everything you upload is public
A web host's entire job is handing your files to anyone who asks for the URL. Every page arrives in the visitor's browser as full, readable code. Right-click any website and choose View Page Source to see this for yourself; your bank's site ships readable code too. This is how the whole web works, and it is safe by itself.
It only goes wrong if a page carries something that should never travel: an API key, a password, a client's email address. The rule that keeps you safe through this entire module: pages carry presentation, servers carry secrets and personal data. The Supabase lesson, two lessons from here, shows where the real locks live.
Path 1: You upload HTML files (this course)
Your website is a folder of files Claude wrote for you. You hand those files to a hosting provider and they serve them to visitors. Cheap, fast, fully owned by you. No monthly software subscription. No platform that owns your content. Pick one of the options below.
Hostinger (~$3-4/mo, bundles domain)
Best for: people newer to technical work who want it bundled. Domain registration, hosting, and email at your domain all in one bill. Drag-and-drop file manager. What this course recommends as the default. What thefourlanguages.com runs on.
Deploy: a one-line ./deploy.sh script using rsync over SSH. Ask Claude: "set up my Hostinger deploy script."
Cloudflare Pages (free, unlimited bandwidth)
Best for: anyone comfortable with GitHub who wants truly free. Push to GitHub, your site rebuilds automatically. Fastest CDN on the internet. No bandwidth limits. You buy your domain elsewhere (Cloudflare Registrar pairs perfectly).
Deploy: git push. Cloudflare detects the push and rebuilds. No script needed.
Netlify (free tier, 100GB bandwidth)
Best for: people who want preview URLs to share work in progress. Same git-deploy idea as Cloudflare. Branch previews are the standout feature.
Deploy: git push, or netlify deploy --prod from the CLI. No script needed.
Vercel (free tier, 100GB bandwidth)
Best for: people who'll build a Next.js app eventually. Same idea as Netlify. Overkill for static HTML. Skip unless you have a specific reason.
Deploy: git push, or vercel --prod from the CLI.
GitHub Pages (free if repo is public)
Best for: personal sites or portfolios where source code can be public. Private repos require GitHub Pro at $4/mo. At that price, Hostinger gives you more.
Deploy: git push to the configured branch (usually main). No script needed.
Namecheap shared hosting (~$2/mo, bundles domain)
Best for: budget-first decisions. Cheaper than Hostinger, slower, older UI. The dollar saved is not always worth the friction.
Deploy: rsync or FTP, same shape as the Hostinger script. Ask Claude: "set up my Namecheap deploy script."
Where to register your domain
If you picked a host that bundles registration (Hostinger, Namecheap shared hosting), you can buy the domain from the same place as your hosting. One bill, one login, one DNS panel. Skip the section below.
If your host does not include domain registration (Cloudflare Pages, Netlify, Vercel, GitHub Pages), you buy the domain separately, then point its DNS at your host. The standalone registrars below all give you free DNS management. That is where you will later add SPF, DKIM, and DMARC records for email (next lessons in this module).
Cloudflare Registrar (~$10/yr, at-cost)
Cheapest, most technical-friendly. Sells domains at wholesale price with no markup. Free WHOIS privacy, free DNS, no upsells. Pairs perfectly with Cloudflare Pages hosting. If you bought a domain elsewhere first, you can transfer it after 60 days.
Namecheap (~$10-15/yr)
Simple and reliable. Free WHOIS privacy. Clear DNS panel. Fair pricing. The default for most indie operators who want to keep registrar and hosting separate.
GoDaddy (~$12-20/yr)
Most popular, often promo pricing then renewal increase. Free WHOIS privacy. Decent DNS panel. Watch for upsells at checkout (most are unnecessary). Fine if you already have a domain there. Otherwise Cloudflare or Namecheap costs less long-term.
Porkbun (~$10/yr)
Indie favorite. Same idea as Namecheap, slightly different name. Free WHOIS privacy, free SSL, simple DNS panel. Fine choice, less name recognition.
If you bundled with Hostinger, you are done. Domain registration and DNS are already in your dashboard. If you went standalone: Cloudflare Registrar for cheapest at-cost pricing, or Namecheap if you want the simplest interface. Skip GoDaddy unless you already use it.
Path 2: A platform builds the site for you
You can use these, but...
If you are on one of these platforms (Squarespace, WordPress, Wix) and want to stay, that is a real choice. But you will not be able to create and deploy your website from your root system directly. Your site lives inside the platform's editor, not as files Claude can edit. The rest of the system still works for you (Supabase backend, CRM, email sequences, dashboard), you just skip the website lessons.
Squarespace ($16-49/mo)
Drag-and-drop builder. Beautiful templates. You build inside their editor, no way to upload HTML files. Strong choice if you are never going to write code.
WordPress.com ($4-45/mo)
Hosted WordPress run by Automattic. Same constraint as Squarespace: you work in their interface, not files. Plugin access depends on plan.
WordPress.org (self-hosted)
The "real" WordPress. Free open-source software you install on Hostinger, Bluehost, or SiteGround. Becomes a PHP application with a MySQL database. The website Claude builds is static HTML, architecturally different. Going this route means your website lives in WordPress, not as files Claude wrote.
Wix ($16-39/mo)
Drag-and-drop. Heavier on features than Squarespace. Strong for service businesses (salons, restaurants, gyms) that need booking flows.
Webflow ($14-39/mo)
Designer-focused. Visual editor that produces real HTML/CSS underneath. Lets you export the code and deploy to a Path 1 host. The hybrid option.
Carrd ($9-49/year)
Single-page sites only. Useful for one-off launch pages or link-in-bio replacements. Not a full site.
If you are new and want it bundled: Hostinger. If you are comfortable with GitHub and want truly free: Cloudflare Pages + Cloudflare Registrar. You can always migrate later. The HTML files do not change, you just point your domain at the new host.
Go deeper
Once you have decided, tell Claude what you picked: "I am going with Hostinger, walk me through the setup" or "set up Cloudflare Pages". It will read the hosting guide and handle the steps with you.
What you decide today
Set up your database with Supabase
✨ Supabase is the place your business remembers things. Session logs, dashboard data, contacts, form submissions, course progress, every moment that needs to outlive a single conversation. Free for what we need this week, hosted in the EU, about 20 minutes from nothing to ready.
What it actually is
A place online where your business data lives. Underneath, it is a Postgres database, the same database technology banks and governments use, with a clean dashboard on top. You sign up, your database is ready, you put rows in like a spreadsheet. The same root holds your contacts, your event signups, your dashboard data, your course progress.
Why not HubSpot or Airtable
HubSpot and Airtable are products. They decide the shape, the limits, the per-seat pricing. You rent a room inside their world. Supabase is the foundation underneath. You decide the shape, the fields, the rules. The same database that holds your contacts also holds your event signups, your dashboards, your course progress. With HubSpot you are a tenant. With Supabase you own the building.
Questions before you start
Can I give different team members different levels of access?
Yes. At the organisation level, Supabase has roles (Owner, Admin, Read-only, Billing). At the data level, Row Level Security lets you say "this person sees only their own rows." Even if someone got into your dashboard, the database itself refuses what is not theirs.
How safe is my client data?
Supabase publishes its security posture: encrypted at rest (AES-256), encrypted in transit (TLS), SOC 2 Type 2, ISO 27001, multi-factor authentication on accounts. Check supabase.com/security for the current list. One honest note: automated daily backups start on the paid plans, so on the free tier you export your own copy (one CLI command, worth putting on a schedule). A stronger baseline than the usual places solopreneurs keep client data (a Google Sheet, a Notion page, a folder on a laptop), and still yours to configure and keep safe.
My website's code is visible to anyone. How is any of this safe?
Every website's pages are readable code, including your bank's. That is how browsers work, and it is safe because pages never carry the keys to anything. Supabase gives you two keys for exactly this reason. The publishable key sits in your pages and can only do what your database rules allow an anonymous stranger to do, like submitting a form. The service key, which can do anything, lives only on the server side (your .env file and edge function secrets) and never appears in a page.
The real lock is Row Level Security: the database itself checks every single request and refuses what the requester is not allowed to see, no matter what code they run. A login screen organizes the experience; RLS protects the data. When a client asks whether your setup is secure, this is the architecture answer: pages carry no secrets and no personal data, and everything personal sits behind rules the database enforces server-side. It stays true only while you keep it true, with the right policies on every table, which is why the security audit in Module 8 re-checks it.
Is the free tier enough?
For most solopreneurs, comfortably. 500 MB of database (hundreds of thousands of contact rows), unlimited API requests, 5 GB of bandwidth. Free projects pause after a week if literally nothing touches them. Any normal use of your live site keeps it active. A signup form submission, a dashboard page load, a logged-in visit, all count.
What does "paused" actually mean?
The whole project, not individual tables. The database goes offline as a unit until you click "Restore" in the dashboard. One click, takes a minute, nothing is deleted. While active, your signups and queries work normally even if a week passes between them, as long as something else is touching the project.
GDPR for an EU-based business?
Pick an EU region (Frankfurt or Ireland) when you create the project if you want your data held in the EU. Sign Supabase's Data Processing Agreement from your dashboard. Write a privacy notice for your clients explaining what you store and why. That covers the storage layer, and only that layer: none of it makes your business GDPR compliant by itself, and the AI side is a separate question. The Privacy & GDPR module in Get Set Up walks through the rest.
Do I need to know SQL?
No. The dashboard has a Table Editor that looks and behaves like a spreadsheet. Click to add a column, click to add a row. SQL becomes useful when you want to ask questions across your data, and even then Claude writes it for you.
What if I outgrow it. Can I leave?
Fully. Supabase is Postgres, the most portable database technology there is. One CLI command exports everything as a standard SQL file that any other Postgres host will import. No proprietary format. No lock-in.
Before this works: you need two small command-line tools (Supabase CLI + Deno) installed once. Tell Claude "install the CLI tools I need for this module" and it handles them in a minute. Once.
What you will do
supabase link in your terminal to connect your local project to the cloud database..env file (never committed to git) and as Supabase secrets for edge functions.A moment with this
If your customers, partners, or contacts are mostly in the EU, EU Frankfurt is the only sensible region. If your audience is mostly elsewhere, you can pick a US region. Pick once, on day one. Migrating regions later is hours of work that buys nothing.
Go deeper
Ready to set it up? Tell Claude: "let's set up Supabase" or "set up my database". It will walk through the project creation, the linking, the auth toggle, and storing your secrets safely.
Choose your email home
Before you set up email delivery, decide where it lives. You probably already use a platform: Substack, Beehiiv, Kit (formerly ConvertKit), Mailchimp, Flodesk, something. The next lesson will show you how to send email through your own system using Resend. This lesson decides whether you should.
The honest answer for most of you is hybrid. Keep your platform for what it is good at. Build your own only for what only your own system can do. This lesson tells you which is which.
What your platform does that you cannot see
Three layers of magic make a polished newsletter platform feel "easy" that you take for granted.
1. Send-time email rendering pipeline
Email clients (Gmail, Outlook, Apple Mail) are stuck in 2010. They strip web fonts. They strip CSS in style blocks. They reject flexbox and grid. Your platform's editor renders modern visuals on screen, then at send time runs an invisible pipeline that inlines every style on the element itself, replaces your brand font with a fallback stack (Karla becomes Arial when Karla is not loaded), converts your layout to old-school HTML tables, caps width at 600 pixels, and hosts every image on the platform's CDN. Without that pipeline, your email arrives broken: ugly fallbacks, busted layout, missing images.
2. Deliverability infrastructure
SPF, DKIM, DMARC records on your sending domain. Bounce handling. Suppression lists so unsubscribed users do not get re-added by accident. List-Unsubscribe header (the one Gmail uses to show "unsubscribe" at the top of the message). Sender IP reputation. Spam testing before send. None of this is glamorous. All of it is what gets your email out of spam.
3. Compliance plumbing
GDPR consent log. Double opt-in flow when you switch it on. Hard bounce removal. Unsubscribe audit trail. Privacy policy linkage. If you operate from the EU or sell to EU residents, this is the plumbing that keeps your email on the right side of consent rules (the Privacy & GDPR module has the legal background).
When you build your own system, none of this is automatic. You build it.
The platforms, side by side
Each one trades something for something else. There is no "best." There is only what fits the work you are actually doing.
Substack
What it is: writing, publishing, and discovery platform with a built-in social network. Now handles newsletters, podcasts, video, and live streams from one editor. Discovery comes from the Substack Network.
You get: multiple post formats in one editor (article, podcast, video, live stream, static page), native podcast hosting with auto-RSS to Apple Podcasts and Spotify (plus AI text-to-speech narration of written posts in six voices), native video hosting plus live streaming with auto-distribution to YouTube and LinkedIn, the Substack Network for discovery (cross-publication recommendations, Notes feed, category leaderboards, semantic search), reader referrals with milestone rewards, paid subscriptions with trials, gifting, and group plans, post-level access control (free, free-subs only, paid, founding), drip campaigns triggered by subscriber lifecycle events (new free sub, new paid, founding upgrade, churn), targeted ad-hoc emails to subscriber segments, custom CSS for emails, A/B headline testing, public web pages for every issue (indexed for SEO), comments on each post.
You lose: brand control (the URL says substack.com, the design is mostly Substack's), tag-based subscriber model (no proper tags, just lifecycle states), tag-driven conditional automations, robust API (limited and mostly read-only), engagement data ownership (you can export the list, but reads and clicks live with Substack).
Best for: writers and multi-format creators (newsletter plus podcast plus video) whose primary growth lever is the Substack network, or who want public web pages indexed for SEO.
Beehiiv
What it is: newsletter platform with podcast hosting, web builder, and built-in monetisation, all in one. Built by ex-Morning Brew people. Strongest of the consumer-grade tools for direct ad revenue.
You get: the Beehiiv Ad Network (real advertisers paying you per send. Standout feature vs every other platform on this page), Boosts (paid recommendations between newsletters), podcast hosting and distribution alongside your newsletter, web builder for branded archive pages on your own domain, paid subscriptions, referral programs, recommendations network, polls embedded in emails, conditional automations that branch on poll answers and reader behaviour (someone clicks "yes" on a poll, they go down path A; "no" goes down path B), segments that update dynamically based on actions, RSS-to-send, multiple newsletters per account, robust API for sending and reading subscribers, real analytics (open by issue, click, growth), survey forms.
You lose: the Substack social ecosystem (different network, different reader culture), Kit's deep tag-based subscriber model, Flodesk's custom-font upload.
Best for: growth-focused creators monetising via ads or sponsorships, running a podcast alongside a newsletter, using polls and behaviour to personalise each reader's next email.
Kit (formerly ConvertKit)
What it is: the long-time creator email platform. Strongest visual automation engine of the consumer-grade tools.
You get: Visual Automations (drag-and-drop conditional logic, the flagship and most flexible if-this-then-that of any platform here), tag-based subscriber model (one subscriber, many tags, very flexible), Sequences for drip campaigns, Broadcasts for one-offs, native Commerce (sell digital products directly with Kit handling the checkout and delivery), apps marketplace with creator integrations (Transistor.fm for podcasts, SavvyCal for booking, Broadcast Boost), landing pages and forms with custom fields, Liquid templating in emails for real personalisation, robust API, free migration service from any other platform if you are on a paid plan, consistently strong deliverability.
You lose: visual polish (the editor is functional, not Flodesk-beautiful), public web archive (minimal), network-driven discovery (none built-in, you bring your own audience), native podcast hosting (Transistor app integration only).
Best for: businesses where the email IS the product (courses, coaching, info products, digital downloads) and where automation depth and tag-based personalisation matter more than visual design.
Mailchimp
What it is: legacy general-purpose marketing platform owned by Intuit since 2021. Has expanded beyond email into a full marketing suite (websites, ads, CRM).
You get: Marketing Automation Flows (Customer Journey Builder), Behavioral Targeting, Generative AI for body copy and subject lines, Send Time Optimization (AI predicts the best send time per recipient), Dynamic Content (personalise content blocks per recipient), Predictive Demographics, full Website Builder and Landing Pages, A/B Testing, Marketing CRM, Tags and Customer Profiles, Smart Recommendations, Retargeting Ads (run paid ads from inside Mailchimp), Transactional Emails, Webhooks, Surveys, Content Studio, deep integrations with Canva, Salesforce, Shopify, Instagram, Google Analytics.
You lose: pricing scales aggressively as your list grows, the brand has aged into "small business" rather than "creator" territory, deliverability can be inconsistent on the free tier, no native podcast hosting.
Best for: small businesses with an existing Mailchimp setup, e-commerce stores wanting integrated retargeting, teams that want one tool for email plus landing pages plus ads plus CRM.
Flodesk
What it is: design-first email platform. Patented layout system, custom font upload, beautiful templates. Pricing scales by subscriber count.
You get: custom fonts uploaded directly into the editor (rare among email tools, where your brand font actually shows where supported), brand color palette baked in, patented layout system for in-email graphics with no third-party design tool needed, countdown timers that match your brand, polls embedded in emails, Link Actions (segment subscribers and trigger automations when they click any link), workflows with visual builder, abandoned cart automation, Forms and Landing Pages and Sales Pages, audience segmentation, email analytics and reporting, plays well with Squarespace, Showit, Shopify.
You lose: automation depth versus Kit (workflows are nice but shallower than Kit's visual builder), tag complexity (simpler model than Kit), custom HTML import (limited), API (basic), Substack/Beehiiv-style network discovery (none).
Best for: brand-led businesses (designers, photographers, wedding industry, lifestyle, course creators with a strong visual brand) where the email's design IS part of the product.
Build with your own system (Resend + Supabase)
What it is: not a newsletter platform. A transactional email API plus your own database. The next lesson sets it up.
You get: total control (every email is your code, every subscriber is your row), real-time triggers (user did X, send email Y) with full conditional logic, multi-step sequences with branching that depends on database state, costs scale with usage rather than list size (Resend covers 3,000 emails per month free, then $20 per month for 50,000), data lives where you live (your Supabase project), a full consent log built in and EU hosting available, no platform lock-in.
You take on: the send-time rendering pipeline (you write email-safe HTML, see below), deliverability infrastructure (SPF, DKIM, DMARC for your sending domain), suppression management (your bounces, your unsubscribes, your job), HMAC-signed unsubscribe tokens, bounce webhooks, click and open tracking, list management UI (Resend has none, you read your own database).
Best for: people who already run on Supabase, who have transactional emails to send (purchase confirmations, lead-magnet sequences, automated onboarding), and who want their CRM and email database to be the same row.
Three patterns for choosing
Hybrid (most common, recommended for most)
Keep your newsletter platform for broadcasts: newsletters, announcements, content. Build with Resend for transactional: purchase emails, lead-magnet sequences, post-event reminders.
Why this is usually right: broadcasts benefit from the platform's send-time pipeline, design tools, audience growth features, list-management UI, and deliverability reputation. Transactional benefits from being native to your system, triggered by real events, recorded in your own database. Most professional setups look exactly like this.
Replace selectively
Move one specific use case from your platform to your own system. Most common: lead-magnet sequences, post-purchase onboarding, multi-touch nurtures triggered by behavior.
Reasons to replace selectively: the sequence needs to react to data only your system knows (course progress, app usage, dashboard activity), the sequence needs to update CRM data as it sends (mark someone "engaged" when they reply), or the trigger fires from a Stripe webhook or app event your platform cannot see.
Replace fully
Move everything, including broadcasts.
Reasons to consider: you are very EU-GDPR strict and want full data residency control, your "newsletter" is small and intimate (under 300 people) and you want zero platform overhead, or you genuinely hate the platform you are on and the editor is the daily drain. If you go this route, you take on the whole rendering pipeline. The next section names what to consider.
If you replace your platform: what your platform was doing for you
If you decide to send branded emails through Resend yourself, here is what you take on. None of these are hard. They are simply not free.
The next lesson sets up Resend itself. The email-sequence skill (already in your system) handles all of the above for you when you ship a sequence. Read it before you write code: .claude/commands/email-sequence.md.
How to use Claude WITH your platform (the hybrid play)
Most of you will land on hybrid. Here is how Claude actually helps inside your platform without forcing you to leave it.
Pattern 1: Analyze your platform performance
Export your subscriber list and your last 10 issues' performance from your platform (every platform supports CSV export). Drop the CSVs into your root system. Ask Claude:
"Read the CSVs in heart/content-hub/newsletter-exports/. Tell me my open rate trend over the last 10 issues, my best-performing subject lines, the type of content that gets the most clicks, and the segments of subscribers I should send more or less to."
Pattern 2: Write the body in your voice, format inside your platform
Open your platform's editor. Before you type a word, ask Claude:
"I want to write a newsletter about [topic]. The angle is [angle]. Read my voice guide and my recent issues, then draft a 350-word body in my voice with a real hook, two concrete examples, and one specific ask at the end."
Claude drafts. You paste into the platform's editor (the platform's send-time pipeline handles the rendering). You tweak the formatting in the platform's UI where the design lives.
Pattern 3: Generate the visual asset, not the layout
You want a custom image at the top of your issue. The platform's stock images are bland. You generate a brand-aligned image with Claude (the /ai-image skill, or another image tool you trust), save the file, upload through your platform's image picker. Use the platform for layout. Use Claude for the asset.
Pattern 4: Generate the sequence outline, build inside the platform
You want a 5-email welcome sequence inside Kit. Ask Claude:
"I want to write a 5-email welcome sequence for [audience]. Each email is short, in my voice, no marketing speak. Email 1 sends immediately, then days 2, 4, 7, 14. Draft the sequence with subject line plus body for each."
Claude drafts the copy. You rebuild it as blocks inside Kit's editor (so Kit's pipeline handles the rendering). Slow but bulletproof.
Track every email event in your own system
Whichever platform you use, you can track every meaningful email event in your own root system. The point is to make your dashboard show what your platform alone cannot: cross-platform insight, your own tagging, your CRM-aware view.
Copy the prompt below into Claude. Adapt the part in [brackets] for your specific platforms. Claude will design the tracking schema, build the dashboard view, and walk you through every step.
Do not run two newsletter platforms in parallel. Pick one home for broadcasts. Use your own system for transactional. Decide today, before the next lesson sets up Resend. The decision is real even if it lands at "stay where I am" (which counts).
Brand your emails for the inbox
If you decided to send emails through your own system, you take on the rendering pipeline that platforms like Kit and Beehiiv hide from you. This lesson is the missing manual: how to put your brand in the inbox so it actually shows up the way it does on your website.
Email clients are not browsers. They strip your CSS, ignore your fonts, refuse your images, and break your layout if you let them. What follows is the floor for every branded email you ship.
The one rule that explains everything else
An email is HTML that fetches everything else over the public internet.
Your recipient's email client downloads your HTML, then makes separate requests for every image. If a URL in your email points to your laptop, your local repo, your private Drive, or anything behind a login, the recipient sees a broken image. The image must be reachable by anyone on the internet typing the URL into a browser.
How images actually get into emails
Most students think "I'll just put the image in my repo." That does nothing. Repo files are not internet-reachable. The image needs a public HTTPS URL. Three real ways to get one.
1. Your own deployed website (recommended for logos and recurring assets)
If you have a website folder that gets deployed (most of you do, even if you didn't realize), drop your image into a subfolder, run your deploy, and the file becomes a public URL.
Example pattern: a file at website/email-images/logo.png in your repo, after deploy, lives at https://yourdomain.com/email-images/logo.png. That URL is what goes in your email's <img src="...">.
Test: paste the URL into an incognito browser tab. If you see the image, every email client can too. If you see a 404, your email recipients will see a broken image.
2. Resend's image upload (best for one-off newsletter hero images)
Resend dashboard has an image uploader. Upload, get a stable URL back, paste into your email HTML. No deploy step. Use this for images that are specific to one newsletter and won't be reused.
Same test: paste in incognito, see the image, you're good.
3. A dedicated image host (Cloudinary, Cloudflare Images, R2, S3)
Overkill for most of you. Useful only if you ship a lot of email or want automatic resizing. Skip until you need it.
What does NOT work
- Local file paths like
/Users/you/Desktop/photo.jpg - Relative paths like
./images/photo.jpg - Repo files that have not been deployed
- Private Google Drive, Dropbox, iCloud links (they require login)
- Base64-encoded images embedded in the HTML (Outlook strips them)
- SVG files (inconsistent client support, especially Outlook). Convert to PNG.
How fonts actually work in emails
You cannot ship custom fonts in email reliably. Most email clients strip <style> blocks (where Google Fonts @import lives) and ignore <link> tags pointing to external fonts. So your custom brand font almost never loads in the recipient's email.
The pattern that works: declare a web-safe font stack with your brand font first as a wish, and a system font as the fallback. Where the brand font happens to be installed (rare), it shows. Everywhere else, the system font shows. Both render reliably.
Stack examples that render everywhere
For warm serif headlines (book/magazine feel):font-family: Charter, Georgia, Times, 'Times New Roman', serif;
Charter ships on every Apple device. Georgia is on every device made in the last 25 years. You always get a real serif.
For modern sans-serif body (clean, friendly):font-family: 'Karla', Arial, Helvetica, sans-serif;
Karla shows where it happens to load (some Apple Mail), Arial fallback elsewhere. Both clean.
For UI labels, footers, eyebrows:font-family: 'Helvetica Neue', Arial, Helvetica, sans-serif;
System sans, looks the same everywhere.
If your brand truly cannot live without a specific custom font (a script font for the logo, a display font for headlines), the answer is to render that text as a PNG image once, host it (see images section above), and embed it. The image is what email clients see. The text is part of the picture.
Brand identity in the inbox: the full toolkit
<img> with explicit width and height. Never SVG.<img>, not background-image.Test before you send (every time)
Send a test version to at least three inboxes that render differently:
Open each. Verify: the logo renders, the layout holds, the fonts fall back gracefully, and the unsubscribe link is visible and clickable. Fix the worst-case render before shipping.
Paste your email HTML and say: "Audit this email for inbox rendering. Check: hosted image URLs, web-safe font stacks, table layout, 600px max width, visible unsubscribe link." Claude will tell you what will break and where.
Set up email delivery with Resend
Your system needs to send emails: confirmation emails for signups, welcome sequences for new subscribers, transactional emails for purchases. Resend handles this. It is simple, reliable, and free for up to 3,000 emails per month.
Read first: Pick your data residency before you sign up
Resend stores email data in the region you pick when you create the account. The default is US. If you operate from the EU, sell to EU residents, or want your email data held in the EU, switch to the EU region during signup.
Why it matters: changing region after the fact is a hassle. You cannot migrate an existing account between regions. The fix is to create a new account in the right region, re-verify your domain, regenerate API keys, update every Supabase secret, and migrate your suppression list. Hours of work that costs you nothing if you pick right on day one.
Match your residency to where Supabase lives. If your Supabase project is in EU Frankfurt, your Resend account should also be EU. Same logic for US: keep them in the same region so your transactional flow does not cross jurisdictions.
What you will do
RESEND_API_KEY. This is what your custom edge functions (lead-magnet sequences, post-purchase emails, etc.) use to send.resend-webhook function, all email.* events). Set the signing secret as RESEND_WEBHOOK_SECRET. Without this you only know that you called the API, not whether the email arrived.What those DNS records actually do
Resend will give you three TXT records to paste into your DNS. Each answers one question Gmail and Outlook ask about every email arriving in their pipes.
SPF
"Is this server allowed to send mail for this domain?" The record lists who is approved. Resend, Google, anyone else sending as you. Anyone else is a stranger using your name.
DKIM
"Was this email tampered with on the way?" Resend signs every message with a private key. The receiving server checks the matching public key in your DNS. One character changed, the signature breaks.
DMARC
"What should I do if SPF or DKIM fails, and where do I send the report?" Three levels: p=none (watch), p=quarantine (spam folder), p=reject (bounce).
The mental model: SPF and DKIM are the locks. DMARC is the rule for what to do when a lock fails, plus the camera that tells you who tried.
📖 Deliverability deep-dive — tap when you want to harden DMARC
The DMARC upgrade path
Most domains ship with v=DMARC1; p=none;. Translation: "I have a record, but if a stranger spoofs me, do nothing." Tighten in three phases.
Phase 1: monitor (today)
v=DMARC1; p=none; rua=mailto:dmarc@yourdomain.com; fo=1
No enforcement. You start receiving aggregate reports. Run for two to four weeks. Free parsers: Postmark DMARC Digests, dmarcian.
Phase 2: quarantine (after reports look clean)
v=DMARC1; p=quarantine; pct=25; rua=mailto:dmarc@yourdomain.com; fo=1
Spammers spoofing you start landing in spam. pct=25 ramps gently. Increase to 100 once stable.
Phase 3: reject
v=DMARC1; p=reject; rua=mailto:dmarc@yourdomain.com; fo=1
Spoofed mail is bounced before reaching anyone. What banks and large brands run.
DMARC tags worth knowing
p= policy (none / quarantine / reject)rua=mailto: where aggregate reports gopct= percent of failing mail the policy applies to (use during ramp-up)fo=1 generate a report on any authentication failuresp= subdomain policy (inherits from p= if omitted)Domains that do not send mail (the shortcut)
A parked domain, an old brand, a receive-only inbox: skip the ramp. Anything claiming to be from a non-sending domain is spoofing by definition. Two records lock it.
v=DMARC1; p=reject; rua=mailto:<you@another-domain>; fo=1
v=spf1 -all
First as a TXT at _dmarc.yourdomain.com, second on the root. Skip the SPF if you already have one. Don't stack two.
Cleanup, while you are in there
DMARC only belongs at the root: _dmarc.yourdomain.com. If you see _dmarc.www in your DNS, delete it. The root record covers every subdomain.
Custom click-tracking subdomain
Resend may show a yellow banner: "your domain uses shared click tracking." Worth fixing once you are sending real volume. Resend dashboard → Domains → Add domain. Subdomain: links. Click tracking on, open tracking off. CNAME record into DNS, verifies in 10 to 15 minutes.
A moment with this
Open the last automated email you got that landed in spam. Look at the headers if you can. Was the sending domain different from the brand on the email? Was DKIM missing? You will start to see why these three records matter the moment they fail.
Go deeper
Ready to set it up? Tell Claude: "set up Resend" or "help me with email delivery". It will handle account creation, domain verification, the API key, the webhook, and a test send.
Deploy your edge functions
Edge functions are small programs that run on the internet and handle things like: someone signs up on your website, someone buys your product, someone unsubscribes from your emails. They are the glue between your website and your database. (You may hear them called "form handlers" or "webhook handlers" elsewhere. Same thing. We call them edge functions.)
Your starter system ships with eight pre-built edge functions in supabase/functions/. You fill in your secrets, push them, and deploy. Claude does this for you.
What gets deployed
events.ts to add your live events.Before deploy: fill in your secrets
The functions read every brand-specific value (your domain, sender email, business name, Stripe payment-link IDs, etc.) from environment variables. The starter ships a fully-commented supabase/functions/.env.example listing every one. You copy it to .env, fill in the blanks, and Claude pushes them to Supabase as secrets in one command. Nothing brand-specific is hardcoded.
A moment with this
Of the eight functions above, which two do you actually need this week? Most students start with guide-signup + confirm-email (your lead magnet flow) and add the rest as their business reaches for them. Don't deploy what you will not use yet.
Go deeper
Ready to ship them? Tell Claude: "deploy my edge functions" or "let's set up the form handlers". It will copy the env example, ask you for each value, push your secrets to Supabase, deploy each function, register the Stripe and Resend webhooks, and run a real test signup to confirm.
Set up payments with Stripe
Stripe handles your payments. When someone buys your product, Stripe processes the payment and sends a webhook to your system so it knows what was purchased. No payment page to build. No checkout flow to code. Stripe hosts it all.
What you will do
checkout.session.completed, invoice.payment_succeeded, charge.refundedThree events, not one (or your income disappears)
Most "Stripe is broken" stories trace back to a webhook subscribed to one event, when it needed three. Each one captures a different kind of money:
checkout.session.completed
Fires once, when a customer finishes a checkout. New course buyers, first month of any subscription, one-off invoices. If this is missing, your welcome emails never send.
invoice.payment_succeeded
Fires every time a recurring subscription renews. Without this, your dashboard shows the first month of every membership and then goes silent. Three months in, you think your memberships generated the same income as month one. They didn't, you just stopped recording.
charge.refunded
Fires when you refund someone. The starter handler records this as a negative-amount row, so your year-to-date total self-corrects. No mental math.
All three are checkboxes on the same Stripe webhook setup screen. Tick all three the first time. Future-you will not have to backfill.
The income table (stripe_payments)
Your starter system has two tables that record purchases. They sound similar but do different jobs:
course_purchases
One row per checkout. Tells you "who has access to what." Useful for granting course access. Does not capture renewals after month one.
stripe_payments
One row per actual payment. New checkouts, monthly renewals, refunds (as negative rows). This is the table your dashboard reads for income, year-to-date, monthly trend. Idempotent on Stripe event id and invoice id, so retries can never double-count.
Your starter ships migration 007_stripe_payments.sql and a webhook that writes to it on all three events. You do not have to build this. You only have to subscribe to the three events above. Setup guide: supabase/STRIPE-SETUP.md in your repo.
The four words people mix up
Stripe has a few different things that all sound similar. Here is what each one actually is:
Payment link
A hosted checkout page Stripe creates for you. You give it a product and a price, Stripe gives you back a URL. You share that URL anywhere (button on your site, DM, email). Looks like buy.stripe.com/abc123.
plink (or "plink ID")
The internal ID for one of your payment links, e.g. plink_1ABC.... You see this in Stripe dashboard URLs and webhook events. It is just the unique name for that specific payment link.
Webhook
A message Stripe sends your system every time something happens (a purchase, a refund, a failed payment). Your edge function listens for these messages and reacts: send the welcome email, create the login, log the sale. The customer never sees this. It is server-to-server.
Invoice URL
A one-off bill for a specific person. You make an invoice in Stripe ("€500 for Jane Doe"), Stripe gives you a hosted URL like invoice.stripe.com/i/.... They pay it. Different from a payment link because it is personal and one-time, not a reusable product checkout.
When to use which: Payment link for products you sell repeatedly (course, sprint, membership). Invoice for one-off custom work or someone paying you a specific amount. Webhook is always running in the background, you do not pick it.
How to test the full flow without losing money
Webhooks are where most setups silently break. The payment goes through, Stripe takes the money, but the welcome email never sends and the customer is left in the dark. You need to see the whole chain run end-to-end at least once.
The cleanest way: create a 100% discount code, apply it to your payment link, and "buy" your own product.
- In Stripe: Products → Coupons → New → 100% off. Optionally restrict to one product so you do not give it away by accident.
- Edit your payment link → Options → allow promotion codes. Save.
- Open the payment link in a private/incognito window. Use a different email than the one connected to Stripe (otherwise Stripe blocks the purchase). Apply the discount code. Complete the "purchase".
- Check three things landed: (1) the welcome email arrived, (2) the row appeared in your
course_purchasestable in Supabase, (3) you can log into the course with the magic link. - If any of those three failed, check the Stripe dashboard → Webhooks → your endpoint → recent attempts. The error message is there.
Same trick for testing membership: set up a 100% discount on the recurring price. Your "subscription" is free, you can confirm the recurring webhook fires monthly without paying yourself. Cancel the test sub when you are done.
If you would rather not deal with discount codes, the alternative is buying your own product for the real price (with a different email) and refunding yourself in Stripe afterwards. Same end-to-end test, costs you the Stripe fee on that one transaction.
If you sell memberships, subscriptions, or anything with recurring billing, you will also need a self-serve billing page so customers can update cards, download invoices, and cancel without emailing you. Covered in Module 6.
A moment with this
Look at the last three things you sold (or want to sell). Are they repeatable products that the same checkout could handle every time? Or are they one-off custom things priced per person? That tells you whether you need payment links, invoices, or both.
Go deeper
Ready to set it up? Tell Claude: "set up Stripe" or "let's set up payment links". It will walk through account creation, the payment links, the webhook, and the discount-code end-to-end test so you can see your welcome email actually arrive.
Upgrade your dashboard to live data
✨ In Part 1, your dashboard read from local files on your laptop. Quietly useful, but only as fresh as the last time you opened a file. With Supabase live, the dashboard becomes a window into the business as it actually is, right now. Yesterday's energy. This week's saves. The contact who replied an hour ago. Always current, no manual refresh.
What changes
Before (local)
Reads from JSON files on your machine. Updates only when you edit them by hand, or when Claude does.
After (Supabase)
Reads from your live database. Refreshes itself when you save a session, complete a task, log a relationship moment.
The shift is subtle but it changes what the dashboard is for. It stops being a record you maintain and starts being a quiet companion. You glance at it on a slow morning and see your week in four languages. Soul, Mind, Heart, Body, all in one place.
Income, on top of the dashboard
When the Stripe webhook from the previous lesson is wired correctly, your dashboard's Today tab gets a strip across the top: year-to-date income, this-month income, and a 12-bar trend showing every month. It reads from the stripe_payments table, which captures one-time purchases, recurring renewals, and refunds (as negative rows). New payments appear automatically. Every renewal updates the bar for that month. Refunds subtract themselves. You never edit it by hand.
If the strip ever stays stuck at a single number for weeks while you know memberships renewed, the cause is almost always a missing Stripe event subscription, see the previous lesson. Add the missing event in Stripe and the next renewal lands on its own.
Who is moving through your course
If you sell a course, the live dashboard adds a Students tab: which lessons people open, which they finish, and where the cohort stops. It reads the same way for any stepped flow you build, a quiz, an onboarding sequence, a sales funnel. A step everyone reaches but few finish is the one to make clearer. You wire the tracking onto your course pages in Module 6.
A moment with this
What is the one number you would actually open the dashboard to check, daily? Energy yesterday? Tasks pending? Contacts cooling? The dashboard works hardest when it answers a question you genuinely have, not when it shows everything at once.
Go deeper
Ready to flip it on? Tell Claude: "upgrade my dashboard to live data" or "move my dashboard to Supabase". It will run the migrations, connect the dashboard HTML, and confirm data is flowing before you close the session.