Client-First (Finsweet)

What Client-First actually is

Client-First is a naming and structure system for Webflow, created and released for free by the agency Finsweet. It is not a plugin, a script or a paid product. It is a documented set of conventions that tell you how to name your CSS classes, how to organize your style folders and how to structure the elements on a page so the project stays readable long after it is built. The name captures the intent: a site built this way can be handed to a client, or picked up by another developer, without a decoding session.

The founding idea is that a Webflow project is a shared document, not a private sketch. Because Webflow shows class names directly in the interface, those names become the documentation. A class called padding-global or heading-style-h2 tells you what it does at a glance, whereas a class called p1 or box3 tells you nothing. Client-First turns that difference into a repeatable standard so that every page of every project reads the same way.

How the system works

Client-First organizes styling into a small number of clear layers. At the top sit global structure classes that control layout consistency across the whole site.

• Page and section wrappers such as page-wrapper and section, which frame the overall layout.
• Container classes such as container-large or container-small, which cap content width in a predictable way.
• Global padding classes such as padding-global and the padding-section spacing helpers, which keep vertical and horizontal rhythm consistent.

Utility classes and a spacing system

Below the structural layer, Client-First relies heavily on utility classes: small, single-purpose classes you combine rather than restyle. A margin-bottom paired with a spacing value, or a text-size class, can be reused everywhere instead of inventing a new class each time. The spacing system in particular is a named scale, so a designer picks from a consistent set of gaps rather than typing arbitrary pixel values. This is what keeps a large site visually coherent and quick to adjust, because a single change to a spacing value ripples predictably across every place it is used. The convention also separates classes that carry meaning from classes that only adjust one property, which makes it obvious at a glance whether a class is structural or cosmetic.

Client-First versus BEM and other conventions

The web already had naming conventions before Client-First, the best known being BEM (Block Element Modifier). BEM was designed for hand-written CSS and HTML, where you type long, structured class names like card__title--featured to express hierarchy in the markup. It is excellent for source-code modularity but verbose to manage inside a visual builder.

Client-First borrows the spirit of BEM, readable and predictable names, but adapts it to how Webflow actually works. In Webflow you stack combo classes, you scan a class list in a side panel, and you want names that read as plain English. So Client-First favors human readability and reusable utility classes, where BEM favors strict block-scoped modularity. Neither is objectively better: BEM suits a hand-coded codebase, Client-First suits a Webflow project where the interface is the editor and the class names are the docs.

When to use it, and its limits

Client-First earns its keep on any project that will be maintained: a site with several contributors, a build that will be handed to a client, or a template meant to be reused. The larger and longer-lived the project, the more the convention pays back, because a clear structure makes adding a section six months later trivial instead of risky.

Its limits are worth naming honestly. Client-First is a convention, not a guarantee: a team can follow the folder names and still make a mess if it does not respect the spirit. It has a learning curve, and applying it half-heartedly is sometimes worse than not applying it, because it creates the appearance of order without the substance. On a tiny one-page site with a single author, the full system can be more ceremony than the project needs, though even there the naming habits do no harm.

Common mistakes and pitfalls

The most frequent mistake is treating Client-First as a coat of paint applied at the end rather than a decision made at the start. Renaming classes late in a project is tedious and error-prone. A second pitfall is over-nesting combo classes, stacking four or five classes on one element until nobody can predict which style wins. A third is inventing custom classes for things the utility system already covers, which quietly defeats the point of a shared vocabulary. Teams also forget that consistency beats purity: it is better to follow the convention imperfectly but uniformly than to mix three styles across a single site.

Client-First at BeBranded

At BeBranded, Client-First is the default build standard, not an optional extra. Every project starts from the recommended base structure: global layout classes, the named spacing scale and reusable heading styles are in place before the first section is designed. This means two people on the team build the same way, a client can update their own site without breaking styling, and another agency could take over the project without starting from zero. We treat the class names as living documentation, so the site explains itself. The payoff is not aesthetic, it is operational: faster onboarding, safer edits and a lower total cost of ownership across the life of the site. In short, Client-First is how we make maintainability a feature rather than an afterthought.