TL:DR
This is part 2 of a 3 part series on MultiLaunch - an Astro Theme built by Bejamas using DatoCMS, Astro, and Vercel.
Part 1 covers the setup of the CMS, the content modeling, and the schema.
Part 2 talks about the overall editorial experience using the project and the use of plugins.
Part 3 covers the monorepo and the overall DX and deployment when working with this theme.
If you're looking for quick links to take it all for a spin, here's what you need 👇
Check out the demo here: https://astro-dato-multilaunch.vercel.app/
Fork the repo here: https://github.com/bejamas/astro-dato-multilaunch
Check out the details on the official Astro theme library here: https://astro.build/themes/details/multilaunch-multi-brand-website-template/
We also had a really nice chat with Mojtaba on his approach to the whole project, so check that out too!
With the way the CMS is set up for MultiLaunch, editors can launch a new website, pick a brand color, translate content into five languages, and go live, without touching any code. In this post, we’ll show how MultiLaunch makes that possible inside DatoCMS.
The reason why talking about the editorial experience by itself matters, is because the goal with MultiLaunch wasn’t just to make things easier for devs. It was to make launching and maintaining content across multiple brand sites a zero-stress experience for editors, too, considering that this theme was very much built from real world experiences of working with clients at that scale.
No dragging content into place. No fighting with design tools. No guessing what a field does. Just clear, structured inputs and immediate results.
This is the DatoCMS editorial layer in MultiLaunch. It’s surprisingly clean, and most of that power comes from keeping things simple and straightforward.
Working off an opinionated schema
Every brand in MultiLaunch runs off the same schema. That schema is opinionated, and that’s a good thing.
Editors don’t get a blank canvas. They get clear content types:
Homepage (made from modular blocks)
Brand info (logos, features, references, colors...)
Theme (fonts, max width, dark/light mode settings)
Layout (shared navigation, footer, etc.)
When editors add or update content, they’re not touching layout. They’re just filling in content for the system to render.
We don’t let editors define layout. They define content. That keeps everything clean.
That separation between structure and presentation is what makes MultiLaunch so easy to scale.
Flexible and Modular editing
The homepage of each brand site is built using modular blocks. These blocks are reusable and rearrangeable. Think CTAs, content sections, reviews, feature lists.
If an editor wants to change the order of sections on the homepage, they can. If they want to add a new review or a second CTA, that’s fine too.
But they’re not creating new layouts or writing any markup. They’re just stacking existing components within certain guardrails. Each block is pre-designed, pre-tested, and tied to a schema.
This way, the frontend always looks right, and the editor can never “break” the design.
To give editors even more confidence while working in the CMS, MultiLaunch includes a few visual enhancements.
The Visual Select plugin is used in content types like the contact form. Editors can choose between layout options (like vertical or horizontal forms) by selecting visual previews instead of guessing what “layout-1” or “layout-2” means.
And for more dynamic views, there’s also Web Previews, giving editors a live visual of what they’re changing.
This preview system mirrors the actual frontend. So instead of previewing a generic page, editors see exactly how their update will appear on the live site, fonts, colors, layout, everything.
On the localization side, each brand site in MultiLaunch supports multiple locales, five "out of the box" with English, French, German, Dutch, and Polish.
DatoCMS handles localization with tabs across fields. Editors can toggle between locales and add translations for any piece of content.
But instead of doing that manually, MultiLaunch also ships with the AI Translator plugin.
Here’s how it works: you write your content in English, click “Translate to all locales,” and DatoCMS generates translations across every field, product descriptions, reviews, CTAs, the whole thing.
I wrote the English content, clicked translate, and it just happened. That part honestly blew my mind.
The translations aren’t perfect, but they’re more than good enough to use as a baseline, and for teams without dedicated localization resources, this feature saves hours.
There’s also a review section powered by the Star Rating plugin. Editors can click to set ratings instead of typing numbers. Small touch, but nice UX.
Again, all of this is scoped to content and brand identity. No layout logic. No conditional zones. No DIY page building.
How content should feel
MultiLaunch works because it doesn’t pretend editors want to build the site. It assumes they want to manage content.
They want to update a description, add a new brand, tweak the homepage flow, or launch in a new market, and they want to do that without asking for dev time or touching code.
DatoCMS makes that possible here, and the editorial layer in MultiLaunch shows what good schema design, minimal plugin use, and thoughtful modeling can do.
From the editor's point of view, DatoCMS looks and feels clean. There are no unused fields, no optional overrides, no surprises.
The UI is fast. The localization tabs are intuitive. The field labels are written in plain language.
And because the schema is shared across all brands, training is basically one-and-done. Once someone knows how to edit Brand A, they can edit Brands B through Z with zero confusion.
Even onboarding someone new is quick. You don't teach them how to build pages, you show them where to edit structured content.
In the next and final post of this series, we’ll switch back perspectives to the devs to talk about the monorepo architecture, how slugs control brand deployments, why Astro was chosen, and how the entire setup was designed to be fast and easy to scale.