Five notification types, one pattern

The portal sends five different kinds of email notification. Session notes added. Milestone status changed. New comment posted. Deliverable uploaded. Action item assigned. Each one is a single function that takes the client email, the project name, and the relevant detail, then fires a Resend API call. No queue, no background worker, no retry logic. Fire and forget from the route handler. If Resend is down the notification silently fails and the portal still works — the email is a courtesy, not a dependency. Every notification links back to the portal so the client can see the full context. Every one uses the same from address, the same reply-to, the same tone. The pattern is so consistent that adding a sixth notification type would take ten minutes. That is what happens when you extract the pattern after building five real examples instead of designing an abstraction before building any.