Client-First naming in Webflow: why it saves money later

Most Webflow sites look tidy on launch day. The trouble shows up a year later, when someone edits a button style and three unrelated sections change with it, or a new designer spends a morning working out which of four similar classes controls the hero. That time gets billed, and it traces back to how the classes were named during the build. A documented naming system, such as Finsweet's Client-First, is how we keep that cost down.

What is Client-First?

Client-First is a set of guidelines and strategies from Finsweet for building Webflow sites: how to name classes, how to structure pages and how to organise styles. Its goal is that anyone can read a class name and know its purpose, so names are clear and descriptive, with no abbreviations or shorthand. It is also written so a project can pass to another developer or agency, which is exactly what a client needs when their team or supplier changes.

Why does class naming affect what you pay later?

Because every class in Webflow is shared. Change a class and every element using it changes too, which is the point of classes and also the risk. When names are vague, nobody can be sure what an edit will touch, so small changes take longer and need more checking.

Webflow's own design system guidance makes the same point: when names don't make their purpose clear, team members create several classes that do the same job, which is worse for site performance and for maintenance. Webflow also adds a class automatically when you start styling an element that has none, so a quick build without rules soon fills up with names nobody chose.

Utility classes or custom classes: what's the difference?

A utility class does one global job and has no underscore in its name; a custom class belongs to one component or section and always has one. That single rule tells anyone opening the project what kind of class they are looking at.

• Utility classes, such as text-size-large or background-color-primary, give the same result wherever you apply them.
• Custom classes, such as testimonial-slider_headshot, name the group before the underscore and the element after it.
• Variants are combo classes with the is- prefix, such as button is-brand. They only work on top of their base class.

Client-First also advises against deep stacking: two classes on an element is common, three should be questioned, and by five you should create a custom class instead. Webflow adds that stacked classes can't be reordered on an element, because they become one compound selector in the published CSS.

How are pages structured?

Every page uses the same wrapper layers, so any section can be found, copied or rebuilt the same way. The default Client-First structure looks like this:

page-wrapper
  main-wrapper
    section_hero
      container-large
        (the section's content)

page-wrapper holds everything on the page, so a whole page can be copied in one go. main-wrapper uses the main tag, which helps screen readers and search engines find the main content, with the navigation and footer kept outside it. Each section_ class names its section, which keeps the Navigator readable for whoever edits the page next.

What breaks when classes are named ad hoc?

Mostly the confidence to change anything. These are the usual problems in a project without a naming system:

• An edit made for one page changes another, because two unrelated elements shared a vague class.
• Near-duplicate classes pile up, because nobody can tell which existing one is safe to reuse.
• Long class stacks build up that can't be reordered and are slow to untangle.
• Clean-ups get risky. Webflow recommends deleting unused classes regularly, but the Style selectors panel only knows how classes are used in the Designer, not in custom code, so unclear names make it hard to know what is safe to remove.

Scale makes all of this worse. On the John Deere dealer network we built, eight dealer sites run on one Webflow system with a shared component library, so a class has to mean the same thing on every site.

How do folders help on a large project?

Underscores become folders. The Finsweet Extension builds a virtual folder structure inside the Webflow Designer from class names: one underscore makes one folder, so every testimonial-slider_ class sits together, and utility classes are grouped in their own folder by the keywords in their names. On a project with hundreds of classes, that turns a long flat list into something you can browse.

Where to start

Open your project's Style selectors panel and read ten class names at random. If you can't tell what each one styles and where, the next round of changes will cost more than it should. Our Webflow websites service builds with Client-First naming, and a website review will tell you whether an existing build is worth tidying or rebuilding.