---
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/).