Why We Use Client-First in Webflow Development

Client-First is a free system from Finsweet for naming classes and structuring pages in Webflow. It uses clear, full-word class names, a standard page structure, and rem-based sizing so anyone can understand and update a site. At Graceful Web Studio, we use it on every Webflow build because it makes sites easier to maintain, easier to hand off, and kinder to people who resize text.

Clarity, accessibility, and long-term maintenance sit at the center of everything we build. Client-First supports all three. It gives designers, developers, and business owners a shared language, so nobody has to dig through mystery classes or cryptic shorthand to make a change.

What is Client-First in Webflow?

Client-First is a set of naming conventions, page structure rules, and organizing principles built specifically for the Webflow Designer. Finsweet created it, and it is one of the most widely used Webflow frameworks. The current release is Client-First V2.1, with V3 announced but not yet released as of October 2026. The full Client-First documentation is free.

Finsweet states the main goal plainly: empower a non-technical person to manage the website. Everything else in the system supports that goal.

What are the key features of Client-First?

• Clear class names: every class describes its purpose in full words, with no abbreviations or jargon.
• A standard core structure: the same page wrapper, section, padding, and container pattern on every page.
• Custom and utility classes: a simple rule tells you whether a class belongs to one component or can be reused anywhere.
• Rem-based sizing: sizes respond to the visitor's browser font settings.
• Strong documentation: a written guide and a free learning path that new team members can follow.

If you are still choosing a framework, our comparison of which Webflow framework to use for your next project looks at Client-First next to MAST and Lumos.

Why is Client-First built for clients, not coders?

Webflow makes visual development possible, but the real test comes after launch. Too often, a site becomes hard to manage because nobody can make sense of its classes. Client-First flips that. Its goals are to:

• Help a non-technical person manage their own site
• Remove the need to "translate" class names to understand a layout
• Cut down on developer help for every small text or image change

With Client-First, our clients aren't left guessing. They can open the Designer, find the section they want, and understand what they are looking at.

How does Client-First name classes?

Client-First sorts classes into two groups, custom classes and utility classes, and uses the underscore (_) to tell them apart.

• Custom classes contain an underscore and describe a specific component or its parts. Example: header-primary_content
• Utility classes do not contain an underscore and are reusable styling helpers. Example: text-color-primary

That one rule makes it easy to scan a class list and know right away whether you are about to change one component or every element that shares a style.

Names are written in full words that explain purpose and relationships:

• No abbreviations. You won't see .hdng-sm or .cntnr-main. You will see readable names like .heading-small or .container-main.
• No guessing. A name like .section-home-hero tells you where it lives and what it does.
• A predictable pattern. Classes start with familiar keywords, such as:
  • section-
  • container-
  • heading-
  • text-
  • button-
  • padding-, margin-, and so on

Descriptive names are predictable, and predictable names are easy to maintain. A new developer, a contractor, or the business owner can open the project and find their way around without a guided tour.

What we find when we take over Webflow sites without a naming system

A large share of our work is taking over Webflow sites that someone else built. When a site was built without a naming system, we see the same problems again and again:

• Class soup. Classes named "div-block-47," "text-block-12," and "heading 3 copy 2." Nobody can tell what any of them do without clicking through the page.
• Duplicate styles. Five or six classes that all set the same font size and color, each created because the last builder couldn't find the first one.
• Combo class chains. Long stacks of combo classes on one element, where removing one quietly breaks a layout on another page.
• Fragile edits. A client changes the padding on one section, and three other pages shift because they share an unnamed class.
• Fixed pixel sizes everywhere. Text and spacing set in pixels that don't respond to the visitor's font settings.

Every one of those problems costs time. Simple requests, like adding a section or updating a button style, take longer because we first have to figure out what each class does and what else it touches. On some sites, cleaning up the class structure is the first task before any new work can start.

