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>
3.5 KiB
title, date, draft, description
| title | date | draft | description |
|---|---|---|---|
| How I Run Infrastructure for Five Small Businesses From One Server | 2026-08-14 | true | A full walkthrough of the hub-and-spoke setup behind five real small businesses — what's shared, what's scoped per brand, and why that split is the whole point. |
Right now, one hub server runs the entire technical backend for five real small businesses. 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. Different industries, different products, different customers — same infrastructure underneath, run by one person.
This is the long version of the story I tell on /platform. Here's what "one hub, five brands" actually looks like, mechanically.
What's on the hub
One server runs:
- Mail for every domain — inbound and outbound, for every business, from one mail platform instead of five.
- The CI/CD pipeline that builds and ships every site, on every push to its own repo.
- The email courses and campaigns that go out under each business's own name and voice, from a shared engine that just happens to run five times.
- A shared Postgres database, holding each business's data in its own scope.
- The checkout and fulfillment system behind every book and product sale.
- Continuous monitoring watching all of it, all the time, instead of five separate someones checking in occasionally.
Each of those five businesses would otherwise need to find, pay for, and separately manage their own version of every single one of those pieces — their own email platform, their own checkout stack, their own hosting provider, their own monitoring. Here, it's one system, config-scoped per brand, watched by one person the whole time.
What "config-scoped" actually means
This isn't five businesses crammed into one undifferentiated system hoping nothing collides. Each business's site, mailing list, and checkout configuration are separate, brand-specific settings layered on top of the same underlying engine — not separate codebases someone has to keep in sync by hand.
When a real fix is needed — a security patch, a new feature, a bug fix — it gets written once, verified once, and it's live for every business immediately. When something is client-specific — their branding, their content, their pricing — it lives in that client's own configuration, and nowhere else.
That split is the entire value proposition: shared reliability, individual identity.
The part that actually makes this safe
None of the above works if a routine, one-line change to one business's site could somehow reach into another's, or if "shared server" quietly meant "shared risk." The thing that makes consolidation safe isn't which machine everything runs on — it's how tightly every path between the pieces is scoped. That's a big enough topic on its own that it gets its own post.
Is this the right shape for your business?
If you're currently paying for and separately managing a stack of vendors — a hosting provider, an email platform, a checkout processor, a project tool — that have never heard of each other, this is what the alternative looks like in practice: one coherent system, run by someone personally accountable for how the pieces fit together.
If that's where you are, the 5-day email course on /platform walks through why this approach holds up, one honest mistake at a time.