Eight Brands, Six Verticals, Nine Weeks: What Happened After Velaro

Welcome back to another blog post. It has been a while — and this time the reason is a good one, because I was busy building. A lot.

As some of you know, Velaro was the first time my agent team took a whole Sitecore site from an idea to a published, live head app in one run. That felt fantastic for about two days. Then the honest question showed up, the one that always shows up after a good demo:

Okay. But can it do that again — somewhere it has never been?

Because one site is not a capability. One site is a data point, and it might just mean I built a pipeline that is very good at building that site. A flow can be quietly overfitted to the thing it grew up on and still look completely general from the inside. There is only one way to find out, and it is not more thinking.

So I did the obvious thing. I pointed it at six different industries in a row.

What I actually did

Eight brand sites. Six verticals. One shared SitecoreAI CM. About nine weeks.

A small-batch coffee roastery. A premium car marque. An insurer selling health, life, home and travel cover. A commercial spaceflight brand. An airline that publishes the air quality you will land in. A luxury property developer with per-unit schedules. A second roastery that turned out to be the hardest of the lot, for a reason nobody would guess.

Not eight variations of one template — and this is the part that matters. A vertical is not a skin. Changing it changes what a page even is. A car marque has models; a property developer has developments; an airline has routes, fare classes and a funnel that has to complete. Those are different content types, not different copy. It changes the register too — Willowmere has to sound plain-spoken because it sells insurance to worried people, and Aphelion gets to be theatrical because it sells the edge of the solar system.

Rather than describe them, here are the five I would actually put in front of someone. All live, all captured by an anonymous browser after hydration, all returning 200 — and, I hope, not obviously siblings.

Automotive

Velaro

A flagship marque, five model pages generated from one reusable page template. The first run taken all the way to a published, live site.

Insurance

Willowmere

Health, life, home and travel cover routed to a human advisor instead of a quote form — and the only one of them that leads in a light register.

Air travel

Zephira

Routes published with the air quality you will land in, and a booking funnel that actually completes. Also the build that taught the flow about authorability.

Property development

Oriel

Luxury developments with per-unit schedules — 597 items published in one scoped job against a CM already serving five live siblings.

Specialty coffee

STRECKER Roastworks

The one where the data IS the product: every coffee publishes its real roast curve, sample by sample, nothing smoothed and nothing hidden.

Two more exist and are live — Umbra Roasters and Aphelion — but they belong in a different bucket. Umbra was the first complete run taken end to end inside the IDE, and Aphelion was the one built deliberately backwards: a whole plain-React reference app first, the content model derived from it, and only then the port to a live tenant. Both were experiments that earned their keep and then taught the flow something. The five above are what I would call the results.

There is a longer, more forensic write-up of the whole portfolio in the case study if you want the receipts rather than the story.

What is actually shared, and what is not

This is the bit people get wrong about the word "multisite", so let me be precise, because the split is the entire economic argument.

Shared by all of them: the content model, the component definitions, the authoring instance, and the baseline in source control. That is the expensive half, and the next brand reuses every bit of it for free.

Different per brand: its own front end, voice, theming, imagery, content tree, authors and release cadence. Brands diverge exactly where a brand should diverge — in how it looks and what it says — and nowhere else.

If a new vertical only costs content, verticalizing is economical and you can genuinely do it eight times. If it also costs pipeline work every single time, it is a demo that happened to run repeatedly. Nine weeks in, I have the answer, and it is the first one.

The part that still makes me laugh

I expected the speed. I did not expect the floor to hold.

These are not demos. ZEPHIRA shipped with 704 unit tests and 88 end-to-end. Willowmere with 727 unit tests. Aphelion with 100 Vitest plus 85 Playwright, and 20 screenshot baselines held within 5% of the approved design, axe clean across all ten route-and-theme combinations, zero horizontal scroll at 375, 768 and 1280. Every one of them has dark, light and system theming that is hydration-safe with no flash of the wrong theme, and WCAG AA contrast asserted at test time in both themes rather than promised in a checklist somewhere.

Every one built against a real tenant, real Edge, a real content model, from the first component. Never against mocks.

The speed is fun. The part that actually matters is that the quality floor rose while the speed held.

Nine weeks, eight brands, and honestly the eighth was better than the first in every way I can measure — not because anyone worked harder on it. Which brings me to the real story.

And then every single one taught me something

Here is the uncomfortable bit, and it is also the good bit.

Every one of these sites was green when I shipped it. Tests passing, build clean, code review done, audits happy. And every one of them still had something in it that the previous site's gates simply could not have seen. Not the same thing twice. Four brands, four genuinely different blind spots, one after the other.

Willowmere — rebuilding a surface audited the shipped one

I asked for two design variants of a page that was already live. The design stage surfaced eight defects in the shipped code — including an overflow-x on body that was silently killing a sticky header.

Nobody was looking for bugs. Producing an alternative just made the current one legible. Since then I treat the design stage as a real audit rather than decoration, and I no longer feel silly asking for a variant of something that is supposedly finished.

Aphelion — the editor is a rendering surface too

Gorgeous site. Passed everything. Then I opened it in Sitecore Pages and a gradient title that was flawless in every browser fell apart, because Pages injects editing markers into the DOM and my markup had not budgeted for them.

I had been verifying the visitor's view and quietly assuming the author's view came along for free. It does not. A component is now not verified until someone has seen it inside the editor.

ZEPHIRA — it rendered beautifully, and an author could not edit it

