Opening moment or tension
The signup step of the Product Health Scorecard makes a small promise: the email address you give is used to send your result, and it is never used for sales follow-up unless you separately say yes. There is an unticked box for that second thing. Most people will never notice the promise. I noticed it for days, because I had to decide which system would be responsible for keeping it.
The default way to build this is well known. A form tool collects the address. An email service provider holds the list and sends the sequences. A few webhooks glue them together. That is where I assumed this build would end up, until a question stopped me: if someone withdraws their consent on a Tuesday, which of these systems knows by Wednesday?
What the obvious explanation misses
The obvious position is that email infrastructure is a speed decision. You are one person shipping a product; the ESP exists so you do not have to build sending, lists, and unsubscribes yourself; wiring one up is the responsible shortcut. That position is mostly right, which is what makes it dangerous.
What it misses is that my promise was not about email. It was about consent. The moment I split the funnel across two systems, consent lived in my database and sending lived in someone else's list, and the promise on the signup page depended on those two staying perfectly synchronized forever. Nothing in either system enforces that. Only my discipline would, and discipline is not architecture.
Evidence
FACT: I built the email layer natively instead. Every outgoing email sits in an outbox on the same database that records consent, and consent is checked at the moment each email is claimed for sending, not when it was queued. Withdrawing consent suppresses every unsent email in a sequence automatically, including ones scheduled days into the future. Unsubscribe tokens are per-send and stored only as hashes.
FACT: this did not cost weeks. The first commit to a verified production flow took four days; the full system, including a four-email consent-gated sequence, took six. The build carries a 107-test suite, and the runtime dependency list is Next, React, and MDX. The email provider and the database are called over plain REST.
FACT, as a limit: no founder has been through the Scorecard's field test yet. I can show you the mechanism. I cannot yet show you behaviour.
INTERPRETATION: the reason the native build was cheap is that the promise itself was doing the design work. Once "never used for sales follow-up" was treated as a system requirement rather than a line of copy, the architecture mostly chose itself: one source of truth, enforcement at send time, revocation that outranks the queue.
The emerging principle
A promise your system cannot enforce is not a promise. It is copy.
The boundary matters. This is not an argument against ESPs, which are the right call at scales and team sizes where a consent sync can be owned properly. It is an argument about where promises live. Every product makes commitments on its public surfaces: about data, about follow-up, about what happens after a failure. Each one is either enforced by a mechanism, or it is enforced by somebody remembering. The second kind fails quietly, and the person it fails in front of is the person you promised.
For builders
List the promises your product currently makes where users can read them. For each one, ask what enforces it. The honest answers tend to fall into three groups: a mechanism enforces it, a tool's settings enforce it until someone changes them, or a person remembers. The second and third groups are your real backlog. Some of those items are engineering work. Some are promises you should stop making.
Ending
The signup box is still unticked by default. Now there is a system that cannot forget what that means.