Boomerang

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 the inbox follow-ups I actually need instead of Boomerang: send later, bring it back if nobody replies, and stop a thread slipping.

**The good news is that most of this is now built into the major mail clients.** Scheduled send and snooze both exist natively. Check yours before building anything — what is genuinely missing is the follow-up reminder that fires only when nobody replied, and that half is a small server.

STACK
- Node 20+ with Fastify
- SQLite through better-sqlite3, WAL mode
- Read-only mailbox access over the provider's API or IMAP, and send through the same account
- A worker for the schedule, separate from the web process
- Caddy in front

THE DATA MODEL
- accounts: id, address, provider, credentials_encrypted, token_expires_at, last_synced_at
- scheduled: id, account_id, draft_ref, send_at, sent_at, message_id, error, attempts
- followups: id, account_id, thread_id, message_id, remind_at, condition, resolved_at, resolution — condition is 'no reply', 'no reply from them', or 'always'
- threads: id, account_id, thread_id, subject, last_message_id, last_from, last_at — a small mirror, enough to answer 'has anybody replied'
- Never store message bodies. The address, the subject, the timestamp and the identifiers are all this needs

SEND LATER, WHICH IS THE EASY HALF
- A worker holding the message and sending at the chosen instant through the account itself, so it appears in Sent like anything else
- **The scheduled instant is in the recipient's working hours if you want it to be**, which means a named zone rather than an offset, and both daylight-saving transitions tested
- Idempotent: a send is recorded before the attempt and confirmed after, so a crash between the two never sends twice. Sending the same message twice is the one failure people notice
- If the send fails, tell the sender rather than silently retrying forever

THE FOLLOW-UP, WHICH IS THE REASON TO BUILD IT
- 'Remind me in four days if nobody replies' — the condition is the feature
- Detecting a reply means watching the thread: match on References and In-Reply-To, and check whether the newest message in it is from somebody other than you
- **An automatic reply is not a reply.** Detect out-of-office and vacation headers and do not count them, or every follow-up cancels itself against a bounce message
- Resolve on reply, on a manual dismissal, or when the reminder fires. Record which
- The reminder is a message to yourself, or a label applied to the thread. A label is better: it puts the thread back in the inbox where it belongs rather than adding a second message about a message

SYNC AND CARE
- Incremental with a cursor, idempotent by message id, polite about rate limits
- Credentials encrypted at rest, refreshed under a lock so two workers cannot invalidate each other
- **This has access to a mailbox.** Say plainly in the README what is stored — identifiers, subjects, timestamps, never bodies — and keep it true
- Revoking access must be one action, and it must actually delete the stored tokens

WHAT NOT TO BUILD
- Open tracking. It is under Mailtrack elsewhere in this catalogue and the argument against it is there too: it is a pixel nobody agreed to, in a one-to-one message, and it tells you very little now that proxies pre-fetch images

WHAT MATTERS MOST
Reply detection that ignores automatic replies, and a send that cannot fire twice. Everything else here already exists in your mail client — check what does before writing any of it.