A bulk email engine that maps every permanent SMTP refusal (5xx) to a hard bounce and blocks the address forever will suppress valid recipients: many 5xx refusals are transient or caused by the sender itself (message too large or complex 5.3.4, the sender domain failing its own DMARC/SPF 5.7.26/5.7.23, reputation or throttling blocks). Unbounce is usually rate limited, so the damage cannot be undone. A second trap: treating 'no answer' from the configured outbound relay (connection refused, 421, auth 535) as a per-recipient drop marks the whole remaining audience as not sent when the relay is just down.

Designing a marketing-email send engine on top of a single SMTP transport (local Mailpit in dev) that must survive restarts, never send the same email twice to an address, apply exclusions (unsubscribed, hard bounced, rolling frequency cap, monthly quota) at send time, and still let developers test bounces, deferrals and complaints even though the local catcher accepts everything.

When building a multi-step outreach sequence (timed emails + task reminders) on top of an app that already has a scheduled-email sender, naive designs read the live sequence definition at each step, render tokens at send time, and keep timers in memory. Result: edits to the sequence silently change what already-enrolled people receive, token values drift, steps can run twice or be lost after a server restart, and business-day/time-window math gets duplicated between UI preview and the worker.

HiveBrain was designed with shared/cloud mode as the default behavior. When TURSO_URL was set, it connected to cloud automatically. The --local flag was an opt-in for privacy. This created a bad default: new users submissions would go to a shared database without explicit opt-in.

How to structure a non-trivial interactive application (100+ lines of JS, multiple UI states, user interactions) in a single HTML file without it becoming an unmaintainable mess. Single-file apps are ideal for personal tools, demos, prototypes, and utilities because they have zero build step, zero dependencies, work offline, and can be shared by email or dropped into any web server. But without structure, they quickly become spaghetti: DOM reads mixed with business logic, state scattered across DOM attributes and global variables, event handlers that directly manipulate other parts of the UI, and no clear flow of data.

When building single-file web tools, personal dashboards, or local-first applications that don't need a backend server, the question of where to persist state comes up immediately. Options include: localStorage, sessionStorage, IndexedDB, cookies, Cache API, File System Access API, and even embedding state in the URL hash. Each has different size limits, APIs, and tradeoffs. The wrong choice leads to either over-engineering (setting up IndexedDB for 10KB of data) or hitting walls later (localStorage 5MB limit when storing images). This applies to: personal note-taking apps, bookmark managers, habit trackers, configuration tools, code snippet managers, and any tool where data lives on one device in one browser.