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>
2.9 KiB
title, date, draft, description
| title | date | draft | description |
|---|---|---|---|
| Template, Don't Fork: How a New Client Goes Live Without Inheriting Anyone Else's History | 2026-08-14 | true | 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.