Every email the platform should send.

What is already standing

More than it looks like. Nothing here needs to be invented; the pieces have simply never been joined up.

For scale: public.notifications holds 22 rows in its entire history across 14 accounts, and a good share of those came from this week's own testing. Nothing about this plan is near a rate limit. That is a reason to be careful rather than relaxed — the domain has almost no sending reputation, and the first thing it does at volume will decide how the next year of mail is filed.

One fan-out point, not thirty

The tempting shape is to send an email at each place something happens. It is also the shape that guarantees the next feature forgets.

Every notice already converges on a single insert into public.notifications. Putting the email on that table means the ten notices that exist today get email without touching any of the code that writes them, and every notice written from here on is covered by construction. One trigger, one template registry, one place to reason about whether somebody is being told too much.

Three new columns on notifications carry it: email_key text is both the template name and the on switch — null means the notice stays in the app, which keeps the decision about what deserves an interruption in one readable place. email_payload jsonb holds what the one-line message does not: the date, the address, the amount, the other person's name and number. emailed_at timestamptz is the guard, so a retried webhook or a re-run trigger cannot mail somebody twice.

The templating deliberately does not live in PL/pgSQL. send_lead_email() concatenates a table of label-value pairs, which is right for two staff addresses and wrong for anything a customer reads. User-facing mail needs the real shell, both MIME parts, copy that changes by role, and working deep links — that belongs in TypeScript next to the generator that already produces the auth templates, so there is one voice and one palette rather than two that drift.

The catalogue: what exists, and gets email

Ten notices are live in the app today. Each one is here because somebody is waiting on it, is owed money by it, or would otherwise drive to a house for nothing.

The catalogue: what is missing entirely

These have no email and no in-app notice. Each needs both halves built. Reading the code, the gaps cluster around exactly the moments people care about most: money actually moving, and a job that is about to happen.

Two of these change the shape of things rather than adding to them. Payouts not being set up is a state, not an event — a nudge two days after signing up, and again if a job is sent to somebody who cannot be booked. And a review request is the only message on the list with no trigger anywhere near it; it hangs off the same clock as the reminders.

What people can switch off

Settings currently says, plainly and correctly, that there is nothing to unsubscribe from because nothing is being sent. That sentence is about to stop being true, and what replaces it should not be a wall of switches that all mean roughly the same thing.

One email_prefs jsonb column on profiles holds it, and every email footer links to it. The link has to work without signing in first — an unsubscribe that demands a password is the reason people press the spam button instead — so it carries a signed token, and the route reads that rather than a session.

The same reasoning puts List-Unsubscribe and List-Unsubscribe-Post headers on everything outside the always-on group. Gmail and Microsoft both now expect one-click unsubscribe from any sender doing volume, and a domain with no history gets less benefit of the doubt than most.

The clock we do not have

Reminders, review requests and payout nudges are all the same problem: something that has to happen at a time, not in response to a write. Everything built so far is a trigger, and a trigger cannot fire tomorrow morning.

pg_cron is the smaller of the two options and keeps the whole system in one place: a job every fifteen minutes that finds confirmed appointments falling inside the next window and inserts the reminder notices, which then flow out through the same fan-out as everything else. Reminders become ordinary notifications that happen to have been written by a clock. The alternative — a Cloudflare cron trigger calling an edge function — means a second deployment target and a second place to look when something does not send.

One thing to settle before writing it: appointments.scheduled_date is a date and scheduled_time is text, with no timezone anywhere on the row. "9:00 AM" is not a moment until you know where. Everything is in one metro today so it works out, but a reminder job does arithmetic on these values and that is exactly where an assumption like this stops being harmless. The job feed already had a timezone migration; this needs the same treatment, and it is worth doing first rather than discovering it at 6am in somebody's inbox.

Reputation is the constraint, not the quota

Fifty thousand messages a month against a marketplace this size is effectively unlimited. A booking that runs the whole way through — application, decision, confirmation, two reminders each side, release, two review requests — is somewhere around fifteen emails across both people. The quota covers a few thousand bookings a month, which is a problem worth having later.

What is actually scarce is the domain's standing. tourdash.io started sending on 4 September and has sent a handful of messages. A beta agent already found her confirmation email in spam, and her brokerage is on Microsoft 365 — as most brokerages are, and M365 junks unknown senders by default. Volume arriving suddenly, from a domain with no history, into tenants that already distrust it, is the one way to make this worse rather than better.

So: every message gets a real plain-text part alongside the HTML, which the auth templates cannot have because Supabase only stores one field — these are ours, and they can. Send the transactional messages first and let them build history, because those are the ones people open. Hold the weekly digest until the DMARC reports come back clean and until there is enough work on the board that it is worth opening. And keep the volume honest: a message nobody wanted costs more than the one it delivered.

The order of the work

