Loading
Case study
The template several of my sites are built on: clone it, edit one config file, and ship a fast, secure, SEO-complete site with a Python backend.
Rather than rebuild a site from scratch each time, I maintain a reusable Next.js and Firebase template under Second Difference Solutions and fork it per project. The site you are reading is a direct fork, and so is the marketing site I built for a home-services company.
The interesting part is not the starter files. It is that a fix made in the template can still reach a site that forked from it a year ago.
Every new site was re-solving the same problems: SEO plumbing, structured data, security headers, a design system, auth, a backend. Copy-pasting between projects meant fixes never propagated and each site drifted from every other one.
I wanted new sites to start from a hardened baseline, and I wanted a fix made once to be able to flow to every site using it.
A fork's entire visible brand comes from one config file plus a handful of CSS variables, so rebranding is a config change rather than a code change. It ships an SEO layer (metadata, sitemap, robots, dynamic OG image, and nine JSON-LD generators), security defaults (entitlement derived from Stripe-owned data, default-deny Firestore rules, HSTS and security headers), and a Python Cloud Functions backend behind the static export.
What makes it a platform rather than a folder is the upstream-sync workflow: template improvements merge down into forks while surfacing only genuine conflicts. It also carries a Claude Code agent harness (specialist agents, path-gated rules, and guard hooks) so AI-assisted work follows a process instead of improvising one each session.
The parts worth pointing at
Where the engineering decisions actually mattered.
The source is private, but the design is not. Happy to walk through the upstream-sync model or the agent harness.