Add /platform devops funnel, point homepage Technical Help link at it

Reuses the existing courses/single template so this doubles as both the
value-validation case study and the small-business-infrastructure email
course opt-in. /devops stays live as the direct contact-form path, just
no longer linked from the homepage.

content/_index.md

@@ -13,6 +13,6 @@ description: "DevOps consulting, ghostwriting, and helping fiction authors find
 ## Technical Help
 
 - Enterprise-grade reliability for small
-  businesses, without the overhead. [See how](/devops/).
+  businesses, without the overhead. [See how](/platform/).
 
 Will Estes lives outside Atlanta with his children and one very opinionated cat. He plays classical guitar and listens to country music. His favorite season is soup season. The mark by the site name is traced from a piece of petrified root wood he keeps on his desk.

content/platform.md

@@ -0,0 +1,52 @@
+---
+title: "Small Business Infrastructure Without the SaaS Tax"
+description: "Enterprise-grade reliability for small businesses, without the overhead — see how it actually works, then get the 5-day email course explaining why."
+type: "courses"
+eec_slug: "small-business-infrastructure"
+
+hero_subhead: "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."
+
+cta_text: "Get me started"
+
+credibility_heading: "Written by Will Estes, who's..."
+credibility_bullets:
+  - "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."
+
+curriculum_heading: "Here's what's inside"
+curriculum_intro: "Five short emails, sent at whatever pace you want."
+curriculum_items:
+  - label: "Day 1."
+    text: "Mistake #1: Assuming \"enterprise-grade\" means \"enterprise-sized.\""
+  - label: "Day 2."
+    text: "Mistake #2: Renting a different tool for every job because that's what everyone uses."
+  - label: "Day 3."
+    text: "Mistake #3: Trusting a person to be careful instead of a system that makes the mistake impossible."
+  - label: "Day 4."
+    text: "Mistake #4: Assuming one shared server running several businesses is riskier than five separate ones."
+  - label: "Day 5."
+    text: "Mistake #5: Waiting until something breaks to decide who's actually responsible for keeping it running."
+
+repeat_cta_heading: "Ready to see how this could work for you?"
+---
+
+## 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.