A consistent system changes that math. On a Client-First build, we can find the right class in seconds, reuse existing utility classes instead of creating new ones, and make changes without fear of side effects. That means fewer billable hours for routine updates, faster turnaround, and fewer surprises. If you are inheriting a messy Webflow build, our website rebuilds and platform takeovers service can bring it into a clean structure. Once it's organized, our monthly website support and maintenance plans keep it that way.

Why does Client-First use rem units for accessibility?

In every Client-First build, including ours, we follow Finsweet's recommendation to use rem units instead of pixels. rem stands for root em. It is relative to the font size of the root <html> element, which by default comes from the visitor's browser settings.

Rem sizing is an accessibility decision. When someone increases the default font size in their browser, a rem-based layout grows with it. A pixel-based layout ignores that setting. Finsweet's sizes and rem guide explains that the Client-First rem system adapts to the user's browser font size settings, and that browser font size is an essential accessibility topic.

Rem units help a site meet two WCAG 2.2 success criteria:

• 1.4.4 Resize Text (Level AA): text can be resized up to 200% without losing content or function. Rem-based text and spacing scale together, so text grows without overlapping or getting cut off.
• 1.4.10 Reflow (Level AA): content works at a width of 320 CSS pixels without scrolling in two directions. That is roughly what a 1280 pixel wide screen looks like at 400% zoom. When breakpoints, max widths, and spacing are set in rem, layouts reflow into a single column as people zoom in instead of spilling off the screen.

Rem units alone don't guarantee either criterion. Fixed heights, text inside images, and wide tables can still break at high zoom. We test every build at 200% text size and 400% zoom to confirm. Rem sizing just makes passing those tests much more likely from the start.

To convert sizes while you build, we use the NekoCalc PX to REM converter. At the browser default of 16px, 1rem equals 16px, so 24px becomes 1.5rem.

Why does Client-First work for our studio and yours?

• For clients: it puts control back in their hands, with less hand-holding and shorter waits.
• For designers: it keeps the build organized, clean, and reusable.
• For developers: it removes guesswork and speeds up onboarding.
• For accessibility testing: clear names make inspection, testing, and remediation faster, because we can trace an issue straight to the class that causes it.

As a site grows, its class structure shouldn't fall apart. Client-First lets you add sections or pages without refactoring, bring in new contractors without confusion, and debug layouts without wading through dozens of nested, unnamed divs. We treat class naming as part of your site's long-term health, not an afterthought.

How can I learn Client-First?

If you want to learn Client-First yourself, start with Finsweet's free Client-First learning path. It is a 7-day schedule that walks through the system from the ground up. It works well for designers, developers, and in-house teams who maintain their own Webflow sites.

Frequently asked questions

Is Client-First free to use?

Yes. Client-First is free. Finsweet publishes the documentation, the learning path, and a starter cloneable project at no cost.

Does Client-First affect SEO?

Not directly. Search engines don't rank pages on class names. Client-First helps SEO indirectly: a clean structure makes it easier to keep proper heading order and semantic HTML, and faster, safer edits mean content stays current.

Can you convert an existing Webflow site to Client-First?

Yes, though it is usually done section by section. On a takeover, we often rebuild key templates in Client-First first, then move the remaining pages over as part of a rebuild or ongoing maintenance.

Is Client-First the only good Webflow framework?

No. MAST and Lumos are also strong options, and each fits a different team. We choose Client-First because its full-word naming is the easiest for business owners and new contractors to understand.

Start with a site that's easy to maintain

A clean naming system keeps your site affordable to update for years. If your current Webflow site is hard to change, our rebuilds and platform takeovers service can restructure it with Client-First and accessibility built in. Request a free project quote to get started.

Sources

• Finsweet: Client-First
• Finsweet: Client-First documentation
• Finsweet: Sizes and rem
• Finsweet: Client-First changelog
• W3C: Understanding SC 1.4.4 Resize Text
• W3C: Understanding SC 1.4.10 Reflow

Written by Crystal Scott, founder of Graceful Web Studio. Crystal is a Certified Professional in Web Accessibility (CPWA), a Section 508 Trusted Tester, and a Certified Webflow Expert with over a decade of front-end experience.