Verticalized at Scale: Eight Brands, One CM
Eight brand sites across six verticals in about nine weeks, each one properly tested, themed and accessible — and each one made the flow that built the next one measurably better.
What this is
Eight brand sites, six verticals, one shared SitecoreAI CM, in about nine weeks.
Not eight variations of one template — eight genuinely different content models, visual registers and information architectures, each provisioned, built, authored, published and smoke-tested against a live tenant by the agent pipeline, with me on the gates rather than the keyboard.
Two of them have their own write-ups because they were firsts: Umbra Roasters was the first complete run taken end to end in the IDE, and Velaro was the first taken all the way to a published, live site. This is about what happened when the flow stopped being a proof of concept and started being a production line. If you would rather have the journey than the numbers, the same nine weeks are written up as a blog post.
six verticals
run to the eighth
WCAG AA at test time
flow gained on the way
Why the vertical was the axis
Velaro proved the pipeline could build a site. That is a weaker claim than it feels like, because a flow can be quietly overfitted to the one thing it was built on and still look like a general capability from the inside. The only way to find out is to point it somewhere it has no muscle memory.
So the runs that followed moved deliberately along the axis that hurts most: the vertical. And a vertical is not a skin — changing it changes what a page even is. A car marque has models; a property developer has developments with per-unit schedules; an airline has routes, fare classes and a funnel that has to complete. Those are different content types, not different copy. It changes what the visitor came to do, it changes the register — Willowmere has to sound plain-spoken because it sells insurance to worried people, Aphelion gets to be theatrical because it sells the edge of the solar system — and it changes what correct means, because an air-quality reading and a completion date are both numbers and only one of them is allowed to be approximate.
What does not change is the machinery underneath: one CM, one collection-scoped data model, one component pipeline, one gate set. That asymmetry is the entire experiment. If a new vertical only costs content, then verticalizing is economical and you can do it eight times. If it also costs pipeline work every single time, it is a demo that happens to have been run repeatedly.
Velaro
A flagship marque, with five model pages generated from one reusable page template — and the first run taken all the way to a published, live site.
Umbra Roasters
Small-batch coffee, and the first complete run taken end to end inside the IDE rather than assembled by hand.
Zephira
Routes published with the air quality you will land in, plus a booking funnel that actually completes. Also the build that taught the flow about authorability.
Willowmere
Health, life, home and travel cover, routed to a human advisor instead of a quote form — and the only one of the eight that leads in a light register.
Oriel
Luxury developments with per-unit schedules — 597 items published in one scoped job against a CM already serving five live siblings.
Aphelion
Destinations and experiences, held to 20 screenshot baselines within 5% of the approved design and axe-clean across all ten route-and-theme combinations.
Six live, two still in flight — Meridian Studio, a design studio, and Strecker Roastworks, which is deliberately a second coffee brand. Coming back to a vertical on purpose is its own test: the interesting problem there is not craft copy, it is getting a real forty-to-sixty point roast curve through Sitecore and out of Edge intact.
The part I still find slightly ridiculous
The speed is the headline, but it is the quality floor that came with it that I did not expect to hold.
These are not demos. Every one of these sites ships the things that usually get cut when a project is in a hurry:
Nine weeks, eight brands, and the honest summary is that the eighth one was better than the first in every measurable way — not because anyone worked harder on it, but because of what the seven before it had already forced into the pipeline.
The speed is fun. The part that actually matters is that the quality floor rose while the speed held.
And every single one taught me something
Here is the mechanism, and it is the reason this compounds instead of plateauing.
Every one of these sites was green when I shipped it — tests passing, build clean, review done. And every one still had something in it that the previous site's gates could not have seen. Not the same thing twice. Four different brands, four genuinely different blind spots:
Four brands, four unrelated discoveries, one shape: the gate that would have caught it did not exist yet. So it got built, and from that point on that entire class of defect became impossible rather than merely unlikely.
That is what I mean by the flow getting better. Not "we were more careful next time" — the pipeline itself gained three read-only audits that run at every tranche exit and exit non-zero on an unwaived defect, plus four always-on rules. By Oriel, quality had stopped being something I brought to a build and become something the build could not get past.
And it showed. Oriel — the last of the six to start — was the first site to pass all six live smoke checks first time: anonymous browser crawl after hydration, media served from the Edge CDN, nine internal destinations all returning 200, zero console errors. It managed that precisely because it inherited every rule the builds before it had already paid for.
What the shared CM actually costs
Running eight brands off one authoring instance is what makes this economical, and it has sharp edges worth naming — none of which I found in documentation:
- A shared rendering binds every site that uses it. A Datasource Location pinned to a hard GUID rather than a site-relative query quietly ties every brand to one brand's content tree. No test, review, build gate or serialization check catches it. On a shared CM you fork a rendering rather than mutate it.
- Serialization modules collide on conventional names. Two manifests in one directory sharing an include name abort the build — and MSBuild reports zero errors first, so it reads as a platform fault when it is yours. Nine of fifteen include names collided across six brand modules.
- Site config is Edge-context-wide, not app-wide. One brand's head app can enumerate its siblings, which is harmless until a build tries to prerender a sibling it knows nothing about.
- Scoped publishing works, and it is what makes this safe. Oriel published 597 items against a CM hosting five other live brands and touched none of them.
The honest part
Two things worth stating plainly.
The gate set was built out of real mistakes on real sites. Every audit here exists because something shipped without it. That is an effective way to learn and a poor way to plan, and the only reason it was survivable is that these are my own brands rather than a client's — which is exactly what a dogfood portfolio is for.
Two runs were blocked by environment faults rather than code. One editing host had not deployed successfully for weeks; another needed deleting and recreating after two rollout timeouts with no root cause found — both had built green on the correct commit. "Recreate the environment" is a workaround, not a diagnosis, and it is still open.
What it proves
Speed and a quality floor are not a trade here.
Eight brands in nine weeks, every one with hundreds of tests, three-state theming, measured contrast and real-tenant verification. The bar did not get negotiated down to hit the pace — which is the claim I would have been most sceptical of before doing it.
Verticalizing compounds, and the gates are why.
The eighth site was better than the first because seven builds had each converted a discovery into an automated check. The sites are the visible output; the gate set is the durable one.
Turn every finding into a check, not a guideline.
“Always use field components” in a document holds for about two builds. The same rule as a script that exits 1 holds indefinitely, because nothing merges past it. That conversion is the whole mechanism.
Share the model; do not share the instance.
Collection-scoped templates are free to reuse and are why this works at all. A shared rendering is a different animal — mutate one and every brand inherits it. Fork instead, and scope every publish.
Content is the linear cost, and always will be.
Code, components and rules amortise across brands. Words, imagery, voice and the per-site environment binding do not. Budget verticalization on the content axis — it is the one the tooling cannot flatten.
Green is scoped to the questions you asked.
Four brands shipped green with four different unnoticed defects. A passing suite is a precise statement about specific checks and reads like a general verdict on quality. Most of these gates exist because I once confused the two.
Where it goes next
The question is no longer whether the pipeline can build a brand site to a real standard. It demonstrably can, repeatedly, across six verticals, fast. The open question is whether it can do it unattended — every gate token off, idea to live, nobody watching.
The mechanism for that already exists; every stop in the pipeline is a token that can be turned off. What does not exist yet is the track record, and this is what accumulating it looks like: the last site to start was the first to pass every live check on the first attempt, because it inherited every rule the ones before it had paid for.
One data point. The two brands still in flight are the next two.
Related case studies
