Client-First Explained: Why Your Webflow Agency Should Use It

What Client-First is

Client-First is a style system for Webflow created by Finsweet. Its own description is "a set of guidelines and strategies to help us build Webflow websites". It is not a plugin or a template you install. It is a way of naming classes, structuring pages and handling spacing that a whole team agrees on.

Finsweet frames it around four goals: be predictable, be organised, be consistent and be a good partner to the client. In short, anyone who opens the project should understand it without a briefing.

It matters most for agencies because projects change hands: from designer to developer, from agency to client, from one developer to the next.

Naming conventions: utility, custom and combo classes

Naming is the core of the system. The class strategy documentation describes three kinds of class.

• Utility classes are global and written without underscores, for example background-color-primary or text-size-large. Their values come from variables, so changing the variable changes every element that uses the class.
• Custom classes belong to a specific component, section or element and use an underscore, for example header_background-layer or team-list_headshot-wrapper. The part before the underscore is the group, the part after is the element.
• Combo classes are variants of a base class and use the is- prefix, for example button is-brand. The base class always comes first.

Names go from general to specific: text-size-large, not large-size-text. Client-First also advises against stacking many classes on one element, because it is hard to edit in the Styles panel. Instead, create one custom class that holds the combined styling.

Page structure and the spacing system

The core structure is a set of layers around the page content:

• page-wrapper around everything on the page;
• main-wrapper, ideally a <main> tag, with the nav and footer outside it;
• section_[identifier], a native Webflow section for each part of the page;
• container-large (small, medium and large containers exist) to centre content and set the maximum width.

For spacing, the spacing strategy uses one fixed scale of names for padding, margin and gap: xxtiny, xtiny, tiny, xxsmall, xsmall, small, medium, large, xlarge, xxlarge, huge, xhuge and xxhuge. A name always means the same distance, so padding-bottom-medium and gap-medium match.

In practice you rarely put margins on headings or buttons. Instead you use a spacing block (an empty div with one class such as padding-bottom-medium between two siblings) or a spacing wrapper (a div that wraps one element). It looks odd at first, but it keeps components reusable, because each instance can have its own spacing without changing the shared component.

Versions: v2, v2.1 and v3 with variables

The official changelog lists the main steps:

According to Finsweet, v3 splits variables into Base, Theme, Typography, Layout and Sizes collections. Spacing uses one class per decision, such as padding-bottom-large, instead of combining a direction class with a size class. Values can differ per breakpoint through Webflow variable modes, so you do not need extra combo classes to change spacing on tablet or mobile.

V3 is brand new at the time of writing. Many live sites run on v2 or v2.1, and the core ideas are the same: clear names, utilities for shared styles, custom classes with underscores. Check which version a project uses before you edit it, and do not mix systems inside one project.

Pros and cons

Pros

• Predictable. A developer who knows the system finds things quickly, even in a project they did not build.
• Easier handoff. Clear names help non-technical editors and the next developer. This is the main reason agencies adopt it.
• Consistency. One spacing scale and one set of utilities stop the stylesheet from filling with random values.
• Design maps to build. A Figma file with a clear scale and named styles maps almost directly to variables and classes. See Figma to Webflow handoff.
• Documented and widely used. There is public documentation, so you do not have to write your own standard.

Cons

• Learning curve. The underscore rules, spacing blocks and wrappers take some days to get used to.
• More elements in the Navigator. Wrappers and blocks add layers, which some developers dislike.
• Needs discipline. A system only works if everyone follows it. One shortcut at a time and the project drifts.
• Version differences. Moving a v2 project to v3 is a deliberate refactor, not a click.

When not to use it

I would think twice in three cases.

• The client already has a different system. If an in-house team maintains a Webflow site with its own convention, follow theirs. A consistent project in another system beats a half-converted Client-First one.
• A one-off page with a short life. A campaign page that will be deleted in a month does not need a full naming strategy, although a few clean names still help.
• Heavily bespoke experiences. Highly custom animated pages still benefit from structure, but you may adapt parts of the system rather than apply it strictly.

Even then, the useful minimum is the same: predictable names, a spacing scale and no random one-off values.

How it helps handoff to clients and other developers

For clients, the benefit is practical. Class names describe what things are, so an editor opening the Designer is less likely to break something by accident. For the next developer, the structure is familiar, so onboarding is measured in hours of reading, not days of reverse-engineering.

For agencies, this reduces risk. If your Webflow developer is unavailable, another Client-First developer can continue the project without a long briefing. That is one of the questions I recommend asking in my article about subcontracting mistakes.

A short handoff note helps too: which Client-First version the project uses, where the variables are, and any intentional deviations.

My take: why I build on Client-First

I build on Client-First (Finsweet), whether I work directly with a client or white-label for an agency. The reason is simple: I do not want my work to depend on me.

When I build in an agency's Webflow workspace and finish with a Loom walkthrough, the project should make sense to the next person who opens it. A shared naming system is the cheapest way to achieve that. It matters most on projects with CMS and many templates, such as the Big Moe Watches catalogue of 1,100+ luxury watches, which I built white-label via Landrieau Studio, or the CMS-based Stone Hedge Capital site, designed by Boldhuman.

I am also a designer, so I like when a design file already follows a clear scale. It makes the mapping to classes and variables almost mechanical. If you want to know how I work with agencies in general, see white-label Webflow development explained, or send me a project.

FAQ

Written byPeter CekanakDesigner & Webflow developer · white-label partner for agencies

I design and build Webflow sites for agencies and startups since 2018 — Client-First, GSAP, CMS and AI automations. Sites I built helped a client to a $10M exit and tripled demo requests for a SaaS.

Webflow Certified ExpertRelume ExpertClient-First