Shipping a newsletter feature in a markup-driven CMS

Quick build-in-public note: this week Micropage shipped a full newsletter feature. Subscriber capture, broadcasts, sender settings, welcome emails. End-to-end on existing infrastructure.

Why this matters more than it sounds like it should

Most landing-page builders don’t have a newsletter. You wire up Mailchimp, ConvertKit, Buttondown, or roll your own. The signup form on your landing page POSTs to a third party, and you go check your dashboard later.

That’s three tools to manage when you wanted one. And for the actual use case — capturing emails from people who arrived on a landing page — the lift is small enough that there’s no good reason it shouldn’t live in the same product.

Looking at how Micropage was actually used told the story. Most of the real sites running on it already had a form that was effectively a newsletter signup: name + email, no other fields. The submission went into the same place as a contact form. People manually exported the CSV every few weeks and pasted it into ConvertKit.

We could do that part too.

What shipped

Newsletter signup forms. Any form in the editor can be toggled to “Newsletter.” Submissions are still saved as form submissions, but they also create a persistent subscriber record on the project.

Subscriber management. A subscribers tab lists every subscriber for the project — email, subscribed date, source form, unsubscribe status. Export as CSV. Manual unsubscribe.

Broadcasts. A composer with markdown body, preview, test-send-to-myself, and send-to-all. Each broadcast gets a delivery report (sent, bounced, unsubscribed).

Sender settings. Per-project from-name, reply-to, organization details for CAN-SPAM / GDPR footers.

Welcome emails. Optional — set a subject and body once per form, sends immediately on subscription.

The interesting tech bit

The thing that surprised me about implementation: a newsletter is barely a “feature” when you build it on top of a form system that already exists. The whole feature is essentially:

  • A boolean flag on the forms table: is_newsletter.
  • Two new tables: newsletter_subscribers (one row per active subscriber per project) and newsletter_broadcasts (one row per broadcast).
  • A Supabase edge function for sending broadcasts via the existing transactional-email provider.
  • A few new editor screens.

That’s it. No new auth model, no new permissions, no new billing logic — subscribers count against the project’s form-submission quota.

The reason this was easy is structural: the form system was designed without assuming what each form is “for.” Adding a form-type wasn’t a special case; it was a flag.

That’s how I’d design a markup-driven CMS in general — the primitives should be small and useful in combinations, not pre-bundled by use case.

Roadmap

The obvious follow-ups:

  • Segmentation. Tag subscribers by source form, by region, by custom field.
  • Automations. Welcome series, drip campaigns, abandoned-cart-style triggers.
  • Transactional emails. Send a templated email from a webhook for arbitrary events.
  • Double opt-in. Currently single-opt-in only.

If you have a strong opinion on what’s next, drop a note in the contact form. Solo founder, fast roadmap — feedback shapes what ships.

Try it

Newsletter is on the free tier. Make any form a newsletter signup with one toggle, capture your first subscriber today. The docs page walks through it.