Vibe Coding a Newsletter System: How I Replaced $500/Month SaaS with Three Nights of TV and AI

Mission Command Development Case Study #1

Last week, I was browsing Twitter during a Netflix break when I realized something ridiculous: I was paying Substack $50/month, ConvertKit another $79/month, and had Mailchimp on standby for $39/month. Nearly $170/month for what amounts to collecting emails and sending newsletters.

"How hard could it be to build this myself?" I thought, grabbing my laptop without pausing The Bear.

Four nights later, I had a complete newsletter system. Email collection with modal name capture, admin dashboard, AI-powered content generation, Resend integration for delivery, audience management, unsubscribe handling, enterprise-grade CSV migration with real-time debugging, and Safari authentication fixes that would make any enterprise dev proud.

Total cost: $0/month (plus whatever I'm already paying for Supabase and Vercel).

This is Mission Command Development in action — one senior dev directing AI agents to replace entire SaaS products while half-watching TV. Let me walk you through exactly how it happened.

Night One: "Can Claude Just... Build This?"

I opened Claude Code with the simplest possible prompt: "I want to add a newsletter signup to my Next.js blog with a Supabase backend."

What followed was fascinating. Claude didn't just write a form component. It:

Analyzed my existing codebase structure
Created a proper database schema with subscribers table
Built shadcn/ui components that matched my design system
Set up the API routes with proper error handling
Added TypeScript interfaces for everything

First issue: "Failed to subscribe" errors in the footer form.

My question: "I entered my email - no modal with name and a msg - Failed to subscribe"

The fix: Claude immediately spotted that the subscribe API was using the wrong Supabase client (client-side instead of server-side). One import change, and we were live.

The whole thing took about 45 minutes, including debugging. I barely missed any of the episode.

Night Two: "Wait, This Needs to Actually Send Emails"

The next evening, I was watching Ted Lasso reruns when I realized my newsletter system was just collecting emails into a void. Time to integrate actual email delivery.

My question: "ok - lets add resend integration noe" (yes, I misspelled "now" — Claude still knew what I meant)

Claude immediately:

Added Resend SDK to the project
Created email templates with proper HTML/CSS
Built a newsletter generation system using OpenAI
Set up an admin dashboard with send functionality
Added test email capabilities

Issue #1: GPT-5 API errors.

Claude tried to use GPT-5, but we hit rate limits and parameter issues. Without me having to research anything, Claude switched to GPT-4o and adjusted the parameters.

Issue #2: Safari authentication problems.

My question: "safari stuck loading now"

This was the most interesting debugging session. Claude identified that Safari's strict cookie policies were breaking the client-side auth provider, even though server-side authentication was working fine. The solution? Remove client-side auth checks since the middleware was already protecting routes server-side.

Issue #3: Domain verification errors.

When we first tried sending emails, Resend threw a 403 error: "The benenewton.com domain is not verified."

Instead of making me dig through Resend docs, Claude immediately suggested using the sandbox domain for testing, then guided me to verify my custom domain. Once I had news.benenewton.com verified, Claude updated all the email templates automatically.

Total dev time: Maybe 90 minutes across two Ted Lasso episodes.

Night Three: "This Needs to Be Production-Ready"

By the third night (House of the Dragon was on), I wanted to polish this into something I'd actually use in production.

My question: "i also think we shoud be sending the subscribe data to resend"

Claude immediately understood I wanted two-way sync between my database and Resend's audience management. It built:

Contact creation in Resend audiences
Name updates that sync to both systems
Unsubscribe handling that removes from both
A complete unsubscribe page with resubscribe options

Issue #4: API key permissions.

When we tried syncing to Resend audiences, we got: "This API key is restricted to only send emails."

Claude diagnosed this instantly and walked me through creating a full-access API key. Problem solved in 30 seconds.

My question: "don't we need an unsubscribe page? Or is that handled by resend? if so, do we need a webhook to update our db table when someone unsubscribes?"

This question led to the most sophisticated part of the build. Claude built a complete unsubscribe system:

Custom unsubscribe page with proper branding
Token-based verification using subscriber IDs
State management for already-unsubscribed users
Resubscribe functionality
Full CAN-SPAM compliance

The entire unsubscribe flow was built in about 20 minutes.

Night Four: "I Need to Migrate from Buttondown"

A few weeks later (Kandahar was on Netflix), I realized I had 50+ subscribers trapped in my old Buttondown account. Time to build a migration system.

My question: "I need to migrate subscribers from buttondown - they export csv files"

What followed was the most detailed engineering session yet. Claude built a complete enterprise-grade migration system:

The CSV Upload Interface:

File validation and parsing
Progress indicators during uploads
Error handling for malformed data
Sample file format guidance

The Migration API:

Rate-limited email sending (learned this the hard way when we hit Resend's 2-emails-per-second limit)
Database transactions with rollback capabilities
Duplicate detection and handling
Comprehensive error logging

The Re-opt-in Flow:

Custom migration confirmation emails with branded headers
Different email templates for migrations vs. new signups
Token-based verification system
Proper unsubscribe links using subscriber IDs instead of verification tokens

Issue #5: Rate limiting disasters.

First migration attempt: "3 subscribers imported, 2 emails sent." Claude immediately diagnosed this as a Resend rate limit issue (429 error) and increased the delay between emails from 100ms to 600ms.

Issue #6: The unsubscribe link nightmare.

Migration emails were generating unsubscribe links with verification tokens, but the unsubscribe endpoint expected subscriber IDs. Users clicking unsubscribe got error pages.

The debugging process was fascinating. Instead of guessing, Claude had me add comprehensive logging to the production API:

console.log('=== UNSUBSCRIBE API CALLED ===')
console.log('Token received:', token)
console.log('Search by ID result:', { subscriberById, findByIdError })

The Vercel logs revealed the exact issue: "Could not find the 'unsubscribed_at' column of 'subscribers' in the schema cache" - we were trying to update a database column that didn't exist.

Claude's solution was elegant:

Updated the migration email template to use proper subscriber IDs
Added backwards compatibility to handle old verification tokens
Fixed the database schema mismatch (changed unsubscribed_at to updated_at)
Created proper branded unsubscribe success/error pages
Fixed the email template to include my site logo and branding

My question: "I clicked on the confirm link, but nobody was added to the audience in resend"

This led to discovering that the verification flow was silently failing to sync with Resend. Claude added detailed logging and made the sync process more robust.

Issue #7: Real-time production debugging.

When the unsubscribe links still weren't working after deployment, Claude guided me through a systematic debugging approach:

Add comprehensive logging to the production API
Deploy immediately and test with real user traffic
Check Vercel function logs in real-time
Identify the exact error from the server logs
Fix the root cause (database schema mismatch)
Deploy the fix and verify resolution

The entire debug cycle took about 15 minutes from "still broken" to "working perfectly." This is enterprise-level debugging practices applied to a casual side project.

The level of detail was incredible:

Email templates with proper HTML tables for email client compatibility
Branded headers with my avatar and site link
Different color schemes for verification vs. migration emails
Comprehensive error handling at every step
Production-ready logging for debugging
Real-time debugging with live traffic

Total time: About 2 hours while watching Kandahar. The result? A migration system that would cost thousands to have built professionally, with error handling that rivals enterprise software.

The Final Product

After four casual coding sessions, I had:

Frontend:

Compact footer newsletter signup
Modal for optional name collection
Admin dashboard with stats and management
Newsletter editor with AI content generation
Unsubscribe and preferences pages
CSV upload interface for migrations
Branded email templates with logo integration

Backend:

Secure Supabase integration
Resend email delivery with rate limiting
Two-way audience sync
Admin authentication with middleware protection
Complete API for CRUD operations
Enterprise-grade migration system
Token-based verification with backwards compatibility

Features that would cost hundreds in SaaS:

AI-powered newsletter generation
Audience segmentation ready
Email deliverability through Resend
Custom branding throughout
Complete admin control
CSV migration with re-opt-in flow
Professional email templates
Comprehensive error handling and logging

The Broader Point

This isn't really about newsletters. It's about what becomes possible when you combine:

Senior dev intuition (knowing what questions to ask)
AI agents that understand context (Claude analyzing my existing codebase)
Modern infrastructure (Supabase, Resend, Vercel that AI can configure directly)

I wasn't writing boilerplate code or reading documentation. I was having a conversation about what I wanted to build, and Claude was handling the implementation details.

The questions I asked weren't technical specifications — they were product decisions:

"This needs to actually send emails"
"The form is too big for the footer"
"Don't we need an unsubscribe page?"

Claude translated those into architecture decisions, code implementation, and infrastructure setup.

Mission Command Development in Practice

This is exactly what I mean by Mission Command Development. I wasn't managing a team of specialists — I was directing an AI agent that could handle:

Frontend development (React components, UI/UX)
Backend engineering (API routes, database design)
DevOps (deployment, environment configuration)
Email infrastructure (deliverability, compliance)
Product thinking (user flows, edge cases)

The total "team cost" for this project: $0/month ongoing, plus my existing infrastructure.

A traditional approach would have meant:

$170/month for email tools
Hours of integration work
Multiple service dashboards to manage
Limited customization options

What This Means for You

If you're a senior developer, this model is already available to you right now. The tools exist, the integrations work, and the AI agents are sophisticated enough to handle real production code.

The question isn't whether this will replace traditional development workflows — it's how quickly you'll adapt to it.

Companies still hiring 10-person teams to build what one senior dev + AI can ship in a week will find themselves massively outpaced by competitors who embrace Mission Command Development.

For solo developers and small teams: You can now compete with much larger organizations by leveraging AI to handle the specialist work you can't afford to hire for.

For larger organizations: The teams that learn to work alongside AI agents will ship features exponentially faster than those that resist the change.

What's Next

I'm planning to open-source this newsletter system as a template for other developers who want to ditch expensive SaaS tools. But more importantly, I want to document more of these "vibe coding" sessions where complex systems get built casually.

Next up: Building a customer support system to replace Intercom ($99/month), then maybe a analytics dashboard to replace Mixpanel ($89/month).

The pattern is always the same: identify an expensive SaaS tool, spend a few casual evening sessions with Claude, end up with something more customized and $0/month ongoing cost.

Want to follow along with more Mission Command Development experiments? Subscribe to my newsletter (built with the system described in this post) for detailed walkthroughs and real-world case studies.

P.S. — Yes, I'm writing this blog post using Claude too. The irony is not lost on me.

Vibe Coding a Newsletter System: How I Replaced $500/Month SaaS with Four Nights of TV and AI