Why we rely on Client-First and how it shapes our Webflow workflow
Hi! My name is Artyom, and I’ve been building in Webflow for nearly 9 years. Over that time, I’ve tested various naming systems and strategies for organizing large-scale projects. But today, I want to focus entirely on the one approach we actually rely on in production: Client-First.
How It All Started
Back in the day, I came from classic frontend — JavaScript, CSS, and HTML. Naturally, I picked up BEM (Block Element Modifier) early on. It made sense: clean, modular, readable. But then I transitioned fully into Webflow — and that’s when BEM started to fall apart.
Why BEM Doesn’t Work Well in Webflow
Combo classes in Webflow are a trap. If you assign several classes to an element and need to change the second one — good luck. You’ll need to strip everything after it, edit, then rebuild the chain. If the class is unique, that’s even worse.
The result? BEM becomes rigid, error-prone, and a blocker to fast iteration. We dropped it.
Enter Client-First — the Webflow-Friendly Solution
When Client-First arrived, it clicked instantly. It felt like someone rebuilt BEM specifically for Webflow — with all of its quirks and strengths in mind. No more worrying about class order. No more breaking the cascade. Everything was modular, human-readable, and scalable.
We didn’t just adopt it — we adapted it.
Our Lean Take on Client-First
Truth is, Client-First is powerful — maybe too powerful for most projects. So we simplified. We stripped it down to just what we need: a solid naming system, predictable structure, reusable components, and global utility classes.
We use the Relume Client-First template as our base — not just for consistency, but because it keeps us ready. If a project suddenly requires components from Relume’s library, we’re good to go. That level of flexibility is a huge win when dealing with fast-moving clients or evolving designs.
It’s clean. It’s fast. It works.
📌 Useful Links:
Artem Kopytok
{wf-dev} kopytok
