The kudos board has scheduled delivery now. You pick a future date, lock the board, and contributors can add their cards without seeing what anyone else wrote. When the date passes, everything unlocks at once and the recipient gets an email telling them their board is ready.
That’s the feature. It’s built. The pipeline runs on schedule. Nobody’s received an email from it yet.
Here’s the architecture that’s currently sitting idle. Every five minutes, a pg_cron job calls process_pending_deliveries(). That function scans the boards table for rows where delivery_at has passed and delivery_email_sent_at is null. For each match, it makes a pg_net HTTP call to a Supabase Edge Function. The Edge Function builds an HTML email (subject line, recipient name, link to their unlocked board) and sends it via AWS SES v2. Then it stamps delivery_email_sent_at to prevent duplicate sends.
That whole thing works. I tested it by pointing a board at my own email address. The email landed in my inbox within about six minutes of the delivery window passing, the HTML rendered correctly, the link opened the right board. The logic is solid.
But AWS SES has two states: sandbox and production. In sandbox mode, you can only send to addresses that have been manually verified in the SES console. Send to anyone else and you get back a MessageRejected: Email address is not verified. error. The message goes nowhere. No error shown to the user. Just silence.
The only address I’ve verified is my own. So the only person the delivery pipeline can currently reach is me.
Getting out of sandbox requires filing a case with AWS Support and making an argument for why you should be trusted with production email. I submitted mine last week with a detailed use case. AWS came back the next day with follow-up questions: expected send volume, how recipient addresses are collected, how bounces and complaints get handled, a sample of the email content.
I answered everything honestly. Volume is low by design: a few dozen recipients per board, not blast campaigns. Recipients are entered by the person creating the board, for someone they know personally. SES event notifications handle bounces. Sample HTML included.
Submitted the follow-up. Now I wait.
I’m not annoyed by the approval process. AWS gating production email access is correct. Anyone with a t3.micro and a bad idea can start blasting mail. Requiring a paper trail is the right call.
It’s just a reminder that finishing the work and being allowed to use the work are two different milestones. The code ships clean. The permissions catch up later.
The cron job has been running every five minutes for three days now. Scanning the database. Finding nothing eligible. Doing nothing. When production access comes through, the first real delivery will work exactly as designed, immediately, without touching a line of code. The pipeline has been sitting there the whole time, executing correctly, waiting for AWS to say yes.
I know that is either wishful thinking or weird kind of optimism. Probably both. Either way I’ll let you know how it turns out.