Investigate simple email subscription (likely via Buttondown)

[twistedmelonman]

Goal

Investigate adding a simple email subscription option for the blog/site, most likely using Buttondown.

Scope of investigation

• Buttondown pricing/free tier limits and whether they fit our needs
• Embed options: hosted subscribe page vs. embeddable form vs. API-based custom form
• How it'd integrate with the current Astro site (src/content/blog/) — static form embed vs. a small serverless function (Netlify function) hitting the Buttondown API
• Data/privacy considerations (what we tell subscribers, double opt-in, unsubscribe flow)
• Whether we need to store any subscriber data ourselves or if Buttondown handles it all
• Rough implementation estimate once an approach is chosen

Deliverable

A short writeup/recommendation on the preferred integration approach, to be used as the basis for a follow-up implementation issue/PR.

[twistedmelonman]

Investigation findings: Buttondown email subscription

Pricing / free tier

• Free tier: first 100 active subscribers, no cost. Includes markdown/rich-text editor, custom-domain sending, hosted archive. Limited to one email/day to the full list (a non-issue for a personal blog's cadence).
• Paid add-ons are à la carte, not tiered plans: $9/mo unlocks tagging, segmentation, analytics, RSS-to-email, attachments, etc.; $29/mo adds custom-domain archives, multiple newsletters, automations; $79/mo adds whitelabeling/teams.
• Billing is based on active subscribers (people currently receiving mail), not total contacts.
• Verdict: the free tier is very likely sufficient to start — no paid tier needed until well past 100 subscribers, and Project Insomnia's traffic doesn't suggest that's imminent.

Integration options (static Astro site, no backend currently)

Three supported approaches, in increasing order of effort:

1. Hosted subscribe page — link out to https://buttondown.com/<username>. Zero implementation cost, but takes the reader off-site.
2. Embedded <form> snippet — a plain HTML form POSTing to https://buttondown.com/api/emails/embed-subscribe/<username>, styleable with our own CSS, droppable straight into an Astro .astro component (no JS framework needed — this matches the site's existing all-static-Astro pattern with zero UI islands). Buttondown's docs flag a caveat: plain <form> submission only sends the page origin, not the full referring URL, due to browser referrer behavior — cosmetic only (affects Buttondown's own subscriber-source analytics, not functionality).
3. Embedded <iframe> — https://buttondown.com/embed/<username>, pre-styled, avoids the CORS/origin caveat above, but harder to visually match to site's design system (colors, fonts) since it renders Buttondown's own UI.
4. API-based custom form via serverless function — POST to Buttondown's REST API from a Netlify function (the site already has @astrojs/netlify + existing serverless functions per now.astro's /api/* feed pattern), giving full control over UX/validation and letting the API key stay server-side rather than exposed to a public embed. Most implementation effort, most control.

Recommendation: option 2 (embedded HTML form), styled with the site's own .tag/.share-button-style CSS conventions, placed in BaseLayout.astro's footer or at the bottom of PostLayout.astro (mirroring where #104's share button landed). This needs no serverless function, no API key exposure, and keeps subscribers on-site — a good match for a low-traffic personal blog where the API-driven approach's extra control isn't worth the added surface area. If richer UX (e.g. inline success/error states without a page reload) is wanted later, form submission can be intercepted with a small fetch()-based progressive enhancement, still without needing a backend function, since the embed endpoint returns a normal HTTP response.

Privacy / GDPR

• Buttondown enforces double opt-in by default for all newsletters — subscribers must click a confirmation link before becoming active. No extra work needed on our end.
• Buttondown states it is fully GDPR compliant despite being US-based, and handles data export and deletion requests from subscribers directly (self-service, "honored immediately" per their docs/privacy policy).
• Unsubscribe is subscriber-self-service via a link in every email, honored immediately.
• We don't need to store any subscriber data ourselves in any of the above approaches — Buttondown is the system of record. The only thing we'd want on our side is a short line of copy near the form disclosing what happens (e.g., "You'll get an occasional email when I publish something new. Powered by Buttondown — no spam, unsubscribe anytime.") for transparency, not because Buttondown requires it.

Rough implementation estimate (once approach is chosen)

For the recommended embedded-form approach: small — roughly a 1-2 hour PR. Create a SubscribeForm.astro component with the Buttondown form markup + site-matching CSS, drop it into BaseLayout.astro footer and/or PostLayout.astro, verify against Buttondown's docs for any current markup changes, test the double opt-in flow end-to-end with a real signup. No new dependencies, no serverless function, no schema/data changes.

Sources

• https://buttondown.com/pricing
• https://buttondown.com/features
• https://docs.buttondown.com/building-your-subscriber-base
• https://docs.buttondown.com/double-opt-in
• https://docs.buttondown.com/gdpr-eu-compliance
• https://buttondown.com/legal/privacy

---

Next step: if this approach looks right, I'd suggest filing a follow-up implementation issue scoped specifically to "add embedded Buttondown subscribe form to site footer/post pages" so it can be picked up as a normal, well-scoped task (this issue is intentionally left open as investigation-only per its own scope).