Send email — and keep your own record that you did

Twenty minutes ago, a customer asked for a password reset. It never arrived — they're locked out, mildly annoyed, and asking why. So you go to find out, and discover there's nowhere to look. The reset link is generated and handed to an email-sending library, and after that the trail goes cold. You can't tell the customer "we sent it at 14:32, here's the message," because your own system doesn't know it did. You also can't tell them "we never sent it," because it doesn't know that either. The honest answer is I don't know what happened — the worst answer to give someone who can't get into their account.

That gap is the whole subject of this note. It has nothing to do with which email service you picked, and everything to do with what you kept on your side of it.

The provider's job is real, and it's theirs

Getting a message accepted by a stranger's inbox is genuinely hard, and the hardness lives almost entirely outside your product. Whether a message lands depends on sender reputation, on SPF and DKIM records lining up, on how a given mail server scores you that day, on bounces and spam-folder placement — a dozen signals you don't control and shouldn't try to. An email or SMTP provider exists to carry exactly that burden: the sending infrastructure, the relationships with the big mailbox operators, and the reputation that gets your messages through the door. It's a clean thing to rent — high-stakes, well-solved by specialists, and not the part that makes your product yours.

So delivery is settled. The provider takes the message and works to land it in the inbox. What the support email above exposes is narrower and entirely yours: whether the message ever left your building, and whether you can prove it.

What you keep: the templates, the meaning, and the log

Three things stay on your side, and the provider is the wrong home for all three.

The templates are yours — the wording of the receipt, the reset, the welcome. They carry your product's tone and they change for product reasons, so they live with the product, not in a vendor's template editor where they drift out of sight.

The meaning is yours. "A receipt for invoice 4021 was sent to this customer" is a sentence about your product; "an HTTP request to send an email returned 200" is a sentence about an API. Those are different facts, and the first one is the one you'll be asked about. Your system should record that a receipt went out, tied to the invoice it's for — not just that some bytes were handed off.

And the log is yours: a local record of every message your product tried to send. Who it went to, which template, when it was queued, and whether it ended up sent or failed. The provider keeps its own version of some of this, but reachable only through their API, on their schedule, shaped their way. The copy your product reads from — the one your support person opens when a customer is locked out — should be yours, answerable in seconds.

Sending once, on a schedule, and writing down what happened

There's a quieter discipline underneath the log, and it's the part most hacked-in send code skips. When a send fails — the provider is briefly down, the connection times out — the tempting reflex is to retry immediately, and keep retrying. That turns one failed message into a loop that hammers the provider and hides the failure instead of recording it.

The steadier shape is to try on a known, bounded schedule, write down the result of each attempt, and stop. A message goes into a send queue; the queue attempts delivery on a fixed cadence; each attempt's outcome is logged; after a bounded number of tries a message that still won't go is marked failed and left visible, not buried under another silent retry. The point isn't to never retry — it's that every attempt leaves a trace, so "we tried four times over an hour and the last one bounced" is a thing your system can actually tell you. (That bounded-retry-plus-log shape is worth getting right once and reusing; wiring a new kind of email on top of an existing queue and history is an afternoon — the afternoon is only short because the queue and the log already exist.)

What this buys you the first week real users sign up

Put the log back into the opening scene and the support reply changes completely. Instead of I don't know, you open the Emails view, find the customer, and read the row: reset link queued at 14:32, sent at 14:32, no bounce recorded. Now you know the message left your building, and the question has moved to the inbox side — caught in a spam filter, a mistyped address, a corporate mail server holding it — which is a different and far more answerable conversation. Or the row says failed, and you've found a real bug on your side before the customer had to teach it to you. Either way you can tell the difference between we never sent it and we sent it and it didn't land, which is the one distinction the whole situation turns on.

None of this shows up in a demo. A demo is one person signing up once, and it works. The gap shows up the first week real people are creating accounts and expecting receipts — exactly when "did we send it, or did their inbox eat it?" starts arriving in your inbox, and you need an answer that isn't a shrug.

This isn't theoretical for the foundation. CompanyGraph runs an email-service in production today — templates, a send queue, SMTP delivery, and a queryable send history surfaced in an admin Emails page — and the same service sends for Smallbox Labs. When a message doesn't arrive, the first move is to read the row, not to guess. The sending was the part to rent; the record of what was sent is the part that makes support possible at all.

The capability note beside this one — what a payment provider should never be the only record of — makes the same argument about Stripe, because it's the same argument every time: rent the hard external job, own the record that says what you did.

---

Email wired this way is part of the foundation — the queue, the bounded retry, and the searchable send history run in CompanyGraph's production email-service today, and send for Smallbox Labs from the same place.