Headway

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 changelog that replaces Headway: what shipped, told to the people using the thing that shipped, without them going looking.

STACK
- Node 20+ with Fastify, server-rendered HTML
- SQLite through better-sqlite3, WAL mode
- One small widget script for the in-app badge, under 8KB
- Caddy in front

THE DATA MODEL
- entries: id, slug, title, body_md, kind, published_at, created_at, author_id, cover_path, is_major
- kinds: new, improved, fixed. Three, not seven — a taxonomy nobody can apply consistently is noise
- tags: id, name, colour; entry_tags joining table
- readers: id, key_hash, last_seen_entry_id, first_seen, last_seen — who has seen what, without an account
- subscribers: id, email, verified_at, unsubscribed_at, digest_kind
- views: id, entry_id, reader_key_hash, created_at, source — page, widget or email
- reactions: id, entry_id, reader_key_hash, kind — a small set, and one per reader per entry

WRITING
- Markdown, images pasted in, a preview beside the editor
- Draft, scheduled, published. A scheduled entry appears at its time without anybody being awake
- An entry can be marked major, which is the only thing that triggers the widget's badge — otherwise every typo fix nags the whole user base
- Templates for the three sentences you always write

THE PUBLIC PAGE
- Reverse chronological, one entry per block, filterable by kind and tag
- Permalink per entry with its own OG card
- RSS and JSON feeds, both complete rather than truncated
- Fast and readable without JavaScript

THE WIDGET
- A script that renders a badge on a trigger element the host page already has
- The badge counts entries newer than the reader's last seen, and only major ones if the host asks for that
- Clicking opens a panel with the recent entries, rendered from a payload fetched once
- The reader is identified by a hash the host application supplies, or by localStorage when it does not. No cookie
- The panel must not trap focus, must close on Escape, and must be reachable by keyboard
- Fails invisibly: if the changelog is down, the host page shows no badge and nothing else happens

TELLING PEOPLE
- Email subscription with double opt-in, per kind: everything, or major only
- A digest option — weekly, monthly — so somebody can hear about it without a message per release
- Every email carries the entries in full, not a teaser and a link
- One-click unsubscribe that works without logging in

WHAT THE TEAM SEES
- Views per entry, split by page, widget and email
- Reactions per entry
- Reader reach: how many distinct readers saw an entry within a week of publication
- The entries nobody read, which is usually a titling problem

INTEGRATIONS THAT ARE NOT A PLATFORM
- A webhook out on publish, so Slack or Discord get it without this project knowing what those are
- An API to create an entry, so it can be published from a release script
- Import from a Markdown folder, because most teams already have CHANGELOG.md

THE INTERFACE
- Writer: list, editor, schedule. Nothing else
- Public: one column, generous type, dates on the left on desktop
- Dark and light, one accent

OPERATIONS
- .env: DATABASE_PATH, BASE_URL, SMTP_URL, WIDGET_ORIGINS, HASH_SALT
- Migrations on boot, each once
- The widget payload endpoint is cached with an ETag and served from memory
- Nightly backup off the machine plus restore
- Health endpoint

WHAT MATTERS MOST
The widget and the major-only rule are the product. Build the entry model, the public page and the badge first, and put the badge on a real application — then ship five entries in a week and see whether the badge is useful or irritating. That answer decides the defaults.

Give me the repository, the widget script, migrations, .env.example, a seed with ten entries, and a README with deploy steps behind Caddy.