The zip opens into a folder named module-5-pack. Downloading it is not installing it. To install it, open the pack in Claude Code. Open Claude Code in your system folder and ask it to list what you already have before it adds anything, then let it add only the files that are new to you.

It cannot overwrite anything you made. Your dashboard from Module 4, your brand colours, any skill you have edited: if anything in the pack shares a name with a file of yours, Claude stops and asks you first, before it copies anything. This pack adds to your system, it does not replace what is in it. The pack README opens with the exact words to paste, so start there rather than typing your own.

Plan for one to two focused sessions across a few days. The clicking and setup itself is only a few hours. What stretches it to a day or two is waiting on things outside your control: DNS records propagating, and Stripe verifying your business. You can start those waits on day one and do everything else while they clear.

What you need on hand

• Two command-line tools, installed once. The Supabase CLI and Deno, both through Homebrew (which you set up back in Part 1). You install them once. Claude runs the actual commands for you from there.
• A domain you own, or one you are ready to buy this month. Your email delivery and your live sign-up forms both attach to it.
• A Supabase account (free). Your database project spins up in about two minutes.
• A Resend account (free up to 3,000 emails a month) and access to your domain's DNS settings. After you add the email records, they take a few minutes to a few hours to verify. You add them, then come back.
• A Stripe account. You can build and test the whole payment flow today in test mode with no waiting. But before you can take a real payment, Stripe verifies your business (bank details and an ID check), which can take a day or two to clear. If you plan to launch soon, start that verification on day one so it is done when you need it.

You do not do this in one sitting

There are natural places to stop and come back. Each piece stands on its own:

• After your database is live.
• After you have added your email DNS records, come back when they verify.
• After you have started Stripe verification, come back when it clears.

And you may not need every piece. The first lesson helps you choose your path before you build anything, so you only set up what your business actually uses.

Watch: A grove of separate trees (1:47)

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 next lessons in this module (Hosting through Dashboard) are your map.

Note: the actual pages and forms people meet (sales pages, /start/ pages, sign-up forms) get built in Module 6. This module is the plumbing they'll connect to.

Studio ✨ · Wire your connectors (Notion, Gmail, Calendar, Drive), turn the questions you ask every week into skills, and set up your first routine that runs on its own. Your daily work, automated, no database to maintain. The three Studio lessons at the end of this module are your path. The Storefront infrastructure lessons in between are skippable for you.

Watch: None of this is actually AI (0:31)

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.

Rule of thumb: if the sequence is short and fixed, Pattern A. If it lives on for months and might change, Pattern B. A short lead-magnet welcome series is Pattern A. A 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.

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.

Watch: Squarespace and Wix can't do this (0:55)

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.

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.

🔧 If you are not sure the domain is pointing at your host

Check this before you move on, because a domain pointed at the wrong place is what makes email verification fail two lessons from now, and there it looks like an email problem rather than a domain one. You will know it worked when your host's dashboard shows the domain as connected or active, with no warning next to it. A fresh change can take anywhere from a few minutes to a few hours to travel, so "not yet" and "wrong" look identical for a while: if it has been under a couple of hours and nothing shows an error, that is normal, wait. If your registrar still lists its own default nameservers rather than your host's, that is the real thing to fix. Screenshot your host's domain page and your registrar's nameserver page, show Claude both, and it will tell you which one is wrong.

Watch: Leaving with your data (0:51)

Watch: You stop visiting your data (1:03)

🔧 How you know these four landed

Your project shows Active in the Supabase dashboard, and supabase link prints your project ref back at you. Step 3 is the one that fails quietly: if you skipped it, nothing errors, your login and magic links simply do nothing, and the fix is to add your site URL under Authentication, URL Configuration, Redirect URLs. If a command fails, paste the whole error to Claude. Nothing is live yet, so nothing is broken and nothing is lost.

Watch: Choose your email home (0:42)

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.

