---
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/).