Four phases. The first one is the only one that is mostly plumbing; after that each phase ships messages people actually receive.

Team alerts get a small extension along the way. Waiting-list signups and new accounts already reach the team; a first booking, a dispute, a refund and a Connect failure should too. Those reuse send_lead_email() exactly as it stands and cost almost nothing to add.

Phase one, as built

Live on 10 September, the same day this was written. It went in as described above, with three changes the code argued for once it was being written rather than planned.

Two bugs turned up while the producers were being edited, both fixed in the same migration. handle_new_application had quietly reverted to "New Application" in title case with the job name in straight quotes and no link, because profile-preferences-migration.sql ran after notifications-migration.sql and carried an older copy of the function forward with it. And a contractor who withdrew from a booking was being told the agent had gone with someone else, about a job they had walked away from themselves — the edge function marks their own application rejected, which is what the notice trigger reads. That was already wrong in the app and would have been emailed, so applications.closed_reason now records why an application closed and the trigger stays quiet when somebody is being told about their own decision.

All probe rows were removed afterwards and the table is back to the 22 notices it held before. Nothing backfills: the trigger is AFTER INSERT, so nobody was mailed about last week.

The reminder, and the text

The four questions below were answered the same evening, and three of the answers changed what got built.

The reminder is written by a fifteen-minute pg_cron sweep that inserts ordinary notifications, so it inherits the templates, the preference check, the send and the stamp that everything else already goes through. Both sides hear: the person covering needs the address and whatever the agent said about getting in, and the agent needs to know it is still covered and by whom.

The timezone question is settled. appointments now carries starts_at, a real instant built from the date and the text time in the zone the market is in. It is a stored column rather than a generated one because timestamp at time zone is STABLE rather than IMMUTABLE, so Postgres will neither generate the expression nor index it. Two edge cases are decided by the sweep rather than the template: a job booked after its own reminder time gets no reminder, because the confirmation sent minutes earlier already carries the same time, address and note; and the word "tomorrow" comes from the data, so a catch-up run after an outage cannot say tomorrow about this afternoon.

Texting is opt-in and stays opt-in. The switch going on is the consent record, stamped by a database trigger so no caller can forget it, and cleared when it goes off. An account with no phone number sees the switch explain itself and refuse to move, rather than a control that looks like it works and can never deliver. Every message carries its own opt-out, because a registered sender is one that offers a way out in the message itself.

Verified by moving one real booking into its reminder window with texts off for the brokerage address: the sweep found it, wrote both notices, stamped the appointment, sent the covering side's email (delivered at Resend, both MIME parts), skipped the other with "reminders switched off", and answered "twilio not configured" for both texts. The booking, its timestamps and both accounts' preferences were put back afterwards. One copy bug turned up in the process and was fixed: the footer said "booked for this job tomorrow" under a message headed Today.

One thing shipped that morning was wrong and is now fixed. appointments.scheduled_time is text holding a 24-hour clock string, and the formatter passed it through untouched, so a cancellation email would have read "at 17:00:00". It reads "5:00 PM".

Phase two, and where each one hangs

Eight moments that already happened and that nobody was told about. The rule throughout was to hang each one off a state change that already exists rather than off an edited code path, so there is no second place to remember.

The payouts nudge changed shape once the data was read. The plan said "the vendor", and the live database has no vendor accounts at all: all fourteen are agents, and agents cover each other's showings for money. Filtering by account type would have meant the nudge never fired for anybody. The test is intent instead — somebody who has applied for a job or been invited to one has said they want work and cannot receive it — which leaves an agent who only ever posts jobs unbothered about a payout they will never take. Two real people qualify today, both of them silently unbookable.

Reviews also gained their own switch. They had briefly been folded under reminders, which the settings page describes as the note the evening before a job; a switch that turns off more than it says is how a preferences page stops being believed. Four switches now: reminders by email, reminders by text, money, reviews.

All four database triggers were fired against live rows and every payload and recipient checked, then everything was put back: the appointment, the payment, the review, the rating average and both accounts' preferences. With money and reviews switched off for the duration, three of the four notices answered "switched off" and sent nothing, while the buyer contact notice sent anyway because it is marked critical — somebody is driving to a house. That is the categorisation proving itself in both directions.

What is still open

Texts need a Twilio account, a number, and the 10DLC registration cleared before a single one sends. Until then the switch is visible, the consent is recorded, and the send path answers "twilio not configured" and moves on. That is the only thing in this plan waiting on something outside the code.

Two notices have been built but never fired by a real event, because neither event has happened yet on this database: the welcome, which needs somebody to confirm a new account, and the payouts nudge, which runs for the first time at 14:30 UTC. Both were checked by rendering and by reading the installed functions back, which is weaker than watching one arrive.

Everything the plan listed is now either live or deliberately cancelled.

How the four questions were put

Everything above is a recommendation, and four of them are genuinely yours rather than the code's.