Looking to dive in to the theme and set up your own project?
Check out MultiLaunch over on the official Astro themes library →
Now on to the good stuff 👇
Managing multiple brand websites or regional variants is one of those problems that hits different. One site becomes five. Five become fifty. Before you know it, you’re juggling different CMS setups, codebases, design systems, and dev teams, just to keep things up and running consistently.
That’s the problem Mojtaba and Bejamas wanted to solve with MultiLaunch.
If you’ve got 50 brands, you shouldn’t be building 50 different sites from scratch. MultiLaunch is about showing that it doesn’t have to be that chaotic. You’re not maintaining ten stacks. You’re maintaining one. And that changes everything.
MultiLaunch is a monorepo theme built with Astro, DatoCMS, and Vercel, designed specifically for companies that need to launch and manage multiple websites efficiently. It’s fast, flexible, and comes with the tooling and structure needed to scale across brands or markets, without scaling your tech debt.
Drawing from real-world work with clients (which we'll conveniently choose not to mention because they had the nerveeee to use another Headless CMS for the project that inspired this🫸 ), Mojtaba helped build MultiLaunch to be more than a codebase to approach multi-site architecture using modern tools that favor simplicity, speed, and future-proofing.
So we caught up with him to walk us through everything he's put together.
Scaling websites with multiple brands
Imagine a company with 5 brands. 10. 25. Ok 50 brands. Now imagine they want a landing page for each brand, each localized to one or multiple regions, each with slightly different messaging or layout tweaks.
That’s not uncommon, and it’s usually handled in the most chaotic way possible.
Different tech stacks. Different CMSs. Different vendors. Different deployment workflows. It works, until it really realllly doesn’t.
While massive enterprises might absorb the inefficiency, smaller companies, or teams trying to grow into new markets, don’t have that luxury. The operational load becomes overwhelming. Launches slow down. Teams get isolated. Costs creep up. And eventually, the inconsistency across websites starts to reflect poorly on the brand.
MultiLaunch was built to offer an alternative. One codebase. One CMS. One pipeline. Multiple outputs. Mojtaba calls it an architectural solution first, and a dev template second. It's a visual and technical proof that this kind of setup doesn’t have to be scary—or expensive.
From a dev's point of view, the value is obvious. You’re not starting from scratch every time. You’re not managing ten repos for ten brands. You don’t have to duplicate your component library or tweak CSS endlessly across isolated sites.
You get a single monorepo that handles every brand or region as a structured piece of a bigger system. That monorepo houses separate apps, one for the parent brand and others for sub-sites, alongside a shared UI package. Everything lives together. Everything is reusable. Nothing is duplicated unless it has to be.
But Mojtaba didn’t build this just for devs.
MultiLaunch is also made for content teams. Editors don’t need to think about deployment or Git. They don’t need to manage multiple logins across different CMS platforms. They work in one DatoCMS instance, with roles and permissions controlling what they can see and edit.
And because the content modeling is clean and consistent, editors can publish localized content quickly without having to understand how the underlying site is built.
The result? Faster time to market. Better brand consistency. Less internal chaos.
But why Astro, Dato, and Vercel?
MultiLaunch wouldn’t work without the right stack. And each tool in the stack plays a specific role.
Astro forms the frontend foundation. Mojtaba chose it because it’s fast, but more importantly, because it doesn’t overcomplicate things. Astro starts simple, just HTML and templates, but it scales with your needs. If you want interactivity, you get it on demand. If you want performance, it’s already there by default.
Astro is simple when you need it to be, but grows with you when your needs get complex. That’s why we picked it.
Because Astro ships zero JavaScript unless you ask for it, sites are fast. Page loads are instant. SEO scores are excellent. And for marketing pages and regional landing sites, that matters.
Psst: Our own DatoCMS website recently moved to Astro, so if you're looking for a deep dive into why we did that, check out our post on the topic.
Anyways.
DatoCMS sits at the core of the content layer for this approach. From Mojtaba’s point of view, it strikes the perfect balance between flexibility for developers and simplicity for editors. He’s used other CMSs. He’s seen the complexity.
With DatoCMS, he gets structured content, localization, roles, permissions, and previews, out of the box. The GraphQL API is straightforward. The editor interface is clean. And the plugin ecosystem makes it possible to extend the UI in smart ways.
And then there’s Vercel. Deployment is seamless. Scaling is handled automatically. Preview branches spin up instantly. From zero traffic to millions, the infrastructure doesn’t need babysitting. Mojtaba didn’t have to over-optimize anything, Vercel just works.
Together, this trio gave Bejamas exactly what they needed to build MultiLaunch. Each tool solves a part of the problem without locking you in. That flexibility was key.
OK, now let's make it about us again 💁♀️
The foundation of MultiLaunch is its content model. Everything is structured to treat the company as one system, with individual brands or regions managed as modular pieces.
Not an ad, Mojtaba. Not an ad 😘
Anyways. Moving on.
At the top level, there’s a home model representing the parent brand. Then, there’s a brand model for each sub-brand or market site. Each brand model includes fields for products, reviews, forms, and any other content unique to that brand.
There’s also a layout and theme model that lets editors define how each site should look and behave, whether it’s colors, structure, or layout options.
Mojtaba deliberately kept the schema really simple and straightforward. The point was to make the architecture clear and understandable for teams evaluating how to scale content operations. He wanted teams to look at the schema and immediately see how the pieces connect.
It’s not abstract. It’s practical.
I’ve worked with a lot of CMSs, and DatoCMS is the one I’d hand to a non-technical editor without hesitation.
And while the content model provides structure, the plugin ecosystem is what makes the editorial experience actually enjoyable.
Mojtaba used four main plugins in MultiLaunch, each with a clear purpose.
Visual Select was used to give editors layout choices without digging through dropdowns. If a contact form had a horizontal and vertical variation, editors could preview both and pick the one they wanted visually. No guesswork.
The Visual Select plugin is one of my favorites. It gives editors real layout control without overwhelming them.
Star Rating Editor came in for the reviews component. Instead of typing in numbers, editors just clicked the appropriate number of stars. Small touch, but a big improvement in usability.
Web Preview was a must. Editors need to see how content looks before publishing, and DatoCMS’s live preview integration made that seamless with frontend visibility right in the CMS.
Then there’s the AI Translator plugin. This one, according to Mojtaba, saved him a lot of pain. During development, as the content model evolved, he had to reset and restructure content multiple times. Since the template supported five languages, that meant hours of re-entering data.
The AI Translator plugin saved me a lot of tears. When you restructure content models mid-project, it’s a lifesaver.
With the translator plugin, it became a one-click process. Users could populate translated versions instantly using OpenAI or DeepL. And while the translations aren’t always perfect, they’re more than enough to start. Teams can tweak them later if needed.
The combination of structured modeling and plugin enhancements made the template feel polished, not just functional.
Peeking under the hood
Behind the scenes, MultiLaunch is built as a monorepo.
Everything lives in one codebase. That includes the Core app for the main brand, the Brands app for regional sites, and a shared UI package with all the components.
The UI package is one of the most important pieces. It keeps design consistent across every site. It also lays the groundwork for a future design system. Instead of rebuilding nav bars, hero sections, or forms for each site, everything is shared—and can be styled or extended per brand if needed.
Mojtaba didn’t try to over-engineer the structure. The goal was to make it easy to understand, easy to duplicate, and easy to extend. Whether you’re launching two sites or twenty, you don’t need to rethink how things are built.
Whipping up a new brand? Simply add the brand slug into Vercel as a new variable, and you've got everything set up.
And speaking of Vercel...
Deployment is handled entirely through there. You push your code, and the site goes live. You publish content, and DatoCMS triggers a build.
Astro’s static site generation keeps build times fast and output lightweight. Because it’s static, there’s very little to optimize, it’s fast by default.
With Astro and Vercel, performance just happens. I didn’t have to fight to make the site fast—it was fast from day one.
Still, Mojtaba put in some work on the details.
To prevent layout shifts, he pulled image width and height into the frontend. That improved Core Web Vitals and made pages feel smoother. He also added a smart image-switching component that lets editors upload light and dark mode versions of the same asset, switching them based on the site’s theme.
Again, small touches, big result.
From dev to deploy, the entire workflow is meant to feel clean. It’s not trying to be fancy—it’s trying to be usable. And it is.
At its core, MultiLaunch is about solving problems that nearly every mid-sized digital team faces. Launching new sites takes too long. Editors don’t have a consistent experience. Teams get fragmented. And the complexity gets out of hand.
MultiLaunch answers that with a simple proposition: keep the architecture tight, the tools flexible, and the workflows smooth.
Everything from content modeling, to plugin selection, to frontend stack was picked to support that idea. You’re not fighting the CMS. You’re not duplicating work. You’re not maintaining five different stacks.
You’re shipping content faster. You’re managing growth. You’re staying consistent across regions and brands. And you're doing it without adding unnecessary overhead.
That’s the real power of this project. It’s not flashy for the sake of it. It’s practical, reusable, and battle-tested.
So, if you’re running more than one website, or plan to, it’s probably worth checking out MultiLaunch and giving it a go.