Managing multiple brands in Webflow without things breaking requires deliberate CMS architecture. Here's the system I use across WithU, TrvlWell, URUNN, and Mvmnt.
April 12, 2026
.webp)
At WithU, I manage Webflow platforms across multiple brands within the same company portfolio WithU itself, TrvlWell, URUNN, and Mvmnt. Each brand has its own visual identity, content strategy, and audience. But they all need to work within a shared ecosystem without stepping on each other.
This isn't a trivial problem. Webflow's CMS is powerful, but it has hard limits that you need to understand and plan around. And when you're managing multiple brands, those limits compound quickly. The difference between a CMS that scales gracefully and one that falls apart under pressure comes down to the decisions you make at the architecture stage, before a single piece of content is published.
Before you can design a CMS architecture that scales, you need to know the boundaries. On a CMS plan, you get 2,000 CMS items across 20 collections, with 60 fields per collection. On Business, that goes up to 10,000 items (expandable to 20,000) across 40 collections. Enterprise pushes it further to 60,000 items or more.
But the limits that catch most people aren't the headline numbers. It's the constraint of 5 combined reference and multi-reference fields per collection. It's the 100-item limit per collection list without pagination. It's the 20 collection lists per page. And it's the fact that you can only nest 2 collection lists on non-enterprise plans.
Knowing these limits cold and structuring around them is what separates a developer who builds sites that work now from one who builds sites that still work in two years.
For multi-brand portfolios, I use what I call a hub-and-spoke CMS architecture. There's a central Brands collection that acts as the hub, containing each brand's name, logo, primary colour, description, URL, and industry.
Every other collection references back to this hub. Projects reference which Brand they belong to. Team Members reference their Brand. Testimonials reference both a Brand and a specific Project. Services exist as their own collection with cross-brand applicability.
This structure means I can filter any collection list by Brand. A brand-specific landing page only shows projects, team members, and testimonials associated with that brand. A portfolio overview page can pull from everything. The same CMS powers both views without duplication.
When you're managing one site, inconsistent class naming is annoying. When you're managing four brands across interconnected properties, it's catastrophic. One rogue class name can cascade styling changes across components you didn't intend to touch.
I use Client-First by Finsweet as my naming system. The core principles: descriptive names with no abbreviations, underscores to separate component from element (like hero_content or navbar_link), and hyphens for multi-word descriptors (like text-color-primary). Utility classes have no underscore; custom classes use them. Everything organises into nested folders in Webflow's Styles panel.
The consistency this provides isn't just about keeping things tidy. It means any developer including future me can open any project in the portfolio and immediately understand the class structure. That's essential when you're handing off builds, onboarding collaborators, or coming back to a project after months of not touching it.
Webflow's component system replaced the old Symbols approach, and it's a significant improvement. Components support Props (exposing text, colour, link, or visibility settings per instance), Slots (placeholder elements for injecting different child content), and Variants (multiple design options like solid versus outline buttons).
For multi-brand work, I create a component library that covers the shared structural elements navigation bars, footers, card layouts, CTAs with brand-specific variations handled through props and conditional visibility. The nav component, for example, has a colour prop that matches the current brand's primary colour, and a visibility toggle for brand-specific menu items.
I also maintain a Component Hub page that displays every component with all its variants. It serves as a living style guide and makes it easy to spot inconsistencies before they reach production.
Even with clean architecture, you'll eventually bump into Webflow's CMS constraints on larger multi-brand builds. Here are the techniques I use to work around them.
Finsweet Attributes extend what the CMS can do natively. CMS Filter provides client-side filtering without page reloads. CMS Sort handles dynamic sorting. CMS Load More adds pagination. CMS Nest lets you bypass nesting limits. CMS Combine merges items from multiple collections into a single list. These are essential tools for any serious Webflow developer.
For sites that might exceed the CMS item cap, a reverse proxy architecture works well. You host each brand's site as an independent Webflow project but serve them all under one cohesive domain main site at the root, blog at /blog, portfolio at /work. Tools like Subfold or custom Cloudflare Workers make this straightforward.
Webflow migrated all sites to its next-generation CMS architecture in 2025, unlocking three layers of nested CMS data (up from one). They also launched individual CMS item publishing, which means you no longer need to republish the entire site just to update a single blog post or product listing.
New curated collection lists let editors manually search, select, and reorder CMS items a feature that makes editorial workflows dramatically smoother for multi-brand content teams.
For organisations managing multiple Webflow sites, Shared Libraries provide a centralised repository of brand-approved components, assets, variables, and styles that sync across sites within a workspace. Update a component in the library and it cascades to every connected site.
This is particularly powerful for multi-brand portfolios where shared structural elements need to stay consistent while brand-specific elements need to remain independent. I use Shared Libraries for foundational components (navigation patterns, footer layouts, form structures) while keeping brand-specific styling at the individual site level.
The technical details matter, but the real lesson from managing multi-brand Webflow portfolios is that CMS architecture is a design discipline. You're not just creating fields and collections you're designing a system that other people will need to understand, use, and maintain.
Every architectural decision should answer two questions: does this make content updates easier for non-developers, and will this still make sense when the site has ten times more content than it does today?
If the answer to both is yes, you're building something that scales.
