Every notification email opens with a first name because automated updates should not feel automated

The portal sends five types of notification email — session notes added, milestone status changed, new comment posted, new deliverable uploaded, and new action item assigned. Every one of them opens with Hi followed by the client's first name. Not their full name, not Dear Client, not a generic greeting. The code calls clientName.split and takes the first element. Sarah Thompson becomes Hi Sarah. That is a deliberate decision about tone. These are not marketing emails. They are not transactional receipts. They are project updates between me and a client I am working with. The language should match the relationship. The subject lines follow the same principle. New session notes uses the project name as context. Milestone completed names the specific milestone. Action needed tells the client something is waiting for them. Every subject line describes what happened without padding it with branding or exclamation marks. The body text is two to four lines of plain text. No HTML template, no header image, no footer links, no unsubscribe mechanism. Just a sentence explaining what changed, a link to the portal, and James at the bottom. The reply-to on every email is my actual email address so the client can respond directly to the notification and it lands in my inbox. The getResend factory function returns null if the RESEND_API_KEY is missing. Every notification function checks for null before attempting to send. If the key is not configured — during local development, during testing, during a CI run — the notification silently skips instead of throwing an error. Email is useful but it is not a dependency. The project update still happens in the database whether or not the email goes out. Five notification types, one tone, zero HTML templates, and every greeting is personal.