Case Study

Velaro

A premium automotive brand on the Content SDK — the first agentic pipeline run taken all the way to a published, live site: provisioned, built, authored and shipped without leaving the IDE.

Case Study5 min read

What it is

Velaro is a premium automotive brand site — "Drive Beyond Ordinary" — built on the Sitecore Content SDK against a live SitecoreAI tenant, and published to production at velaro-brand.vercel.app. No dealership, no configurator: a marketing site with the emotional register of a real car launch — a cinematic home, a five-model range, individual model pages, special editions, a brand story, and a technology narrative.

On its own it is a polished head app. What makes it a case study is that it is the first run of the full Content SDK pipeline taken all the way to a published, live site — the milestone the Umbra Roasters run set up but stopped short of. Umbra was the first complete run; it shipped with caveats. Velaro is the one that went the whole distance: provisioned, built, authored, and published to a live edge context, in a single continuous run inside the IDE.

1
site — idea to live,
one continuous run
5
model pages from
one reusable template
258
unit tests green
before ship
20
on-brand images
commissioned + reviewed

How it actually works

When the pipeline's platform_target is content-sdk, it runs a Sitecore-aware flow. The generic stages stay — architect, task breakdown, implement, review, test — and a set of Sitecore-specific stages slot in around them, owned by two agents that did not exist a few months ago.

Provision
/provision-sitecoreai · DevOps Engineer (13)

Before a line of component code, the DevOps agent stands up the decoupled cloud topology — a CM-only environment plus a separate editing host — and deploys the baseline. Non-interactive, idempotent, cascading from the first missing rung: project, environment, collection, site.

Build (delivery loop)
implement → review → test, per component

Components are built against the LIVE tenant from the first line — no mock world to drift from. Each component tranche loops implement → code-review → test before the next begins, so a break is caught on the component that caused it, not five phases later.

Author
/author-content · Content Author (14) + Content QA (07)

On-brand copy is written in a chosen voice and landed in Sitecore through the Marketer MCP — pages, datasources, children. Empty image slots are filled with commissioned, brand-reviewed imagery. A Content QA gate then confirms it rendered, not just that the write returned 200.

Publish (last)
/publish · preview-first / publish-last

Everything above happens against PREVIEW. Publishing is the single, operator-confirmed step that flips layout, content and media onto a LIVE edge context — and only then does the public Vercel host deploy against it. Nothing goes live before this gate.

That preview-first / publish-last ordering is the newest load-bearing piece. Going live is where layout items, authored content and media all have to agree on one live edge context or the site 404s. Making it a named, gated, last step — owned by the DevOps agent — is what turned "hold your breath at go-live" into a routine the pipeline just runs.

The live Velaro models page — a numbered list of five electric cars (One, S, GT, RS, X), each with range, 0–100 time and a one-word character, over cinematic photography on a near-black background.
The range page as published. Five model detail pages render from one template — a sixth car would be content, not code.

What was built

Most of Velaro is a net-new component set — built React-first, then bound to the exact Sitecore datasource contract each rendering reads. The structural decision that carries the whole range:

Pattern · One template, five machines

A single model-detail template, rendered five times

React component · Sitecore rendering · datasource contract · authored content

VELARO One, S, GT, RS and X are the same template bound to five datasources — adding a sixth is a content task, not a code change.

  • Built once, authored five times — the model-detail page (hero spec strip, narrative blocks, experience cells, keyboard-accessible gallery) is one rendering; each car is a datasource instance created on the live tenant.
  • Dark, light and system theme — hydration-safe via a useSyncExternalStore provider and a FOUC preflight; WCAG AA contrast enforced at test time in both themes, not promised.
  • Motion that behaves — reveal, parallax and kinetic headlines, all guarded on reduced-motion and a mounted flag, with base CSS keeping every element visible with no JS.
  • Bands reused across pages — one CTA band and one quote band serve the home, model, brand, technology and editions pages — no per-page chrome code.

The honest part

Velaro shipped live — but it was not frictionless, and pretending otherwise would waste the most useful part of the story. Two things went sideways mid-run. A cloud CLI token expired during provisioning and had to be refreshed before the topology finished standing up. And a genuinely awkward publishing-projection quirk on the shared tenant meant some freshly authored pages did not emit their route onto the edge — a known shape from an earlier run, worked around by recreating the pages through the content API.

Both got handled. More to the point, both got recorded — the pipeline logs what actually happened, so a skipped gate reads as skipped and "it builds" never gets to pose as "it works". The go-live itself was attended: the authored items were pulled back into the CM code base for git durability, the live edge context was wired, the public host was deployed, and an anonymous smoke plus a media-200-not-302 check confirmed the site — and its imagery — actually serve.

Mocks are faithful to types. A live tenant is faithful to reality. Velaro was built against reality from the first component.

What it proves

Proof 01

End-to-end now means published.

Umbra proved the full flow could run start to finish. Velaro moved the finish line to a live, published site — provisioning, code, content, imagery and go-live, one run, without leaving the editor. The operator owned the gates, not the labour.

Proof 02

Preview-first, publish-last.

Every stage worked against preview; a single operator-confirmed publish flipped everything to a live edge context and then deployed the public host. Go-live stopped being the scary part and became a named step the DevOps agent runs.

Proof 03

The delivery loop caught breaks early.

Building one component tranche at a time — implement, review, test, then the next — meant regressions surfaced on the component that caused them, not stacked four phases deep at smoke time.

Proof 04

Honesty is still a feature.

Two blockers, both recorded, both recovered. The pipeline reports what it verified; a stale-green never gets to pose as done, even on the run that finally went all the way live.

Proof 05

Every prior run paid for this one.

The theme system, the navigation subsystem, the data-fetch discipline, the real-tenant probe — each was a wall an earlier dogfood run hit and turned into a rule. Velaro inherited all of them, which is exactly why it went smoothly.

Proof 06

A brand, not a template.

"Apple meets Porsche" as a design brief became real copy, real imagery and a coherent five-model range — evidence the flow can carry a distinct brand voice end-to-end, not just scaffold a generic site.

Where it goes next

Velaro closes the gap Umbra opened — a Content SDK site taken all the way to live in one run. The next bet is bigger: generating a whole site and its content model from close to nothing in a single pass, until the tooling makes the provisioning half a first-class primitive. Either way it ships through the same pipeline that built Velaro, and it starts the same way every run here does — a real-tenant probe before the deep planning, and a live tenant from the first component.

There is a companion blog post telling the same story from the driver's seat, and the Content SDK flow lays out the playbook the run followed.

Related case studies