SaaS startups need to clearly separate the fixed brand elements (color, font, voice, name) from the flexible brand elements (feature interface, page layout, launch messaging). When these two layers are designed separately from the beginning, the product team can continuously update without unintentionally disrupting what customers have memorized. This is not a creative issue but a system architecture issue.
In this article · 5 sections
SaaS startups have a characteristic that most other industries do not: the product changes while customers are using it. A new feature every month, a new interface every quarter, and potentially a different market direction every year. This is both a competitive advantage and the reason many startups find that after three years, their brand looks like four different companies.
The issue isn’t about changing a lot or a little. The problem lies in the fact that most product teams cannot distinguish which parts of the brand are allowed to change and which are not.
Why SaaS easily loses its foundation
In most industries, the brand and product are two separate entities. A beverage company can change flavors without touching the packaging. A fashion house can launch a new collection without changing the logo. But with SaaS, the product is where the brand appears every day, directly on the user's screen.
When the design team updates a button color to increase the conversion rate (the share of users who take the desired action), when the marketing team uses a new tone for a feature launch campaign, when the sales team builds its own slides in a different font because the old design kit "looks unprofessional", all of it happens in parallel and no one sees the full picture. After a year, the brand identity has drifted a long way, and no single decision caused it.
What this number indicates is that the problem isn’t a lack of guidelines. The problem is that the guidelines do not operate at the actual working pace of the SaaS team.
Two layers of brand need to be separated
Sinh Vũ's approach to digital products is to divide the brand system into two clear layers, with different rules for each layer.
The first layer is the fixed part, consisting of elements that customers use to recognize the brand even without looking at the logo: primary color, font family, product and feature naming conventions, tone in announcements and documents, and how the brand appears at the most important touchpoints (places where customers encounter the brand) such as the login page, transactional emails, and error messages.
The second layer is the flexible part, consisting of elements that need to change with each feature, each launch, and each customer segment: secondary colors for new modules, layout for feature introduction pages, update announcement templates, specific tones in user manuals.
When these two layers are clearly separated from the start, the product team knows where it is free to act and where it needs to ask. There is no need for a meeting on every small design decision, but no one will accidentally change the primary color because it "suits the new feature better".
Design token: one place to change, everywhere to
For digital products, there is a technical tool that helps the fixed layer truly remain fixed: design token. This is a way to store values like colors, font sizes, and spacing in one place, so when changes are needed, the entire product updates simultaneously without having to fix each screen individually.
Salesforce and Google Material Design have used this approach at the scale of millions of users. But the principle applies fully to startups from five people up. The setup cost is a one-time cost, and the cost of maintenance is far lower than the cost of unsynchronized fixes that accumulate month after month.
Brand equity only builds up when identity signals are repeated consistently. Consistency is not aesthetics, it is a memory mechanism.
Jenni Romaniuk, Building Distinctive Brand Assets, 2018
Old customers: an asset easily forgotten
SaaS startups often focus their feature launch messaging on potential customers. But current users also read those announcements, and they read them with a different mindset: they are checking whether the product they are paying for is heading in the right direction.
When an update notice is written in a technical style ("version 3.2.1: fixed bug in API endpoint, added new dashboard module"), users don't see a brand, they see a patch. When that notice is written in a true brand language, in the voice you have built, users see that the team behind the product is working with intent.
The difference is not just in the wording. It’s a signal to users that the company knows where it is headed.
When to update the system
Not every change needs to touch the fixed layer. However, there are times when the brand system needs to be intentionally reviewed, rather than patching up each spot.
- When the product expands into a new customer segment that is significantly different from the original.
- When the design and content team is so large that no one has a grasp of the entire system.
- When you notice design assets across different channels starting to look like they come from multiple different companies.
- When preparing to raise funds and realizing that the current brand does not accurately reflect the scale and direction ahead.
During those times, the task is not to redesign from scratch. Often, it’s just necessary to revisit the two layers of branding, confirm what still holds true and what needs upgrading, and then clarify the documentation.
A SaaS brand doesn't need to be unchanging, but it needs a system for changing on purpose. Without a system, every small decision adds up to a large gap between the brand you are building and the brand your customers actually see.
References
Marty Neumeier, The Brand Gap (2003). Byron Sharp, How Brands Grow (2010). Jenni Romaniuk, Building Distinctive Brand Assets (2018). Marq (Lucidpress) / Demand Metric, Brand Consistency Report (2019). Adobe, Content Authenticity & Brand Report (2022). Google Material Design 3, Design Token Specification (2022). Salesforce Lightning Design System, Token Architecture (2023).
