will
0bdf2b982b
Continues the content-engine plan: /platform, the homepage link, and the small-business-infrastructure course are already live. This adds the remaining pieces — a content/blog/ section with 4 long-form posts (kept draft:true, so nothing goes live until reviewed) and a committed set of ~12 ready-to-copy social posts in drafts/social-posts.md. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
84 lines
4.1 KiB
Markdown
84 lines
4.1 KiB
Markdown
---
|
|
title: "The Guardrails That Let One Person Safely Run Production Email for Five Businesses"
|
|
date: 2026-08-14
|
|
draft: true
|
|
description: "What actually happens when you're not around and something breaks — the specific, boring mechanisms that make one-person-run infrastructure safe."
|
|
---
|
|
|
|
The honest question anyone should ask before trusting one person with their
|
|
technical backend is: what happens when you're not around and something
|
|
breaks? Not "do you have good intentions" — systems don't run on intentions.
|
|
Here are the specific, unglamorous mechanisms that make it safe, today, in
|
|
production, for five real businesses.
|
|
|
|
## A routine push can never trigger a real send
|
|
|
|
Every campaign content repo I run has the same rule built into the tooling
|
|
itself, not just into a process someone has to remember: pushing content
|
|
changes can only ever produce a *draft* campaign. There's no field, no flag,
|
|
no config value that lets a routine content push schedule or trigger an
|
|
actual send to real subscribers.
|
|
|
|
Sending for real requires a separate, deliberate command — normally
|
|
triggered by pushing a dedicated `send/<slug>` tag, not a content commit.
|
|
If the worst outcome of a typo'd push is "an unsent draft appeared,"
|
|
the failure mode is designed correctly.
|
|
|
|
## Storage that's supposed to be private can't quietly go public
|
|
|
|
Every object storage bucket I run defaults to private. There's an automated
|
|
check in CI that fails the build if a change would make one publicly
|
|
listable — unless there's a deliberate, documented comment explaining
|
|
exactly why, right next to the code making the change. Not a wiki policy
|
|
somewhere. A build that won't go green until you either fix it or justify it
|
|
in writing.
|
|
|
|
## One business's access can't reach another's
|
|
|
|
Each site I run has its own deploy key, and each key is scoped so narrowly
|
|
it can only touch that one site's own files — nothing else on the server, no
|
|
other business's credentials or data. If one site's repo were ever
|
|
compromised, the blast radius stops at that one site.
|
|
|
|
This is worth being specific about, because "shared server" and "shared
|
|
risk" get conflated constantly. The thing that actually determines whether
|
|
one business's problem can become another's isn't which physical machine
|
|
they're on — it's whether access is properly scoped. You can have that
|
|
property, or fail to have it, on a dedicated server or a shared one.
|
|
|
|
## Anything touching real customer data defaults to "show me," not "do it"
|
|
|
|
Every ops script that could affect real subscribers — bulk name backfills,
|
|
unsubscribes, list edits — defaults to a dry run. Actually writing a change
|
|
requires an explicit `--apply` flag, every time, no exceptions. The safe
|
|
path is the path of least resistance; the dangerous one takes an extra,
|
|
deliberate step.
|
|
|
|
This isn't hypothetical caution. When one client's mailing list switched to
|
|
double opt-in partway through, their earlier import batch — people who'd
|
|
already agreed to be on the list through a real prior relationship, just not
|
|
yet confirmed in the system — stayed exactly as `unconfirmed`, honestly
|
|
reflecting what was actually true about them, instead of getting swept into
|
|
a clean-looking but false "confirmed" count. Boring and correct beat clean
|
|
and wrong.
|
|
|
|
## You verify after every step, not just at the end
|
|
|
|
Moving a production deploy key off a root account isn't safe to do in one
|
|
commit if you're doing it carefully. It took three: move the key to a
|
|
dedicated account, verify the deploy still works. Fix the account's shell
|
|
so the key actually functions, verify again. Remove the old root-level
|
|
access, verify a final time. Three commits, three separate verifications —
|
|
because "I'm pretty sure that worked" isn't good enough on a production
|
|
system running mail for five businesses.
|
|
|
|
## None of this is exotic
|
|
|
|
Every mechanism above is the ordinary, unglamorous work of making the
|
|
dangerous action harder than the safe one — done once, for the whole
|
|
system, instead of relied on per person, per day. That's what "safe to hand
|
|
this to someone else" actually means in practice.
|
|
|
|
Curious how the whole system fits together? Start at
|
|
[/platform](/platform/).
|