Think twice before choosing Client-First for your next build.

First of all. Deep respect to the Finsweet team. They are the major Webflow community contributor. They have a proven track record delivering top quality products to boost our Webflow builds. With this history, there is no surprise on the huge adaption of their framework for Webflow, Client-First.

Why Client-First Became the "Standard"

There are three main factors that make Client-First some sort of “standard” when building in Webflow.

• People were struggling for a long time to keep consistency on their Webflow builds. Client-First is the first thorough guide explaining on how things could be done in Webflow, beyond HTML and CSS basics already covered in Webflow University and other resources. This was and still is of huge value, specially for those who are relatively new to the platform.
• People were already using other Finsweet products that worked as a charm. Attributes for example. So having the name Finsweet on it is a guarantee that must be good.
• From a marketing perspective, Client-First as a name is extremely on point (this appreciation was made by Corey Moen in one of our calls). One of the biggest challenges we Webflow professionals face is transferring the ownership of our builds to the final client. If Client-First resolves this challenge or not needs to be addressed on another article
  

This three things have made Client-First adoption huge in the Webflow space. To the point that has become the default choice. Where people blindly use it without questioning if it is the right framework for a specific project or the mental model of the person using it.

Issues with Client-First Mindset

There are two foundational points that heavily impact on the Client-First “mindset” and shouldn’t be taken lightly.

• Advocacy for free and frequent class creation
• Openness to client random requests.
  

While these two might sound good as simple stated, there are underlying problems that we can run into.

More classes means more things to manage

‍‍As simple as that. When you have more of something, there is more effort invested on managing them.

Propitiate redundant classes and/or styles

When creating new classes is the predominant approach, the likelihood of having redundant classes and styles increases. This directly impacts the scalability and maintainability of the project. Needing to go through different classes updating values.

Weaker design system or visual language

Relying heavily on custom classes opens the door to CSS properties with values close to each other. As the project grows, the solidity of the initial design system dilutes.

An increased feeling of “heaviness”

Too many classes can led to an overwhelming feeling of having lost the control of the project

Loss of project manageability

The way client requests are handled can determine whether the project becomes an unmanageable challenge. In front of a random client request we should have a solid system defined by design that informs the creation and update of UI components.

Uncontrolled brand evolution

By allowing for random requests, we are letting a brand’s visual identity evolve in uncontrolled ways. This might not have a huge impact on small shops that don’t put much effort on their brand. But, as we work with more established companies, it could really impact on how a solid brand is perceived.

Create your own Client-First version

Client first is a super-well documented framework. It is a good starting specially if you don’t have a framework in place. You can build very fast with all the resources around it_ Client-First starting templates and the Relume Library which is built upon the naming conventions and strategies behind this framework.

But once delivered, and with more attention on bigger projects, the strategies and mindset behind Client-First are not the best approach to keep scaling a site in a controlled and logical way. That being said, you can create some constraints around the out-of-the-box version of Client-First to overcome the mentioned problems.

• Define deeper rules on how and when to use custom classes
• Be really careful about client requests and how to handle them from a design system and visual identity perspective. If you onboard your client early on the system you are building for there, it will make conversation around this topic  much easier further down the line.
• Laverage Webflow components and content overrides. Webflow is putting huge efforts on this part of the tool and will keep getting better and flexible.
  

Whatever framework you choose, after you get comfortable with it, it is a good ideo to question what does and doesn’t work for you. From there, create you own version.

Happy Webflow building!