The unsubscribe path deserves one real test. Four traps pass every code review and fail the moment a person clicks: a page wired to a different endpoint than the one your token was signed for (each unsubscribe then fails politely, forever), a List-Unsubscribe header pointing at a page instead of a processing endpoint (Gmail's one-click POSTs into the void), a tokenless link in your internal reports, and per-type opt-outs that silence someone who re-signed up later. The Resend setup guide in your Repo (guides/15-resend-setup.md) walks through all four. The check that catches them: open the unsubscribe link from a real sent email, and read the database row it wrote.

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).

What "you build it" looks like: the leaving page

Someone clicking unsubscribe might want everything to stop, or might just want the one series that got too heavy this month. A platform gives you a single button for both, so the second person leaves entirely. When you own the plumbing you can offer the smaller answer too.

Below is the live page on this site, reached from the footer of the emails you get from us. Each line is a separate series you can stop on its own, and the page asks the server first, so a series you were never enrolled in is dimmed rather than offered. The red button stays in plain sight for anyone who wants it.

This one is in your Repo, in the neutral template palette with two example series to replace. It ships in both the Module 5 and Module 6 packs at the same path, body/website/unsubscribe/index.html, so if you have both, the second one to install finds the file already there and leaves yours alone. The same guide (guides/15-resend-setup.md) covers what to fill in, and the trap that makes a per-type opt-out silence someone who signed up again later.

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.

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.

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.

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 own machine, 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.

What does NOT work

• Local file paths like /Users/you/Desktop/photo.jpg
• Relative paths like ./images/photo.jpg
• Files that have not been deployed yet
• 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.

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.

Watch: Two flavors of automation (1:30)

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 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.

🔧 If verification never completes

You will know it worked when Resend shows a green "Verified" next to your domain. Still pending after a few hours? The records are almost always sitting in the wrong DNS panel: if your domain is registered in one place but hosted in another, the records belong wherever your nameservers point (the hosting side, from lesson 3). Screenshot both your Resend records page and your DNS panel, show them to Claude, and it will spot the mismatch.

📥 Your first sends may land in Promotions or spam. Expect it.

A brand-new sending domain has no reputation yet. Gmail and Outlook build trust by watching real mail from your domain over the first days and weeks, so early sends can land in Promotions or spam even with all three records green. It settles on its own. Send a small, steady trickle to real people rather than a big blast on day one, and when a test lands in spam, drag it to the inbox and reply to it: both teach the filter. Still landing in spam after a few weeks of steady sending? That is the moment to dig deeper, with the DMARC deep-dive below.

Watch: Tiny servers that wake up (0:52)

🔧 If a deploy fails

You will know it worked when each function reports "Deployed" and shows up under Edge Functions in your Supabase dashboard. A 401 or "not linked" error means you are not logged in to the Supabase CLI or the project link dropped: tell Claude "run supabase login and link my project again", then deploy once more. Any other error, paste it to Claude as-is; a failed deploy changes nothing until it succeeds, so nothing is broken while you sort it out.

The 14 migrations: what each one sets up

A migration is one small file that creates or changes a table in your database. Your pack ships fourteen, and Claude applies them for you in order. You do not edit them by hand; this is just so you know what your back end holds.

Watch: The quiz email that never sent (1:26)

Also in your pack: four skills that keep the whole thing healthy

Setup is not the whole job. Four more skills ship in this pack to keep what you built healthy. Run /automation-health on day one, because it is what switches your daily check on. The other three you run when you want a look.

Test mode now, real money after verification

You can build and test the whole flow today in Stripe's test mode, no waiting. But before you can receive real payments, Stripe has to verify your business: a bank account and an ID check. That can take a day or two to clear. If you plan to launch soon, start the verification early so it is done by the time you flip to live mode.

🔧 If the test purchase does not land

You will know it worked when three things are true: the attempt shows a green Succeeded under Stripe, Webhooks, your endpoint, recent attempts; a row appeared in your stripe_payments table in Supabase; and the welcome email arrived. If the money moved but nothing else happened, it is the webhook, not the payment: open that same recent-attempts list and read the response. A 401 there means your function is not receiving Stripe's signature secret, which is the most common cause and is a secrets fix, not a code fix. Paste the response body to Claude as-is. Nobody else can buy from you while you sort this out, so nothing is at risk except the test you just ran, and you can rerun it as many times as you like.

Notion: from the terminal

