Which Plan To Get?
TLDR: Claude Max - Will get you access to Opus
- Max 5x Pro ($100/month): Average users can send approximately 225 messages with Claude every 5 hours, OR send approximately 50-200 prompts with Claude Code every 5 hours.
- Max 20x Pro ($200/month): Average users can send approximately 900 messages with Claude every 5 hours, OR send approximately 200-800 prompts with Claude Code every 5 hours.
- Model access: Max plan subscribers can use Sonnet or Opus 4 on Claude Code (switch between them using the
/modelcommand).
Claude Code automatically switches from Opus 4 to Sonnet 4 when Max users reach certain usage thresholds:
- Max 5x plan: Switches at 20% of your rate limit
- Max 20x plan: Switches at 50% of your rate limit
Rate limits reset every 5 hours, and this switching happens based purely on usage regardless of time.
Model Selection
The default model selection works well for the Max plan where you get to use Opus until you reach 20% of your limit and it’ll switch to Claude Sonnet.
I’m experimenting but find I like to select the model with
/model then use Opus for planning. When I am done planning I flip it back to Sonnet to let it rip on the plan.Planning Mode
This will help you get the most out of Claude Code and I recommend you start here.
Enable this with the following key commands two times:
shift + tab
Once you have enabled this you just let it rip by giving it all that you want to accomplish. I find that I can throw the “kitchen sink” at it and it is really good at trying to figure out what my intent is and Opus is really great and sorting this out for coding tasks. It is basically a light and organized version of a PRD.
Think Harder
Use the following in your prompt to give Claude super powers! Basically gives it more computation time to help you cook.
- "think"
- "think hard"
- "think harder"
- "ultrathink”
If the results of this step seem reasonable, you can have Claude create a document. I like to tell it to add a markdown file to /documentation/plans folder and I use that to bang out my features. When you are done shipping a feature be sure to tell Claude Code to update this file so you can stay on track.
Rejecting Plans
I’d highly recommend you read and understand the plan before you YOLO for the sake of building great quality products. I frequently reject plans and make sure I get all of the details correct before moving forward with building features.
Escape key is your friend
If you see it generating a plan you don’t like or you see it going down a rabbit hole you need to hit Escape ASAP! From there you can provide context and then hit enter to let it continue.
This is probably the biggest productivity hack that sets it apart from the other providers.
Compact
After you shipped a quick feature you’ll want to compress the chat if you still have a ways to go with your long plan.
My favorite thing to do is to give it instructions on what we want to do next so we setup the agent to not only summarize what we’ve worked on but think about the next logical steps. Here is my example:
/compact be sure to keep details on what we did with this session as we are planning to do an audit of the loops flows
@ files
I find that you can do targeted fixes by using the @ and then type in part of a file name and hit tab or enter to select the file. You can hit the down arrow to select the file from the command line and it’ll auto-complete the file name. I do this when I know exactly what I want to fix and skip the planning part. It’ll generate its own plan and execute the task for you.
Web Access
In your prompt you can just tell it to use the web to do research. It is even more helpful to give it urls for documentation you want it to read.
Example Plan
After going back and forth you start to shape out a really thoughtful plan that is very personalized for your codebase. This is your foundation for shipping high quality features and letting Claude Code go through with the Sonnet model. I find it can one shot the entire thing without linting errors. If you are getting lots of linting errors you can ask the model to help you setup rules in your CLAUDE.md file.
Prompts
> /compact be sure to keep details on what we did with this session as we are planning to do an audit of the loops flows ⎿ Compacted. ctrl+r to see full summary > continue with the next logical steps for the loops flows as I want to make sure they work correctly. Please use the web to look up documentation for loops.so
Interruption
> oh I forgot to mention that I have Clerk for authetnication, Convex, http webhooks in Convex but We are using loops.so so we can keep the webhooks and code low and rely on loops.so to handle a lot of things since it is an easy to use dashboard. I believe they have stripe integration as well so leveraging that platform as much as possible. Please continue with your web research and the next logical tasks. ⏺ Perfect! That context is very helpful. You're using Loops.so as your primary email marketing platform to keep webhooks minimal and leverage their dashboard + Stripe integration. Let me continue researching Loops.so's Stripe integration and API capabilities.
Plan v1 (rejected)
Based on my research and audit of your Loops implementation, here's what I found and the next steps: 🔍 Loops Integration Audit Results ✅ What You Have Implemented Well: 1. Complete API Integration: Your SDK implementation in /convex/loops/sdk.ts correctly uses the Loops API with proper endpoints 2. Proper Authentication: Using Bearer token auth with environment variable 3. Comprehensive Contact Management: upsertContact function matches Loops' updateContact API (create or update) 4. Event Tracking: pushEvent for behavioral triggers 5. Transactional Emails: Infrastructure ready for welcome emails, receipts, etc. 6. Async Processing: Using Convex scheduler to avoid blocking operations ⚠️ Critical Issues Found: 1. Template IDs Not Configured: All transactional email templates use placeholder IDs like 'welcome_email_id' 2. Missing Loops Direct Integration: You're manually syncing via API instead of leveraging Loops' native Stripe + Clerk webhook integrations 3. Redundant Architecture: You could simplify by using Loops' built-in integrations 🎯 Recommended Next Steps: Option A: Keep Current API-Based Approach (Recommended for Control) - Update all template IDs with real Loops template IDs - Test all contact sync flows - Add error handling and retry logic Option B: Leverage Loops Native Integrations (Recommended for Simplicity) - Set up Loops' native Stripe webhook integration - Set up Loops' native Clerk webhook integration - Reduce your custom code significantly Let me help you choose and implement the best path. Which approach would you prefer? ⏺ Update Todos ⎿ ☒ Audit Loops.so integration completeness and flow correctness ☐ Verify Loops API endpoints and response handling ☐ Check Loops transactional email template IDs are configured ☐ Decision: Choose between API-based vs Native Loops integrations ☐ Review Stripe webhook to Loops integration points ☐ Test Loops contact sync and event tracking flows ⏺ Would you like me to: 1. Audit your current template IDs and help you configure them properly? 2. Research setting up native Loops integrations to simplify your architecture? 3. Test your current flows to identify any bugs? Next immediate action needed: Check your Loops dashboard for actual template IDs and either update the placeholders or set up the native integrations.
Planning Prompt for v2
> ahh I knew I was missing something. I just went to their site and will need to setup these integrations. Let me enable them right now and give you the info so you can put it together. First for Clerk, I'm following the guide here: https://loops.so/docs/integrations/clerk https://clerk.com/docs/webhooks/overview https://clerk.com/docs/webhooks/sync-data https://loops.so/docs/integrations/incoming-webhooks 1. Okay, I've now enabled Clerk webhook in loops.so and configured the webhook url in Clerk for loops. I was able to send a test webhook from Clerk and I see [email protected] and the other info in loops.so along with a slack notification that someone just joined. YAY! I'm using this webhook from loops: https://app.loops.so/api/v1[redacted] 2. Now I am going to setup the stripe integration with loops.so. Remember I'm trying to keep my code simple and this loops.so, clerk, and stripe workflow with loops seems promising given the integrations. by the way loops gives me webhook urls like this for stripe https://app.loops.so/api/v1/webh[redacted] here are the stripe integration docs: https://loops.so/docs/integrations/stripe Good news! I got this working and I'm now using the loops webhook here as well. Created a new customer on stripe and saw it hit the webhook and added the customer in loops.so. So now that I've got this going we'll need to do a full code review to prune things and keep things DRY. In additon we need to stest the Clerk flows as well. Here are some intial tests that we should work through but you need to review and add more: 1. New user will click a plan from my frontend app www.raytranscribes.com which will lead them to app.raytranscribes.com/checkout with a corresponding ?plan=${plan}&billing=monthly They will create a clerk account so we have this in our database and so we can eventually sync this with their stripe account. As of now stripe has two webhooks one to send to Convex and another to send to loops.so. I want to keep this as easy to maintain as possilbe. I think we have already done a really robust job with hooking this up with Convex https webhook along with Clerk and Stripe. If you feel that loops.so offers something better than what we have I'm open to discussing the pros and cons. I am sort of leaning to our existing Convex flow since we've already built that out but will need to identify what loops configuration may offer us. I can always disable the loops to stripe webhook as it is one toggle. My thinking is if we can get the source of truth from Clerk for the email that was used to sign up we should already have enough to go off of to send the customers email about various things. Will be intersted to know about nudges, emails for transactional things like payments failing and what the workflows will be with that. 2. We should walk through the trial period app creation. So a user will get a link and start a trial on a given plan. Their email and plan, etc. should be in Convex (which we know it is) and have details in loops.so so we can send emails to them when their trial is almost up, hit threshold limits, and encourage them to upgrade. 3. We should go through workflows where we have existing customers and they upgrade, downgrade, cancel, etc. ⎿ ⧉ Selected 1 lines from app/checkout/page.tsx in Cursor
Plan v2 (rejected)
⏺ 📊 Architecture Analysis: Current State You now have dual webhook flows which creates both opportunities and potential conflicts: Current Webhook Flows: Clerk → Loops (native) ← NEW Clerk → Convex → Loops ← EXISTING Stripe → Loops (native) ← NEW Stripe → Convex → Loops ← EXISTING 🎯 Recommended Hybrid Strategy After analyzing your setup, I recommend a selective hybrid approach that leverages the best of both: Keep Native Integrations For: - Clerk → Loops: User creation/updates (simpler, automatic) - Basic Stripe Events: Customer creation, subscription status changes Keep Convex → Loops For: - Custom Events: Transcription completions, usage milestones, app-specific behaviors - Transactional Emails: Payment receipts, trial notifications, usage warnings - Business Logic: Trial management, usage limit calculations 📋 Comprehensive Test Plan & Code Review ⎿ User rejected Claude's plan: 🔄 Loops Integration Optimization Plan │ │ │ │ Phase 1: Code Cleanup & Architecture Decision (30 mins) │ │ │ │ 1. Remove redundant Loops API calls from Stripe webhooks (since native integration handles this) │ │ 2. Keep Clerk → Convex flow for database management, disable redundant Loops calls │ │ 3. Preserve custom event tracking for app-specific behaviors (transcriptions, usage milestones) │ │ 4. Update transactional email template IDs with real Loops template IDs │ │ │ │ Phase 2: Test Scenario Implementation (45 mins) │ │ │ │ 1. Test Scenario 1: New User Signup Flow │ │ - User visits /checkout?plan=starter&billing=monthly │ │ - Creates Clerk account → Auto-syncs to Loops (native) │ │ - Creates Convex user record → Business logic preserved │ │ - Completes Stripe checkout → Both webhooks fire │ │ - Verify no duplicate contacts in Loops │ │ 2. Test Scenario 2: Trial Period Workflow │ │ - Trial invite redemption flow │ │ - Usage tracking and limit notifications │ │ - Trial expiration warnings (custom Loops emails) │ │ - Upgrade prompts and conversion tracking │ │ 3. Test Scenario 3: Customer Lifecycle Management │ │ - Plan upgrades/downgrades via checkout toggle │ │ - Subscription cancellations │ │ - Payment failures and retry sequences │ │ - Billing portal integration │ │ │ │ Phase 3: Optimization & Verification (15 mins) │ │ │ │ 1. Configure Loops email templates for transactional messages │ │ 2. Test webhook delivery and contact synchronization │ │ 3. Verify event tracking for custom app behaviors │ │ 4. Document final architecture and webhook flows │ │ │ │ Expected Outcome: │ │ │ │ - Simplified, maintainable codebase leveraging native integrations │ │ - Robust custom event tracking for business-specific workflows │ │ - Comprehensive email automation without code duplication │ │ - Verified end-to-end user journey flows
Planning Prompt for v3
all emails will be sent using loops.so so I need you to review again and do some web research with the loop.so docs to cross reference and check your work before you make logical decisions.
Plan v3 (rejected)
⏺ Perfect! Now I have a comprehensive understanding of Loops.so capabilities. Let me analyze what can be handled by Loops native integrations vs what needs custom code. 📊 Comprehensive Loops.so Capability Analysis What Loops.so CAN Handle Natively: ✅ Clerk Integration: - User creation/updates automatically sync to Loops - Welcome email sequences triggered by user.created events - Contact properties automatically updated - Trial invite users automatically added to audience ✅ Stripe Integration: - Subscription lifecycle events (customer.created, subscription.updated, invoice.payment_failed) - Payment failure retry sequences with intelligent timing - Subscription status changes sync automatically - Customer data sync with email matching ✅ Email Automation Workflows: - Event-triggered email sequences (trial expiring, payment failed) - Branch logic for complex workflows based on contact properties - Subscription status-based segmentation - Payment retry sequences with attempt tracking What Requires Custom Convex Code: 🔧 App-Specific Events: - Transcription completion tracking - Usage milestone notifications - File processing events - Custom business logic calculations 🔧 Database Operations: - User record creation in Convex - Usage tracking and limit enforcement - Trial invite code management - Transcription job tracking 🎯 Optimized Architecture Recommendation ⎿ User rejected Claude's plan: ╭─────────────────────────────────────────────────────────────────────────────────────────────────────╮ │ 🔄 Loops Integration Optimization Plan │ │ │ │ DECISION: Leverage native Loops integrations for ALL email workflows, eliminate redundant API calls │ │ │ │ Phase 1: Architecture Cleanup (45 mins) │ │ │ │ 1. Remove Redundant Loops API Calls from Stripe Webhooks │ │ - Keep Stripe → Convex webhooks for database updates │ │ - Remove all internal.loops.sdk.upsertContact calls from stripe.ts │ │ - Let native Stripe → Loops webhook handle all email automation │ │ 2. Simplify Clerk User Creation │ │ - Keep Convex user creation for database needs │ │ - Remove Loops API calls from user registration │ │ - Let native Clerk → Loops webhook handle contact creation │ │ 3. Preserve Custom Event Tracking Only │ │ - Keep transcription completion events │ │ - Keep usage milestone tracking │ │ - Keep app-specific business events │ │ - Remove subscription status updates (handled natively) │ │ │ │ Phase 2: Loops Dashboard Configuration (30 mins) │ │ │ │ 1. Set Up Email Templates in Loops │ │ - Welcome sequence for new users (triggered by Clerk webhook) │ │ - Trial expiration warnings (triggered by custom events) │ │ - Payment failure recovery sequence (triggered by Stripe webhook) │ │ - Subscription change confirmations (triggered by Stripe webhook) │ │ 2. Configure Workflow Automations │ │ - Trial user upgrade prompts based on usage thresholds │ │ - Payment retry sequences with intelligent timing │ │ - Subscription lifecycle email flows │ │ │ │ Phase 3: Test Scenarios (45 mins) │ │ │ │ 1. Test End-to-End User Journey │ │ - New user signup → Clerk webhook → Loops welcome sequence │ │ - Stripe checkout → Subscription webhook → Loops confirmation │ │ - Trial expiration → Custom event → Loops upgrade prompt │ │ 2. Test Subscription Lifecycle │ │ - Plan upgrades/downgrades → Stripe webhook → Loops notification │ │ - Payment failures → Stripe webhook → Loops retry sequence │ │ - Cancellations → Stripe webhook → Loops retention campaign │ │ 3. Test Custom App Events │ │ - Transcription completion → Custom event → Loops celebration │ │ - Usage milestones → Custom event → Loops engagement │ │ - Trial limits → Custom event → Loops upgrade prompt │ │ │ │ Expected Outcome: │ │ │ │ - 90% reduction in custom email code │ │ - Native webhook reliability for all subscription emails │ │ - Preserved custom tracking for app-specific behaviors │ │ - Simplified maintenance with Loops dashboard management │ │ - Professional email sequences without coding overhead │ │ │ │ Files to Modify: │ │ - /convex/stripe.ts - Remove Loops API calls │ │ - /convex/loops/contact.ts - Remove user registration calls │ │ - /convex/loops/transactional.ts - Update template IDs, keep custom events only
Planning Prompt for v4
this plan doesn't make sense because we built a lot of features to listen to stripe and react in our app with convex including clerk. loops.so would just help me out with automating the email flows. We are trying to be surgical here.
Plan 4 (approved)
⏺ You're absolutely right! I was overcomplicating things. Let me create a surgical plan that keeps your existing Convex infrastructure intact and uses Loops.so ONLY for email automation. 🎯 Surgical Approach: Keep Convex as Source of Truth Your architecture makes perfect sense: - Convex = Source of truth for all business logic, user data, subscription management - Loops.so = Email automation platform that reacts to your Convex data Let me create a focused plan: ⏺ User approved Claude's plan: ⎿ 🔧 Surgical Loops Integration Plan CORE PRINCIPLE: Convex remains the source of truth. Loops.so is ONLY for email automation. Phase 1: Identify & Fix Redundant Loops Calls (20 mins) 1. Keep ALL Convex Webhook Handlers Intact - Stripe → Convex webhooks stay as-is (subscription management) - Clerk → Convex user creation stays as-is - All business logic remains in Convex 2. Remove Only Duplicate Contact Creation - Since Clerk → Loops and Stripe → Loops webhooks are now active - Remove upsertContact calls that duplicate what webhooks already do - Keep custom event tracking for app-specific behaviors 3. Update Transactional Email Template IDs - Get real template IDs from Loops dashboard - Update placeholder IDs in /convex/loops/transactional.ts Phase 2: Configure Email Triggers (15 mins) 1. Leverage Native Integrations for Basic Contact Sync - Clerk webhook creates/updates contacts in Loops - Stripe webhook updates subscription status in Loops - No code changes needed - already configured 2. Use Custom Events for Business Logic - Transcription completed → Send usage summary - Trial limit approaching → Send upgrade prompt - Usage milestone reached → Send celebration email Phase 3: Test Critical User Flows (25 mins) 1. New User Signup Flow - User signs up → Clerk creates Convex user - Clerk webhook → Creates Loops contact - Convex can trigger welcome events if needed 2. Subscription Purchase Flow - User completes Stripe checkout - Stripe → Convex updates subscription (business logic) - Stripe → Loops updates contact (email automation) 3. Custom App Events - User completes transcription → Convex tracks usage - Convex sends custom event to Loops → Triggers email Minimal Code Changes Needed: 1. Remove duplicate upsertContact calls where native webhooks handle it 2. Keep all custom event tracking for app-specific behaviors 3. Update template IDs with real values from Loops dashboard 4. Test webhook flows to ensure no duplicate contacts Result: Your robust Convex architecture stays intact, Loops handles email automation, minimal code changes.
We Cooked
If you’ve made it this far and you’ve found this helpful please share this with a friend.
Subscribe to my YouTube channel for my upcoming summer of streaming where I’ll be livestreaming every day until I get to 100k subs. https://www.youtube.com/@rayfernando1337
Don’t miss out as it starts July 1st and you’re always welcome to join the stream and ask me questions.