DEV Community: Frank Mendez

🚀 Building a Newsletter Subscription Feature That Actually Works (No BS Edition)

Frank Mendez — Tue, 21 Apr 2026 09:14:33 +0000

The Problem With Most “Newsletter Features”

Let’s be honest—most newsletter setups are either:

Overkill (hello 20-step Mailchimp workflows)
Manual (someone forgets to hit “send”)
Or duct-taped together like a weekend hackathon project

What we actually want is simple:

User subscribes → You publish → Email goes out automatically

That’s it. No ceremony.

🧠 The Approach: Keep It Lean

This feature was built into a Blog CMS with a few strict rules:

No new vendors (use existing stack)
No double opt-in friction
Fully automated sending
One-click unsubscribe (because lawsuits are expensive 😅)

👉 Full design spec:

⚙️ Core Architecture

Instead of relying on external newsletter platforms, this setup runs fully in-house:

Database: Supabase
Email: Resend
Scheduler: Vercel Cron
Frontend: Next.js

Flow (a.k.a. “what actually happens”)

User enters email → stored in DB
Admin publishes a post
System schedules a send (with delay)
Cron job runs every minute
Emails are sent automatically
User can unsubscribe with one click

No dashboards. No manual triggers. No “oops we forgot to send.”

🗄️ Data Model (Simple but Powerful)

Two tables. That’s it.

1. `newsletter_subscriptions`

Tracks subscribers:

email (unique)
subscribed_at
unsubscribed_at (null = active)
unsubscribe_token (for one-click unsubscribe)

2. `newsletter_sends`

Acts like a queue:

post_id (1 send per post)
scheduled_at
status (pending → sending → sent/failed)

This separation is key. It lets you:

Schedule emails
Retry failures
Track delivery

⏱️ The Secret Sauce: Delayed Sending

Instead of blasting emails immediately:

NEWSLETTER_DELAY_MINUTES=60

Why this matters:

Gives you time to fix mistakes after publishing
Avoids “oops typo in production” emails
Feels more intentional

🔁 Automation via Cron

A Vercel cron job runs every minute:

* * * * * → /api/newsletter/cron

It checks:

Any pending sends?
Is scheduled_at <= now()?

If yes:

Mark as sending
Fetch active subscribers
Send emails
Update status

If something crashes midway?

👉 Anything stuck in sending for 10+ minutes is marked as failed

No silent failures. No ghost jobs.

✉️ Subscription Experience (UX Matters)

The Subscribe Form

Placed at the bottom of every blog post:

Email input
Subscribe button
Instant feedback (success or error)

No confirmation email. No friction.

Because let’s be real—every extra step kills conversions.

❌ Unsubscribe (Don’t Mess This Up)

Every email includes:

/api/newsletter/unsubscribe?token=xxx

Click → done.

No login. No “are you sure?” guilt trips.

Just clean, respectful UX.

🛡️ Edge Cases You’ll Actually Hit

Handled upfront:

Scenario	Result
Duplicate email	“Already subscribed”
Re-subscribe	Reactivates user
Invalid token	404
No subscribers	Send marked as complete
Cron crash	Auto-mark failed

This is where most systems break. Don’t skip it.

🧪 Testing Strategy

Because “it works on my machine” isn’t a strategy:

Unit tests: subscribe/unsubscribe logic
Integration tests: cron + email dispatch
E2E tests: full user flow

Yes, even for a “simple” feature.

💡 Why This Approach Wins

Let’s compare:

Approach	Reality
Mailchimp	Expensive + overkill
Manual send	Someone forgets
Zapier hacks	Fragile
This system	Clean, automatic, predictable

You control everything. No black boxes.

🧠 Final Thoughts

This isn’t just a newsletter feature—it’s an event-driven system disguised as one.

Publish event → triggers queue
Queue → processed by cron
State machine → tracks delivery

It’s simple on the surface, but solid under the hood.

And that’s the sweet spot.

🔥 If You’re Building Something Similar…

Start here:

Keep your data model clean
Automate everything
Design for failure (because it will happen)
Avoid adding tools just because they exist

🏁 TL;DR

If your newsletter requires manual effort, it’s broken.

Automate it. Keep it lean. Ship it.

Notifying Admins When Users Confirm Their Email — The Right Way with Supabase and Next.js"

Frank Mendez — Thu, 16 Apr 2026 10:12:24 +0000

Full blog => here
Steps (Article Sections)