This one stung. 704 tests, 88 end-to-end tests, four clean code reviews, a full /test pass. And 17 of 21 renderings could not be edited in Pages at all.

They rendered perfectly. They were also, from a marketer's chair, dead. My agents had fetched content through queries instead of delivering it on fields, so there was nothing for the inline editor to grab. Everything I had built was pointed at "does it render", and that is a different question from "can somebody change it".

A component is not done when it renders. It is done when an author can find its content and change it. That is a rule now, and — more importantly — a blocking audit that exits non-zero and stops the commit.

Oriel — the prose disagreed with the data

The subtlest of the four. A masthead read "Two cities. Seven buildings." while the section right below it derived "6 developments" from the actual content.

Both halves were individually correct. No test can catch that, because there is nothing wrong with either number in isolation — they simply disagree, and only a human reading the page top to bottom notices. So: never author a number that the page also derives. Say it once, in the place that knows.

STRECKER — the one where the content fought back

The four above are the ones I had when I first drafted this. Then I built one more, and it moved the bar in a different direction entirely.

Every brand so far was hard because of breadth — more page types, more components, more routes. STRECKER is hard because of one field. Its whole thesis is that the data is the product: every coffee publishes its actual roast curve, sample by sample, alongside altitude, process and a named producer. Nothing behind a login, nothing smoothed. 282 published data points across six coffees, each curve a genuine forty-to-sixty point series at one sample every ten to fifteen seconds.

Which sounds like a content problem and is really a delivery problem. Nothing in this workspace had ever pushed a real time-series through Sitecore's Edge before, and "interpolate a nice curve from four milestone fields" was ruled out in the spec as not ship-eligible — not as a fallback, not as a stopgap. Either the actual authored series survives the pipeline point for point, or the feature does not exist.

Two things came out of it that I now reach for elsewhere.

Validation belongs at authoring time, not at render time. A malformed or truncated curve is rejected when someone tries to save it, and it surfaces in preview and editing only. A live visitor sees a correct curve or no curve module at all — never an error state, and never a plausible-but-wrong one. The render-time guard is the backstop, not the mechanism. Getting that the wrong way round is how you end up showing a confident graph of nonsense.

"We did not touch anything" is not evidence. This was the ninth site on that shared CM, so the interesting risk was never the new site — it was the eight existing ones. Isolation got proved with a serialization-state export of every non-STRECKER path captured before and after, and compared. Not a dry run, not an assurance. A diff.

The moment it paid off

Four discoveries, four unrelated causes, one shape: the gate that would have caught it did not exist yet. So each time I built it. Not a guideline in a document — a script that exits 1 and blocks a merge.

That distinction is the entire mechanism. "Always use field components" written in a doc holds for about two builds. The same rule as an audit that fails the commit holds indefinitely, because nothing gets past it. Today there are three of those audits running at every tranche exit — component authorability, Sitecore schema, comment economy — plus a handful of always-on rules. And yes, each audit is deliberately broken during development to confirm the test suite notices. That sounds like overkill right up until an audit silently passes a set it never read, which happened three separate times in one script, each time reporting a confident green over nothing at all.

Then Oriel — the last of the six to start — went live and passed all six live smoke checks on the first attempt. Anonymous browser crawl after hydration, media served from the Edge CDN, nine internal destinations all returning 200, zero console errors, and 597 items published in one scoped job against a CM already hosting five other live brands, touching none of them.

That is what I mean when I say the flow got better. Not "I was more careful that time." The build could not get past the things the earlier builds had paid for.

The honest part

Two things I want to say plainly, because a post that is all wins is not worth reading.

The gate set was built out of real mistakes on real sites. Every audit 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 and not a customer's. That is exactly what a dogfood portfolio is for, and I would not have run this experiment on someone else's launch.

Two runs were blocked by the environment rather than by 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.

Where this goes next

Two directions, and they are related.

The first was packs — and by the time you read this it has shipped, so I will keep it short and point you at the whole story. Everything above was one pipeline with Sitecore knowledge spelled out inline across it; I measured 100 platform_target references across 32 files. That works fine until you want a second platform, and then adding one means editing every stage. So the domain got its own home: agents are identities, commands are tasks, packs are domains. Three composing dimensions, ten runnable combinations, seven published flows, and the field that started the whole thing is now retired with zero branches left on it anywhere.

The bit that matters for this post is what it means for the next brand. Building a ninth verticalized site is no longer "run the pipeline and hope the Sitecore parts apply" — it is a composition you name up front, and the domain arrives as data rather than as conditionals scattered through nine commands.

The second is the unattended run. Every stop in my pipeline is a token that can be switched off, and with all of them off the thing runs the whole distance by itself, live publish included. The mechanism has been there for a while. What is missing is the track record — I have not yet let a real brand go from idea to live without looking, and that has to be earned run by run, by the self-checks getting good enough that my looking adds nothing. Oriel passing every live check first time is one data point. STRECKER shipping a content contract that strict is another. It is not enough yet, and I would rather say that than pretend otherwise.

Now, is any of this the holy grail? Obviously not. It works because these are my brands, my tenant, and my willingness to find defects the hard way. Your mileage depends entirely on what you are building and how much you are prepared to let a gate tell you no.

But the thing I actually wanted to know nine weeks ago has an answer. It was not overfitted to Velaro. It got better every time I pointed it somewhere new — and it got better in a way that stays, because each lesson ended up as something that runs, not something I remember.

More to come. Stay tuned. 😉