AppMate
Sign in

Emailing your waitlist

Send a real email campaign to the people who signed up — a launch announcement, a progress update, a beta invite. Pick recipients straight off the signups list, write it with a live preview, and AppMate queues and sends it in the background. Unsubscribes are handled for you.

Selecting recipients

Start on the app's Signups page. You can tick individual signups, or select everything matching the current filter and hit Email. The compose screen tells you exactly how many people the send will reach.

“Everything matching” scales to very large lists because the audience is resolved server-side from the filter itself — the browser never ships a list of ids. The list and the send share one query implementation, so the 12,000 rows you filtered down to are exactly the 12,000 people who get mail.

Filters you can send by

  • Search — matches on the email address (case-insensitive substring).
  • Date — signed up in the last 24 hours, 7 days, or 30 days.
  • Source — the source tag recorded with the signup.
  • Platform — iOS, Android, macOS, Windows, or Linux.
  • Browser — Chrome, Safari, Firefox, or Edge.
  • Web vs in-app — people who joined on the hosted waitlist page versus through the SDK inside your app.
  • Country — ISO country code.
Anyone who has unsubscribed is always excluded, whether you selected them by filter or ticked them by hand. There is no way to mail an unsubscribed signup.

A single broadcast is capped at 50,000 recipients as a guard rail against an accidental send to an enormous list.

Composing

The email is deliberately simple — it's an email, not a page:

  • Subject and a body of plain paragraphs (blank lines become separate paragraphs).
  • An optional call-to-action button — give it a label and a URL. A URL without a label is rejected.
  • An accent colourfor the button and header rule. It defaults to your waitlist flow's hero colour, so the email matches the page people signed up on.
  • Your app iconat the top, served from AppMate's public icon endpoint so mail clients actually render it.

A live previewnext to the form mirrors the real email's structure as you type.

Templates

Five starter templates ship with AppMate, so you rarely start from a blank box:

  • Thanks for signing up— confirm they're on the list. A good first send.
  • Progress update — keep the list warm between launches.
  • Early access invite — invite a batch in.
  • Launch day— you're live, send them to the store.
  • Beta / TestFlight invite — recruit testers from the waitlist.

Anywhere {app}appears in a template it is replaced with your app's name when the template is applied:

text
Subject:  {app} is live 🚀
          →  Nimbus is live 🚀

You can also save your own templates per app: write the email, give it a name, and it appears in the picker next time. Saving under a name that already exists updatesthat template instead of creating a duplicate, so re-saving a tweaked “Launch day” keeps one clean entry.

Sending

Hitting send doesn't send anything synchronously. AppMate creates one recipient row per person and hands the broadcast to a background worker, which drains it in batches of up to 100 messages, pacing itself between batches to stay inside the mail provider's rate limits. A 20,000-person send never blocks your browser.

The Sent emails page lists every broadcast with a status (queued, sending, sent, failed), a live “X / Y sent” counter, and a failure count if any batch was rejected. It refreshes on its own while a send is in flight.

Recipient rows are claimed with a status-guarded update, so a broadcast is safe to run across multiple replicas — nobody gets the same email twice.

Daily limits

Each account has a daily cap counted in individual recipient emails, not campaigns — ten campaigns of 500 people is 5,000 emails against your allowance.

text
free    10 emails / day
pro     1,000 emails / day
scale   5,000 emails / day
  • The window is a UTC calendar day — the allowance resets at midnight UTC, not on a rolling 24-hour clock.
  • Usage counts every recipient queued today across all apps you own, sent or not yet sent — so queueing ten large broadcasts at once can't sneak past the cap.
  • Your remaining allowance is shown on the compose screen before you write anything, and a send that would exceed it is refused with the exact numbers.
  • The three numbers are configurable by the operator via the EMAIL_DAILY_LIMIT_FREE, EMAIL_DAILY_LIMIT_PRO, and EMAIL_DAILY_LIMIT_SCALE environment variables, so a self-hosted or re-tuned deployment may differ.

The cap exists because every broadcast leaves through one shared sending account and one shared sending domain. An unbounded send burns quota everyone shares and — far worse, because it isn't reversible — damages that domain's reputation with Gmail and Outlook for every other user. It's a blast-radius limit, not a billing lever.

Unsubscribes

Every broadcast is compliant by construction:

  • A per-person unsubscribe link in the footer. The token is an HMAC of the signup id, so links stay valid forever and one opt-out only ever affects that person.
  • List-Unsubscribe and List-Unsubscribe-Post headers, giving Gmail and Apple Mail their native one-click unsubscribe button — which materially helps deliverability.

An unsubscribe does not delete the signup. The person stays on your waitlist and in your exports — you keep the signup, the count, and the analytics — they are simply excluded from every future send, permanently. The Sent emails page shows how many of your signups have opted out.

See getting started for setting up the waitlist flow that collects these signups, and AI agents & MCP for exporting them.