Small Business Infrastructure Without the SaaS Tax
I run the hosting, email, and checkout for five small businesses off one server, by myself. Here's what that actually looks like — and a free 5-day course on why it's built this way.
Written by Will Estes, who's...
- Running the entire technical backend — hosting, email, checkout, project tracking — for five real small businesses right now, from one server.
- Built the guardrails himself: safe-by-default sends, scoped access per business, dry-run-by-default tools — so nothing dangerous happens by accident, on a good day or a bad one.
Here's what's inside
Five short emails, sent at whatever pace you want.
- Day 1. Mistake #1: Assuming “enterprise-grade” means “enterprise-sized.”
- Day 2. Mistake #2: Renting a different tool for every job because that’s what everyone uses.
- Day 3. Mistake #3: Trusting a person to be careful instead of a system that makes the mistake impossible.
- Day 4. Mistake #4: Assuming one shared server running several businesses is riskier than five separate ones.
- Day 5. Mistake #5: Waiting until something breaks to decide who’s actually responsible for keeping it running.
What five businesses running on one server actually looks like
Right now, one hub server runs the entire 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, and a small press with multiple authors. Same hosting, same email system, same checkout system, same project tracking — configured per business, but built and run once.
That one hub runs mail for every domain, the CI/CD that ships every site, the email courses and campaigns that go out under each business’s own name, a shared Postgres database, the checkout and fulfillment system behind every book and product sale, and the monitoring that watches all of it, continuously. Each business would otherwise be paying for and separately managing its own version of every one of those — its own email platform, its own checkout stack, its own hosting, its own project tool. Here, it’s one system, config-scoped per brand, watched by one person the whole time.
The guardrails that make this safe to hand to someone else
Running five businesses’ infrastructure from one place only works if a routine change can never accidentally become a real problem. A few of the specific ways that’s enforced, today, in production:
- A routine content update can never trigger a real send. Publishing changes always produces a draft. Sending something for real requires a separate, deliberate action — nothing routine can trigger it by accident.
- One business’s access can’t reach another’s. Each site’s deploy access is scoped narrowly enough that even if one were compromised, it has no path to any other business’s files or credentials.
- Anything that touches real customer data defaults to “show me what this would do,” not “do it.” Scripts that could affect real subscribers or real records require an explicit, separate flag to actually act — never the default.
- Storage that’s supposed to stay private can’t quietly become public. An automated check fails any change that would expose it, unless there’s a deliberate, documented reason attached.
None of this is exotic. It’s 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.
Is this a fit for your business?
This is built for small businesses that want their technical backend handled as one coherent thing, by someone who’s personally accountable for how the pieces fit together — not managed piecemeal across a stack of vendors who’ve never heard of each other. If that’s where you are, the 5-day course above walks through why this approach holds up, one honest mistake at a time.