# Social post drafts — /platform launch series Ready-to-copy LinkedIn/X posts. Suggested cadence: ~2-3x/week, alternating technical-guardrail posts (credibility with technical referral partners) and human/outcome posts (credibility with small-business owners). Posting order below follows that alternation. Each links to https://reground.org/platform/. All claims are sourced from real commits/incidents in this workspace — sourced-from note under each post for your own reference; drop those notes before posting. --- ## 1. [Guardrail] The CI check that blocks a public bucket I run object storage for five small businesses. Every one of those buckets defaults to private — and there's a CI check that fails the build if a change would make one public, unless there's a comment explaining exactly why. Not a policy. Not a reminder in a wiki somewhere. A build that won't go green until you either fix it or justify it in writing, right next to the code that does it. That's the difference between "we're careful about this" and "this system will not let you be careless about this by accident." More on how I run infra for five real businesses off one server → reground.org/platform *(sourced: reground-infrastructure .gitea/workflows/tf-lint.yml + scripts/check-public-buckets.sh, ACL gate on every linode_object_storage_bucket)* --- ## 2. [Human] Meet the five businesses Right now, one hub server runs the hosting, email, and checkout for: - An author's site - A short-fiction writer's site - A small-batch soap shop - A literary press running open submissions - A small press with multiple authors Same infrastructure underneath. Completely different businesses on top. None of them think about servers, deploy keys, or database backups — because that's the whole point. Curious what "one hub, five brands" actually looks like under the hood? reground.org/platform *(sourced: reground-site content/platform.md client description; kept anonymized to match how the live page describes them)* --- ## 3. [Guardrail] A `git push` can never send an email Every content repo I run campaigns out of has the same rule baked into the tooling: pushing to the repo can only ever produce a *draft* campaign. There is no field, no flag, no config value that lets a routine content push schedule or trigger a real send. Sending for real is a separate, deliberate command. Always. On purpose. If the worst that can happen from a typo'd commit is "an unsent draft appeared," you've designed the failure mode correctly. reground.org/platform *(sourced: eec-campaigns internal/campaign/send.go — Send() only transitions draft/paused → running; sync never touches status)* --- ## 4. [Human] The soap maker doesn't know what a deploy key is And that's exactly how it should be. One of the five businesses I run infrastructure for makes small-batch cold-processed soap. She doesn't need to know what a deploy key is, what Postgres is, or how her checkout flow is hosted. She needs her site up, her orders processed, and her email list intact. The technical decisions underneath are mine to be accountable for, not hers to worry about. That's the actual service. reground.org/platform --- ## 5. [Guardrail] Scoped keys, not shared trust Each of the five sites I run has its own deploy key, and each key can only touch that one site's files — nothing else on the server. It's enforced by the key itself, not by a policy someone has to remember to follow. So if one site's repo were ever compromised, the blast radius is that one site. Not the other four. Not the shared database. Not the mail server. "Scoped" isn't a nice-to-have when you're running multiple businesses from one place — it's the entire reason it's safe to do at all. reground.org/platform *(sourced: reground-infrastructure per-site forced-command rrsync deploy keys)* --- ## 6. [Human] Why a literary press's open-submissions inbox matters to me One of the businesses I run infra for is a literary press that runs open submissions — meaning strangers' work lands in their system every week, sight unseen, from writers hoping someone reads it. That's a real trust relationship on both ends: the press trusting their infrastructure won't lose or leak someone's submission, and the writer trusting the press with something they wrote. I don't get to see the manuscripts. I just make sure the plumbing holds. reground.org/platform --- ## 7. [Guardrail] Verify after every step, not just at the end Moving a production deploy key off the root account isn't a one-commit change if you're doing it carefully. I did it in three: move the key to a dedicated account, verify the deploy still works. Fix the account's shell from a locked-down nologin to bash so the key actually functions, verify again. Remove the old root-level key, verify a final time. Three commits, three separate verifications, because "I'm pretty sure that worked" isn't good enough on a production mail server for five businesses. reground.org/platform *(sourced: eec commits 9fa7895 / 4497e4e / b8759d0)* --- ## 8. [Human] A real incident: what "unconfirmed" protected One of the five businesses I run switched their list 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 Listmonk-confirmed — could have been swept up and auto-confirmed to make the numbers look clean. Instead, those subscribers stayed exactly as `unconfirmed`, honestly reflecting what was actually true about them, while the tooling was updated to explain why. Boring is correct. Correct beats clean. reground.org/platform *(sourced: reground-tools commit f03c36a, 2026-07-22, Two Squirrels Press double opt-in)* --- ## 9. [Guardrail] Nothing that touches real subscriber data runs by default Every ops script I use that could affect real subscribers — bulk name backfills, unsubscribes, list edits — defaults to "show me what this would do." Actually doing it requires a separate `--apply` flag, every time, no exceptions. The safe path is the path of least resistance. The dangerous path takes an extra, deliberate step. That's not a coding style — it's a decision about what a mistake is allowed to cost. reground.org/platform *(sourced: reground-tools backfill-names.sh / unsubscribe-subscriber.sh dry-run-by-default, --apply required)* --- ## 10. [Human] "Generate," not "fork" Every new client site I bring on starts from a clean slate — zero inherited git history, zero leftover config from whoever came before them. Not because forking is technically hard, but because a new client's site shouldn't carry another business's commit history, secrets, or half-finished experiments into their own repo on day one. Onboarding a new business should feel like a fresh start, because it is one. reground.org/platform *(sourced: campaigns-template / eec-courses-template — Gitea "Generate Repo" pattern)* --- ## 11. [Guardrail] One engine, five brands, one fix When RFC 8058 one-click unsubscribe needed to ship, it went out to every brand I run at the same time — because it lives in one shared engine, not five separate forks that would each need the same fix applied by hand, five times, with five chances to get it slightly wrong. That's the actual payoff of "shared engine, per-brand config": a real fix is one change, verified once, live everywhere. reground.org/platform *(sourced: eec + bookshop shared RFC 8058 one-click unsubscribe rollout)* --- ## 12. [Human] What used to be four vendors is now one afternoon Before this setup, a small business selling books needed a checkout processor, a separate storefront platform, a separate ebook delivery service, and a separate email platform — four vendors, four logins, four bills, none of which talk to each other on their own. Now it's one shared service, deployed once, configured per brand, running identically for every business that uses it. Same reliability, a fraction of the moving parts. reground.org/platform *(sourced: bookshop — replaces Stripe + Shopify + BookFunnel + ConvertKit-style stacking)*