Internal newsletter builder

The problem

Internal communications have to go out looking right and on time. Without a tool, each one is either a plain-text e-mail nobody reads or a round trip through someone who can write HTML, so the newsletter goes out when that person is free, not when the news happens.

What I did

A colleague started the component in 2021; I took it over and have been its principal developer since. I also deploy it to the app catalogue of the tenant I administer, so for this component I am the developer, the release manager and the platform owner.

Work in that period includes new section types requested by PR and HR, HTML export, a contacts panel that reads distribution lists from SharePoint with send-as permissions that make mail arrive from the right mailbox, click-count analytics on outbound links, a guard against publishing a half-finished newsletter, and a long tail of layout fixes.

A decision and its cost

Typed sections instead of a free-form rich-text editor. Absolute freedom is lost, and every new layout idea costs a code change. In exchange every newsletter is on-brand, renders correctly in mail clients, and cannot be broken by a non-technical author. For a tool whose purpose is consistent branded output, constraining the author is the feature.

The newsletter is rendered to an image for distribution, because mail clients render HTML unpredictably and an image looks identical everywhere. That made the output unreadable to a screen reader, which is a real accessibility cost; the HTML export came later as the mitigation. It was the pragmatic call, and the mitigation came second rather than first.