Hook / Problem Statement — Why polling or signup-time notifications are wrong; email confirmation is async and outside your app's request cycle.
Architecture Overview — The 6-step event chain diagram (confirmation link → auth.users.confirmed_at → Postgres trigger → public.profiles.confirmed_at → Supabase Database Webhook → Next.js API route). Why bridging via a public-schema table is necessary (Supabase webhooks can't observe auth.*).
The Data Layer — The add_confirmed_at_to_profiles migration: adding the nullable confirmed_at column and the Postgres AFTER UPDATE trigger function handle_user_confirmed() that syncs it. Key insight: OLD.confirmed_at IS NULL AND NEW.confirmed_at IS NOT NULL guard.
The Webhook API Route — app/api/webhooks/user-confirmed/route.ts. Cover: shared-secret verification via x-webhook-secret header (security), parsing Supabase's { type, table, record } payload, independent try/catch per notification channel, and why always returning 200 OK prevents Supabase retry storms.
Notification Services — user-confirmed.ts. Resend for email (HTML body with name/email/ID/timestamp), Slack Incoming Webhook via fetch. Emphasize isolation — one failure never blocks the other.
Supabase Dashboard Config — The one-time manual step: create the DB webhook pointing to the deployed route, set the header, add a confirmed_at IS NOT NULL filter to reduce noise.

supabase.com
Environment Variables — Table of the 4 new vars (RESEND_API_KEY, ADMIN_EMAIL, SLACK_WEBHOOK_URL, WEBHOOK_SECRET) with descriptions.

What's Out of Scope (and Why) — No retry logic (intentional), no multi-admin, no notification prefs UI — acknowledge these and link to potential follow-ups.
Closing — Summary of the pattern: Postgres trigger → public table → Supabase webhook → app route. Reusable for other auth events (password reset, MFA enrollment, etc.).

Supabase Database Webhook Setup

User Confirmed Notification Webhook

This webhook fires when a user confirms their email and triggers admin notifications (email + Slack).

One-time setup in Supabase Dashboard

Go to Database → Webhooks in the Supabase Dashboard
Click Create a new hook
Fill in the following fields:

Field	Value
Name	`user-confirmed-notification`
Table	`public.profiles`
Events	`UPDATE`
Type	HTTP Request
Method	POST
URL	`https://your-domain.com/api/webhooks/user-confirmed`

Under HTTP Headers, add:

Header	Value
`x-webhook-secret`	(value of your `WEBHOOK_SECRET` env var)

Click Confirm to save.

Required: add confirmed_at filter

Without this filter, the webhook fires on every profile update (role changes, name updates, etc.), causing duplicate notifications. Add this filter condition:

Column: confirmed_at
Operator: is not
Value: null

This ensures the webhook only fires when confirmed_at is set.

Required environment variables

Make sure these are set in .env.local (dev) and in your Vercel / hosting environment (prod):

RESEND_API_KEY=
RESEND_FROM_EMAIL=
ADMIN_EMAIL=
SLACK_WEBHOOK_URL=
WEBHOOK_SECRET=

🚀 I Built a Full-Stack Blog CMS with Next.js + Supabase (And You Can Use It Today)

Frank Mendez — Wed, 15 Apr 2026 09:20:09 +0000

TL;DR
I built a production-ready blog CMS using modern tools like Next.js (App Router), Supabase, and Tailwind. It has auth, roles, drafts, an AI assistant, and a headless API. It’s open-source — and yes, you can try it right now 👇
👉 Live: https://blog.frankmendez.site/blog
👉 Repo: https://github.com/frank-mendez/nextjs-blog-cms
👉 Register: https://blog.frankmendez.site/register

🤔 Why I Built This

Let’s be honest — most CMS platforms fall into two categories:

Too simple → great for beginners, painful for devs
Too complex → enterprise-level headache just to publish a blog post

I wanted something in between:

Developer-friendly
Production-ready
Actually enjoyable to use

Also… I got tired of wiring the same auth + roles + editor setup over and over again. So I decided to build it once — properly.

🧠 What This CMS Can Do

This isn’t just a “Hello World blog.” It’s a serious CMS disguised as a clean UI.

🔐 Authentication & Roles

Supabase Auth out of the box
Role-based access control (Admin / Author)
Enforced using Row Level Security (RLS) — not just frontend checks (we don’t do fake security here)

✍️ Writing Experience

WYSIWYG editor (because Markdown wars are over… mostly)
Draft & publish workflow
Clean writing interface without distractions

🤖 AI Writing Assistant

Yes, there’s AI. Because of course there is.

Generate content ideas
Assist in writing posts
Speed up your workflow when your brain says “nope”

🔌 Headless API

REST API ready to plug into anything
Use it for mobile apps, dashboards, or your next side project

⚡ Developer Experience

Built with Next.js App Router
Styled with TailwindCSS + shadcn/ui
Clean structure, easy to extend
MCP-powered workflows (because we like things fast)

🛠️ Tech Stack

Frontend: Next.js (App Router)
Backend: Supabase (DB + Auth + RLS)
UI: TailwindCSS + shadcn/ui
AI: OpenAI integration
Deployment: Vercel-ready

Basically, if you’re a modern frontend dev — this stack will feel like home.

👀 Live Demo

Don’t take my word for it — try it yourself:

👉 Browse posts:
https://blog.frankmendez.site/blog

👉 Create an account:
https://blog.frankmendez.site/register

Yes, you can actually use it. No “coming soon” nonsense.

💡 Why You Might Find This Useful

This project is perfect if you:

Want a starter CMS without reinventing auth + roles
Are learning Next.js + Supabase in a real-world setup
Need a headless blog backend
Want to study RLS done right (seriously, this part matters)
Just like exploring clean, modern full-stack apps

📦 Open Source (And Why I Need Your Help)

Here’s the thing — open source only works if people actually… use it 😅

If you find this useful:

⭐ Star the repo → https://github.com/frank-mendez/nextjs-blog-cms
🍴 Fork it and build your own version
🐛 Open issues / suggest improvements
🚀 Share it with other devs

Every star helps push this project further (and tells me I’m not coding into the void).

🧭 What’s Next

I’m planning to add:

Comments system
Better SEO tooling
More AI features (without turning it into Skynet)
Plugin system (maybe 👀)

🧵 Final Thoughts

This project started as “I just need a blog CMS…”

…and turned into a full-blown platform.

If you’ve ever thought:

“There has to be a better way to build this stack…”

Yeah — same. This is my attempt at that.

If you try it out, I’d love to hear your feedback.
If it breaks… well, congratulations, you found a feature.

Happy building 👨‍💻