You add Notion where you already work, by asking Claude. Say "connect my Notion" and it walks you through signing in and approving access. That is the whole setup.

Gmail, Calendar, Drive: from your Claude account

Because of the way Google sign-in works, these three are switched on in your Claude account settings, not in the terminal. You open your connectors settings in your Claude account, turn on the Google connectors you want, and sign in once. From then on they are available to Claude wherever you work, including in your system. Ask Claude and it will point you to the exact settings page for your plan.

🔧 If a connector says it is on but Claude cannot see anything

You will know it worked when you ask Claude something only that app knows, like "what is on my calendar tomorrow", and it answers with your real events rather than offering to help you set one up. If the toggle is on and Claude still comes back empty, it is almost always the account: the Google connector is tied to the account you signed in with, so if you have a personal address and a work one, turn it on again while signed in as the address that holds the calendar you meant. Start a fresh conversation afterwards, because a conversation that began before the connector existed will not pick it up mid-way. Nothing in your system changes when you connect or disconnect an app, so you can switch one off and back on as many times as you need.

Connect only what you use

A connector is real access to a real account. Turning one on lets Claude read and act inside that app. That is the point, and it is also the reason to be deliberate: wire the apps you actually want Claude working in, skip the rest, and you can always add more later. You are not locking anything in.

Paste to your Claude

Make me a /monday-prep skill. When I run it, read my Notion meeting notes and my Google Calendar for the past week and the week ahead, then give me one short page: what I promised people and have not closed, who is waiting on a reply, and the three heaviest days coming up. Keep it to one screen. Write the skill file, then run it once so I can see it work.

A few starters worth building

/inbox-brief reads your Gmail from the last day and hands you a one-page summary: who is waiting, what is just noise, what needs you today.

/week-ahead reads your Calendar and tells you where the free mornings are before you say yes to anything.

/note-it takes a thought and files it into the right Notion database with today's date, so ideas land in one place instead of scattering.

The honest part, first

Claude sitting in a chat with you cannot wake itself up. It does nothing between your messages, and it forgets a session once it ends. So it cannot quietly remember to do something for you tomorrow. Anything that runs on a schedule is a separate mechanism, on a real timer, that starts up a fresh Claude at the chosen time. When you set one up, you are arming that timer, not asking Claude to remember.

Keep that test in your pocket: if the honest answer to "will this happen on its own?" is "only if I open the terminal," it is not set up yet.

1. While you are working: a timer on your machine

Ask Claude "remind me at 6pm to wrap up" or "every hour, check my inbox and tell me if anything urgent came in." It sets a timer that fires on your own computer and pops up a notification.

The catch: it only fires while Claude Code is open on your machine. Close the laptop and nothing happens. These timers also clear themselves after about a week, so they suit today and this week, not standing jobs.

2. Even when your laptop is closed: a cloud routine

Anthropic can run a scheduled Claude on its own servers. You save a routine (a prompt plus a time), and at that time a fresh Claude spins up in the cloud, does the work through the connectors you wired in the first lesson, and reports back in your Claude app. This runs whether your computer is on or off, which makes it a fit for a morning inbox summary or a Monday calendar brief.

The catch: the cloud Claude has no reach into the files on your laptop. It only knows what your connectors give it. So it is made for inbox and calendar work, not for anything that needs your local system.

Set up your first one

Start with something small and genuinely useful, like a morning inbox brief:

"Set up a routine that reads my inbox and calendar every morning at 8am and gives me a short brief: who is waiting on me, and the shape of my day. Tell me exactly where it will run and where the result lands, then set it up with me."

One honest limit of your path

A cloud routine reports back inside your Claude app, not as an email in your normal inbox. If you want a brief built from your own business data and delivered as a proper email that lands whether or not you ever open Claude, that needs the storefront pieces: a database and a server-side timer. That is the other path, and you can pull it in later if you ever want it. For now, the two routines above are yours with no infrastructure to maintain.

That is your path, wired ✨

Connectors into the apps you live in, skills for the questions you ask every week, and a routine or two that run without you. No database to maintain, no infrastructure to watch. Your daily work, handled, living where you already live.