The challenge

The CMS inside Elon's Adobe Commerce solution was not built with content editors in mind. Publishing took longer than it should. The system was complex enough that Elon hesitated to bring more people into it, and there was no practical way to automate work or reuse content elsewhere.

Elon's ambition went further than fixing the tooling. Most electronics retailers present products well and publish almost nothing around them. Elon wants to sell with guides and inspiration that help customers pick the right appliance and get the most out of it. Content like that only pays for itself if you build it once and use it in several places. The old setup could not do that.

How the selection worked

The pre-study ran in three steps.

Workshop one: objectives and requirements. Content editors and IT stakeholders mapped pain points, business objectives, content types and the key content use cases. Elon's daily reality became the evaluation criteria.

Workshop two: capability evaluation and decision signals. The criteria were grouped and prioritized: authoring experience and collaboration, content modeling and search, publishing and localization, then governance and access.

The workshops showed two problems that nobody had put into words beforehand:

1. Media management slowed editors down more than anyone had said. Assets sat in a flat folder structure with no way of seeing where each one was used. Editors avoided replacing images because they could not see which pages might break.

2. Campaign scheduling was a coordination problem. Editors could schedule a publish, but they had no view of everything going live at the same time. Each release meant checking things by hand before anyone felt confident enough to publish.

Capability scoring and comparison. Vaimo scored Sanity and two other shortlisted platforms against 62 capability dimensions in ten clusters and weighted them by what Elon had said mattered most. The written report set out the recommendation, the reasoning behind it and what the choice would mean for governance, operations and the roadmap.

Vaimo also gathered quotes from all three vendors and supported the tender on price. Each vendor then built a demo around Elon's own requirements, so what Elon saw in the room reflected how they would actually work.

Sanity’s built-in AI capabilities

Since launch, Elon’s editors have had access to three of Sanity’s AI capabilities, none of which needed custom development.

• AI Assist works inside the Studio, so editors can generate, summarize, translate and refine content in the document fields they are already working in. Instructions are set at schema level, which means editorial intent, tone and constraints are defined once per field rather than typed into a prompt every time.

• Canvas is a free-form space next to the Studio for drafting and restructuring before anything becomes a published document. It worked without any setup at launch, so editors could use it straight away for campaign copy or for reworking text they already have.

• Content Agent handles multi-step jobs: drafting a full landing page from a brief, or applying the same change across many documents at once. Basic use cases run on configuration alone. Anything fully autonomous or integration-heavy would need custom development and was not part of phase one.

For a lean team that has to publish more without hiring, these capabilities add the most value over time.

Why IT and the business were both in the room

The two sides wanted different things. IT's priorities were architectural: clean separation between dev, staging and production as well as clear boundaries between CMS and commerce, something maintainable in five years. Marketing wanted speed and independence such as previews they could trust, visibility over what was scheduled, and the ability to publish without a developer in the loop.

Nobody had to argue their corner. Because Elon's real constraint is a lean editorial team facing growing demand, editorial capability outweighed technical release tooling, and that came out of Elon's own requirements rather than a judgment call. Scoring against long-term scenarios as well as current needs meant both sides could see it holding up beyond year one.

The results

• A decision Elon can defend, with scored reasoning behind it rather than vendor preference.

• A shared set of requirements owned by IT and marketing together.

• Three vendor offers sized against real numbers rather than assumptions: user counts, environments, locales, integration scope and data residency.

• Three deliverables that guided the implementation: the workshop board, the weighted scorecard and the pre-study report.

• A launch on schedule, with the Sanity build starting in June 2026 and the webshop going live in October as planned.

Looking ahead

Implementation started in June 2026 and the webshop went live on Sanity in October, on schedule. The Vaimo team that handles Elon’s ecommerce development did the Sanity build. The team worked with the same IT and marketing stakeholders who set the requirements in the pre-study.

Phase one covered the webshop. The next phase is not fixed yet, and the architecture was planned so that adding a channel does not mean replatforming. Because the content model is built for reuse, the same content can feed mobile, in-store screens or email. The same CMS can also take on more brands when they come into scope.