Infrastructure Part 2: Every Monday at 06:00. 100% built with AI.

If you mess up on the web, you just republish the page and the mistake is gone. A send gone wrong cannot be saved. If you send twice, the entire list gets a duplicate in their inbox. If you send to someone who has unsubscribed, you break a promise, and the law cares. If you send to half the list, you have no reliable way to reach the other half. And if next week's issue leaks on the site on Saturday, the release is ruined before it even happens.

That is why we built the engine backwards. We started from the worst-case scenario. Everything up to the send must be undoable: the import, the build, the preview, the test email, even the decision to send. Only one line is irreversible: the second that Postmark — the service talking to the world's email servers — accepts the campaign. Up until that point, we can roll back. After that, nothing is allowed to send that issue again.

Drawing that line perfectly took us six days. The first version was finished in one day.

On July 17, we introduced a SQLite database as the core of the system. A single file. It is readable from both PHP and Node, it handles transactions, and it locks itself. The database sits outside the folder visitors can access, with permissions strictly limited to the owner. Both environments refuse to start if the file permissions are wrong.

Everything the newsletter needs to remember lives there: subscribers, confirmation tokens saved only as hashes, rate limiters stopping abuse, campaign statuses, and the history of every issue ever sent. This is also where every update Postmark sends about an address is saved: an unsubscribe, a spam complaint, or an address that stopped working. All of this arrives through a single, secure front door. The database updates are short, and no write is held open while we wait for the network. The database never locks up because of a slow connection.

The most important detail of the design is the separation of powers. SQLite owns consent: does the person want the email? Postmark owns deliverability: is it even possible to send it there? A subscriber gets the newsletter only when both say yes. Neither of them is allowed to overwrite the other's decision. If an address permanently fails (a "hard bounce"), delivery stops, but it doesn't change the consent record. An old confirmation link can never override a fresh unsubscribe. Every 24 hours, a script compares the two, cleans out expired invitations, checks the database health, and saves a verified backup. We keep 35 daily copies, and one per month for a year.

Consent also has a front door. We gave it the same care.

What lands in the inbox is built at the same time as the website, from the exact same text file. Our code generates a clean, single-column HTML document that works in email clients. All design is baked right into the elements (inlined CSS), and we include a plain-text version. We don't force a background or text color, which means the recipient's native dark mode works exactly as they are used to. If the text is too long, it gets cut off at the end and points to the web, keeping the email under 90 kilobytes. Gmail clips anything over roughly 102 kilobytes, which risks hiding the unsubscribe link at the bottom. We have zero tracking in the email: no hidden pixels, no tracking links. The engine knows what Postmark delivered, but not a thing about what readers do next.

The sending step is where we structurally eliminated the risk of errors. When the campaign is prepared, a fingerprint (a hash) of the exact HTML and text going out is saved. Before the sender starts, it verifies that hash. Then it records the intent to send in the database: which issue, the payload, how many people will get it, and a receipt of the exact list. Only then does it send. One single, massive request to Postmark's Bulk API, containing the email body and the full list of recipients. No loop sending a small batch at a time. No temporary file remembering where a crashed program left off.

Either Postmark accepts the request and we track it via an ID, or it fails in one of two ways. If we get a flat no, we can fix the problem and tell the system to try again, but that requires a human pressing a button. If the answer is ambiguous — like a server timeout or the network dropping — everything stops. The entire send freezes until someone checks the database against Postmark's logs. The tool we built for that reconciliation is extremely pedantic. It checks the request ID, subject line, recipient count, and timestamp before accepting Postmark's status as the truth.

There is no "send immediately" command. The database strictly limits campaigns to one (1) run per issue. We didn't just patch the race conditions we found — we structurally eliminated them.

The Sunday routine is now driven by a terminal panel we start with two letters: tj. The panel compares the code we have with the latest draft from Johan's Obsidian. It displays the versions locally, on GitHub, and on the server, and refreshes every ten seconds. Options that aren't available are grayed out with a clear explanation, so there is no guessing why.

[i] import the newest issue from the vault, commit only that issue, and upload it
[l] build and toggle the background local preview
[t] send the checked candidate to one remembered test address
[a] arm/disarm the checked revision for Monday 06:00
[u] unsubscribe one reader locally and at Postmark
[c] copy the current issue as rich HTML for LinkedIn

This is what a Sunday evening looks like now. Johan finishes the text in Obsidian. He presses [i]. The machine imports the text, shrinks the images, commits the change, pushes it to the server, and waits for a receipt. The draft is now on the server, reviewed and ready, but hidden from the world. [l] opens a preview on the screen. [t] fires a test email to a saved address — the exact code going out, via the same servers, but without being recorded in the database.

Then comes the critical step. Johan presses [a]. The command arms the revision — and its unique hash — for Monday 06:00. What we load the machine with is literally the exact bytes going out. If anything changes before Monday, like fixing a typo and redeploying, the machine disarms itself. Nothing sends until Johan actively chooses to arm the new version. Another press on [a] disarms the release. And the machine can't just forget about it: if the clock strikes 06:00 and three hours pass without a send going out, the alarm sounds.

Johan closes the lid. A draft is armed. The machine handles the rest.

The email we armed that first Sunday opened with the words "Goodbye Wordpress!" The very first thing the machine did was wave goodbye to its own predecessor. At 06:00 the server updated, the request was accepted, the web updated, and the entire list got the issue in their inbox. Then it went up on LinkedIn. Week 30 is in the archive.

That was three weeks ago now. Two more Mondays have passed without a single bump. The human role has shrunk to what it always should have been: write the text, press four keys, go to sleep. The yearly subscription for the WordPress plugins is canceled. The hour-long routine of manual handling is gone. What's left is the cost per email at Postmark, and a small codebase we own from end to end. We let Claude Fable 5 write the engine. We let GPT-5.6 review the safety. We stress-tested everything against a local mock server. And the newsletter is still written by hand.

It is a model that works for any process where the critical moment cannot be undone. Invoice runs, customer mailings, payroll. Put the responsibility for state in one single place (the database). Make arming an active decision tied to exact bytes. Record the intent before you step out onto the network, and stop the machine at the slightest doubt instead of guessing. Rehearse mistakes on a clone. Then Mondays are boring, exactly as they should be.