How to calculate the maintenance cost of the design system: what to consider

Maintaining the design system is not an unexpected expense. This is a recurring operational cost that needs to be budgeted from the moment the system is decided, as the system is a living product, not a one-time deliverable.

The framework of Sinh Vũ

In Sinh Vũ's service model, the maintenance level is set at about 15 to 30% of the project fee each year. This figure includes periodic upgrades, quarterly reviews, and support for teams when they encounter issues during shared usage.

Sinh Vũ is clear: this is Sinh Vũ's framework, not a universal market standard. Specific levels are always finalized through consultation based on the actual scope of each system, as the difference between small and large systems is significant.

Factors that determine the level

You do not need to remember a single number, but you need to understand what drives costs up or down:

• System scale: number of components (interface elements), number of tokens (shared design variables), and number of platforms covered. The larger the system, the more maintenance required.
• Number of teams and dependent products: each team using the system adds another source of questions, requests, and conflicts that need to be managed. More teams mean more coordination work.
• External contribution level: If teams are allowed to contribute components back into the common system, there needs to be someone to approve and maintain quality. More contributions mean more approvals.
• Product and platform change rhythm: When a major programming framework or browser updates, the system needs to be tested and adjusted accordingly.
• Costs are not just monetary: Maintenance also includes the time of internal stakeholders. If the business does not have someone assigned to maintain the system, the real cost will be in the gradual dilution of the system.

When to lean towards high levels, when low levels

If you continue to work with the same unit over the years, you might consider merging the maintenance fee into a larger collaboration package or deducting it from the next project, depending on the specific agreement.

Common mistakes when budgeting

• Do not set any maintenance lines: treating the system as a project that ends once delivered. This is the most common mistake. As a result, the system gradually deteriorates in silence, and by the time you realize it, the cost of redoing it has increased significantly.
• Comparing maintenance costs to zero: Instead of comparing to actual costs when each team builds their own version. Maintaining a common system is always cheaper than each team maintaining a separate version.
• Requesting a fixed number for all systems: There is no correct maintenance level for every case, as it depends on scale and the number of shared teams. A number not tied to the actual scope is unreliable.

The design system should be treated like a product: it needs a budget, an assigned owner, and ongoing care. Without maintenance, support, and care, the system will deteriorate, and maintenance will become a temporary fix.

Brad Frost, Atomic Design, Chapter 5

The viewpoint of Sinh Vũ

Sinh Vũ views maintenance as not just a cost for maintaining appearances but as an investment to keep the system from diluting. A diluted system may still exist technically, but teams have stopped trusting it and have begun to create their own versions. At that point, the business is not saving on maintenance costs but is paying a much higher price in terms of duplicated efforts and inconsistent designs.

About 15 to 30% each year sounds large compared to the number 0. But when compared to the cost each team incurs to maintain their own version, this is often a much more reasonable figure. The right question is not "how much does maintenance cost?" but "if not maintained, what are the real costs?"