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>
220 lines
8.0 KiB
Markdown
220 lines
8.0 KiB
Markdown
# 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)*
|