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>
57 lines
2.9 KiB
Markdown
57 lines
2.9 KiB
Markdown
---
|
|
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/).
|