August 2026 Summaries

Dark mode email rendering varies widely across clients, making it less a single design feature than a compatibility challenge involving unchanged colors, partial inversion, or full color rewriting. Apple Mail, which represents a large share of opens, can follow author-defined dark styles but requires explicit color-scheme opt-in and backgrounds on all containers to prevent dark text from disappearing against the app interface; Gmail ignores dark-mode CSS and transforms colors differently across desktop, Android, and iOS; and classic Outlook for Windows recolors messages with no reliable sender-side control. The recommended approach is to build resilient light and dark palettes with strong contrast, avoid pure white and black, define both inline and bgcolor backgrounds, use image treatments that remain visible when colors change, and test on real devices rather than relying solely on previews. For clients that support styling, media queries, Outlook-specific data attribute hooks, and carefully structured logo swaps can improve results, while Gmail and classic Outlook require designs that remain legible even after automated transformations.

Courier has redesigned its Settings experience as part of an ongoing app refresh, introducing an overlay-based layout that keeps users within their workflow and organizes options into Workspace and Developers categories. Workspace settings cover general appearance and workspace naming, team access, billing, AI credits, and audit history, while developer settings provide access to environment-scoped API keys, outbound and inbound webhooks, tracking controls, send limits, and tenant configuration. The update also adds appearance choices under General, including Light, Dark, and System themes plus nine background color options, with a warm orange Sunset gradient set as the default. Courier says the new settings layout is already available and that additional parts of the application will receive similar redesign updates.

Courier positions itself as a developer-focused alternative to Intercom for transactional and lifecycle product notifications, arguing that Intercom’s support-oriented API lacks direct push and SMS sending, reusable template references, delivery-status tracking, and campaign automation APIs. The post links this distinction to Intercom’s AI-support focus, its 2026 renaming to Fin, and Salesforce’s pending $3.6 billion acquisition, while clarifying that Intercom has not announced plans to discontinue outbound messaging. Courier claims to provide a unified API and interface for email, SMS, push, in-app, and chat notifications, with customer-owned provider accounts, cross-channel preference enforcement, delivery history, templates, broadcasts, and multistep Journeys for campaigns. It contrasts Courier’s flat per-message pricing and 10,000-message free tier with Intercom’s seat-based, add-on, and channel-specific pricing, estimating that 2,000 monthly push notifications would cost $223 on Intercom and nothing on Courier’s free tier. The post recommends retaining Intercom for help-desk functions, AI support, and product-guidance tools, while migrating notification workflows gradually by moving transactional sends first, mapping opt-outs and profiles, rebuilding campaigns as Journeys, and collecting push tokens directly through applications.

A product notifications API centralizes the process of turning application events into user messages by determining recipients, channels, timing, templates, preferences, and delivery status across email, SMS, push, in-app inboxes, collaboration tools, and webhooks. The post argues that such systems address recurring challenges including unified user identities, cross-channel preference enforcement, quiet hours, throttling, batching, digests, durable delayed workflows, notification-center read states, tenant-specific settings, editable templates, and consolidated delivery logs. It contrasts this approach with using separate delivery and marketing platforms, whose preference data and message histories may remain disconnected, and advises that building internally is most suitable only for simple, single-channel cases because long-term maintenance includes provider changes, token management, workflow reliability, and data reconciliation. Courier is presented as an example platform that accepts events through an API or webhook, supports immediate sends and multi-step journeys, provides embeddable inbox and preference components, and offers tools for AI coding agents through skills, an MCP server, documentation, and a CLI; its stated pricing includes a free tier of 10,000 monthly sends and pay-as-you-go pricing thereafter.

Customer messaging platforms support both marketing campaigns for segments and product notifications triggered by individual user events, but many organizations use separate tools for each, creating duplicated preference, suppression, and delivery-management processes. The post compares Courier with platforms including Customer.io, Braze, Klaviyo, Iterable, OneSignal, Airship, MoEngage, and Fin, arguing that most competitors focus on visual, marketing-led workflows and often require enterprise contracts, ongoing data support, or UI-only campaign management. It presents Courier as a unified multichannel platform for email, SMS, push, in-app, Slack, and Teams that combines a visual journey editor with API-based campaign creation, versioning, code management, and AI-agent access, while charging per send with a free monthly tier. The discussion notes that all such tools still require initial technical work to install SDKs, connect data sources, configure deliverability, and validate CDP or warehouse integrations, after which growth teams can generally manage content, segmentation, experiments, and scheduling. It distinguishes simple newsletters and lifecycle campaigns from tightly product-coupled notifications, where reliability, event handling, fallback delivery, auditability, and shared preference controls become more important, and recommends selecting tools based on whether a company primarily needs marketing automation, ecommerce flows, mobile engagement, support messaging, or product notification infrastructure.

Courier is presented as a developer-oriented alternative to Salesforce Marketing Cloud that lets organizations retain Salesforce as their CRM and system of record while moving notification delivery, campaign orchestration, templates, and preferences to a separate API-driven platform. The post argues that Marketing Cloud can create substantial licensing, implementation, consulting, and specialist staffing costs, while its low-code tools may become difficult to manage for complex requirements such as preventing overlapping messages across multiple journeys. It describes an architecture in which Salesforce data is synchronized into Courier user profiles, engineers trigger sends through APIs, and marketers use visual tools for templates, audience segmentation, broadcasts, journeys, preferences, and delivery logs. Courier’s per-message pricing is contrasted with Salesforce’s organization- and contact-based annual contracts, though the article notes that Salesforce Marketing Cloud may remain preferable for teams reliant on its advertising activation, landing pages, attribution tools, or established AMPscript and Data Extension workflows. Suggested migration steps include auditing active sends, building a profile sync, transferring templates and unsubscribe preferences, rebuilding journeys incrementally, and operating both systems in parallel during cutover.