Add blog section (4 draft posts) and social post drafts for /platform funnel

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>

content/blog/template-dont-fork.md

@@ -0,0 +1,56 @@
+---
+title: "Template, Don't Fork: How a New Client Goes Live Without Inheriting Anyone Else's History"
+date: 2026-08-14
+draft: true
+description: "Why onboarding a new business starts from a genuinely clean slate — and why that's cheap and low-risk instead of a corner cut."
+---
+
+When a new business signs on, the easy shortcut would be to copy an existing
+client's site, swap out the branding, and call it done. It's faster to set
+up. It's also a quiet liability: that new site inherits the old one's full
+git history, whatever secrets or config might have leaked into old commits,
+and a codebase shaped by decisions made for a completely different business.
+
+Every new site I bring on instead starts from a template, generated fresh —
+not forked, not cloned. Zero inherited commit history. Zero leftover config
+from whoever came before. The skeleton — the site structure, the shared
+tooling — is identical across every client, because it's the proven,
+already-working shape. What diverges from day one is content, branding, and
+the client's own secrets, nothing else.
+
+## Why this matters more than it sounds like it should
+
+Onboarding risk is usually invisible until it isn't. A forked repo carries
+forward every decision — good or bad — that was ever made in the original
+site's history, plus whatever accumulated in there that nobody remembers is
+still there. A generated repo carries forward none of that. The new
+business gets exactly the current, proven template, with a clean history
+that's theirs alone from commit one.
+
+It also means a shared tool can be pinned to a specific, tested version per
+client, rolled out deliberately, one business at a time — instead of every
+site silently inheriting whatever the "source" repo happened to be running
+on the day it was forked.
+
+## What actually diverges between clients
+
+Looking across the five real businesses running on this setup, what's
+different from one to the next is narrow and deliberate: their content,
+their branding, their pricing, their own credentials for their own mailing
+list. What's identical is the skeleton underneath — the site structure, the
+shared engines for email and checkout, the deployment pipeline.
+
+That's what makes bringing on a new business cheap and low-risk instead of a
+bespoke project every time: there's no "figuring out this client's
+infrastructure from scratch." There's a proven shape, and a short list of
+things that actually need to be decided for them specifically.
+
+## What this means if you're considering this for your own business
+
+Onboarding you doesn't mean untangling your business from someone else's
+history, and it doesn't mean building your infrastructure from a blank
+page either. It means slotting your business into a shape that's already
+running, safely, for others — with your own data and credentials scoped
+to you, and nothing carried over that shouldn't be.
+
+More on how the whole system fits together: [/platform](/platform/).