Three Brands, One Playbook: What Transferred and What Didn't

Three builds, three verticals, one set of machinery. This page is the cross-case receipt: what stayed identical across an insurance lead-gen build, an auto-finance rebuild on a live-traffic domain, and a car-leasing site that shipped its data layer first — and what had to be built again from nothing every single time [our data].

Every date below comes from the source repos' git logs and every count from committed ledgers or extraction reports. Nothing here is projected, and nothing here is a traffic figure.

What was the situation across the three builds?

Three different problems that the same system had to survive [our data]. The insurance build was greenfield: no domain history, no brand, a YMYL vertical, and a content library that had to exist before anything else could. The auto-finance build was a migration onto a domain with live lead flow that could not be interrupted, a WordPress funnel that could not be frozen, and inherited trust liabilities to clear first. The car-leasing build inverted the usual order: perishable offer data had to earn its keep before any evergreen content existed, because lease programs rotate monthly and a static library alone would rot into bait.

Two countries, two regulatory regimes, and three deployment situations. If the engine were really a set of niche-specific tricks, this is where it would have broken.

What stayed identical across all three?

The structural parts — none of which encode anything about a vertical [our data].

Google's May 2025 guidance on AI experiences is a useful sanity check on why this generalizes: it describes the same technical fundamentals — crawlable, indexable, useful pages — rather than a separate content system per topic (Google, succeeding in AI search). A machine built to enforce fundamentals has nothing vertical-specific in it to break.

What did the timelines actually show?

Here is the comparison, from git [our data]:

The row that surprised us was GSC. Search Console returned mineable query data on day 4 of a domain that did not exist a week earlier, which is early enough that query-gap pages shipped inside the first week. The migration build hit it on day 6 despite having years of history — history helped less than we expected.

What had to be rebuilt for every vertical?

Three things, every time, with no reuse at all [our data].

The demand research. The auto-finance build synthesized ten parallel single-lens research documents — roughly 3,000 lines, including 280 categorized questions — into one playbook on the same day its first code was committed. None of that transferred from the insurance build, because none of it was about the machinery.

The approved-anchors list. Each build maintains its own set of sources writers may cite without re-verification, plus a do-not-publish list of plausible-sounding figures that failed verification. A source list is a vertical artifact by definition.

The compliance rails. The insurance build appends deterministic disclaimers in code rather than trusting a prompt. The leasing build runs a contextual poison-pattern gate, where a figure fails only when its mandatory framing is absent from the same page — a design that came out of a blunt earlier gate blocking honest debunk pages. Neither rail means anything in the other vertical.

A fourth thing had to be invented rather than rebuilt. The car-leasing build's offers expire monthly, so a static library alone would have rotted into bait, and the answer was a two-layer split the other builds never needed: perishable numbers live in a data board with verification and expiry, evergreen mechanics live in gated static content, and the content links the board instead of restating its figures [our data]. That doctrine came out of one vertical's constraint and now travels with the playbook — which is how the transferable set grows.

The lesson we would give a buyer is the uncomfortable one: the transferable part is the cheap part to run and the expensive part to build once. The per-vertical part is where every new engagement spends its money, every time. An agency pitch that implies otherwise is describing the reusable half of the work and quietly charging for the half that never repeats.

What outcomes are missing from this record?

Traffic and revenue — deliberately, because we do not have figures we would defend. The builds are weeks old. What the git histories and committed ledgers prove is build velocity and factual integrity: a five-cluster map in 2 days, 445 claims audited with 40 corrections and 0 fabrications, 461 payment figures recomputed with 1 propagated error found [our data]. Those are the honest artifacts, and the detail behind them lives in what three fact audits caught.

We could publish a growth multiplier the way this industry usually does. We would be inventing it. Nobody can promise rankings, citations or traffic from any of this, and a case study that quietly implies otherwise is the thing we built the content contract to prevent.

What is the generalizable rule?

Velocity comes from the contract, not from typing speed. All 3 builds hit their content maps in days because one frontmatter block drives every downstream surface and gates enforce it — the slow work of research, contract and gate design happens once, first, before page one. The day-by-day view of what that speed looks and breaks like is publishing 100+ pages in a week, and the budget shape behind a library at this scale is in what a 200-page library costs.

The second rule is that the audit is not optional and does not scale away: 3 builds, 3 audits, 3 sets of real defects the automated gates had missed. And the third is the one this page exists to test — the engine transfers, the vertical does not. What you can reuse is the system, which is documented in full as the authority engine; what you rebuild every time is everything that makes the system say something true about a specific market, and that reconstruction is the part of GEO nobody can skip.