Buttondown

Promptfree, for everyone, and the only version there is

Copy the prompt for Claude CodeCopy the prompt for CodexCopy the prompt for Cursor

Copy

Build me a plain newsletter tool that replaces Buttondown — and be clear about why this is ALMOST.

The application is small: Markdown in, email out, a signup form. **Deliverability is the whole difficulty.** Buttondown's price buys a warmed sending reputation and somebody watching complaint rates. You will still need a sending provider, and you will have to warm your own domain. If that sentence sounds like a chore rather than a project, keep paying.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- A sending provider through SMTP or its API
- A worker for sending, separate from the web process
- Caddy in front

THE DATA MODEL
- subscribers: id, email, name, status, confirmed_at, unsubscribed_at, bounced_at, complained_at, source, tags_json, consent_text, consent_at, ip_hash, created_at
- emails: id, subject, preheader, body_md, body_html, body_text, status, scheduled_for, sent_at, recipient_count, web_slug, is_public
- deliveries: id, email_id, subscriber_id, sent_at, opened_at, bounced_at, bounce_kind, complained_at — one row per person per email, written before sending, which makes a resume exact and a duplicate impossible
- clicks and links, if you track them
- automations: a welcome sequence, and nothing more elaborate until you need it
- suppression: email_hash, reason, at — global and permanent

WRITING AND SENDING
- Markdown with a live preview, images stored locally with dimensions recorded
- The HTML built from tables and inline styles because that is what mail clients render, and the plain text generated from the same Markdown rather than written twice
- A test send to yourself required before any send, enforced
- Batched with a lease, resumable, rate-limited to what the provider accepts
- A confirmation showing the recipient count before it goes

DELIVERABILITY, THE PART THAT MATTERS
- SPF, DKIM and DMARC on your own sending subdomain, with the records written out in the README
- Warm slowly: hundreds at first, doubling over weeks. A new domain sending ten thousand on day one lands in spam and stays there
- Bounces and complaints consumed from the provider's webhook: a hard bounce unsubscribes, a complaint unsubscribes permanently and is never mailed again
- Watch the complaint rate; above a fraction of a percent the provider suspends the account
- One-click unsubscribe with no login, plus the List-Unsubscribe and List-Unsubscribe-Post headers, which the large providers now effectively require

THE LIST
- Double opt-in, a signup form and an embeddable one, a honeypot, a rate limit per address hash
- The consent sentence stored with its timestamp exactly as the person saw it
- Import from CSV with a dry run and a declaration of where the addresses came from. Importing a purchased list is how a sending account is closed in a week
- Export complete, in one command

THE ARCHIVE AND THE API
- Every sent issue at a permanent public URL if you want one, with an RSS feed, Open Graph tags and a generated share image
- A small REST API for subscribers and emails, with a token — Buttondown's own appeal is partly that it is scriptable, and that is a few endpoints

REPORTS
- Sent, delivered, opened, clicked, bounced, unsubscribed, per email and over time, computed at query time
- Open rate labelled as unreliable, because proxies pre-fetch images

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, PROVIDER credentials, FROM_ADDRESS, SESSION_SECRET, HASH_SALT
- Migrations on boot, each once; nightly backup off the machine — the list is the asset
- Health endpoint checking the provider and the bounce feed

WHAT MATTERS MOST
Per-subscriber delivery rows and bounce handling. Build the resumable send and automatic suppression first, then warm the domain patiently. Everything else here is an editor.