Design System for Startups: One Kit for Web, App and Extension

A design system for startups should be small, built from the decisions you keep repeating, and shared by every surface your team ships. At ViewStats, the creator platform built by the team behind MrBeast, I created and evolved one system for the web platform, the mobile app, marketing pages and a Chrome extension. It started with foundations (typography, color, variables and color tokens), then the patterns the product used everywhere: navigation, data visualization, dashboard components, tables, forms, empty states, mobile patterns and growth experiences. Later I shipped parts of it as React components myself. My advice: do not start with a component library. Start with the tokens and the three or four patterns that already appear on more than one surface.

This is a use case, not a theory piece. Here is the context, the problem, the decisions, what came out of it and what you can reuse on your own product this month.

The context: four surfaces, one fast product

ViewStats grew into a creator workflow platform around research, discovery, validation and execution. I designed or improved Outliers, Competitors Tracking, Alerts, Collections, Thumbnail Research, A/B Testing, the Creator Dashboard, the mobile app, AI workflows and the Chrome extension. That list matters for this story, because each of those lived on a different surface with different constraints.

The web platform was for deep research. The mobile app was for the in-between moments, between uploads, shoots and edits. The Chrome extension put insights inside YouTube itself, so it had to sit next to someone else's interface without fighting it. Marketing pages had to sell the product to creators who had never used it. The full story of each surface is in the ViewStats creator tools case study.

The product also moved fast. The AI creator tools went from concept to launch in roughly two weeks, with most core experiences designed, reviewed and shipped within a few days while engineering worked in parallel. A startup that ships at that speed does not have time for a design system that needs a committee.

The problem: consistency broke as the product grew

As ViewStats expanded, keeping things consistent became harder. That is the honest version, and it is the version almost every startup lives through. Nobody decides to make three slightly different tables. It happens because three people solved the same problem on three surfaces in the same week.

For users, inconsistency is not an aesthetic issue. A creator who learns how a ranking table works on the web expects the same logic in the extension and on their phone. When the column order, the colors of a change, or the empty state differ, they have to learn the product again. In a data-heavy product, that cost adds up fast. I wrote about the bigger version of this lesson in dashboard UX best practices: creators wanted clarity, not more charts. Consistency is part of clarity.

For the team, inconsistency is design debt. Every new feature starts with "which version of the card do we use?" and every engineer rebuilds something that already exists.

The design decisions behind the design system for startups

I did not set out to build a big library. The system was built to support faster product development, and its scope came from what the product actually repeated. Here is what it covered and why each part earned its place.

Foundations first: type, color, variables and tokens

Typography, color, and variables with color tokens came first, because they are the cheapest decisions to share and the most expensive to fix later. A token for "positive change" or "surface background" means the web, the app and the extension can all change together. If you only do one thing this quarter, do this. Figma's guide to variables is the practical starting point, and the Design Tokens Community Group is where the shared format for tokens is being defined.

Product patterns before decoration

The next layer was the patterns a creator analytics product cannot live without: navigation, data visualization, dashboard components, tables and forms. These are where users spend their time. A beautiful button matters less than a table that reads the same way everywhere.

Empty states and growth experiences as part of the system

Most startup systems forget these two. At ViewStats they were core. Empty states, onboarding moments and contextual prompts were how we raised creator channel connection from 13% to 65%+, by showing value first and asking for trust second. If those patterns live outside the system, every team invents its own, and the message gets weaker. You can read that use case in onboarding UX best practices from a 13% to 65% fix.

Mobile patterns that are not shrunken web

The mobile app had to serve free users and Pro subscribers, keeping premium tools visible enough to show value without making the product feel locked. Mobile patterns had their own place in the system for that reason. A shared token set does not mean shared layouts.

A simple map: what to build first

This is the order I would recommend to a startup today, based on what that system covered. It is my advice, not a rule.

Layer	What it includes	When a startup needs it
Foundations	Typography, color, variables and tokens	Day one, even with one designer and one surface
Core product patterns	Navigation, tables, forms, dashboard components	As soon as a second surface or a second designer appears
Data visualization	Chart styles, change colors, ranking and comparison views	When data is the product, not a side feature
Empty states and growth	Onboarding moments, contextual prompts, upgrade moments	Before your first activation or conversion push
Platform patterns	Mobile patterns, extension constraints, marketing blocks	When a surface has rules the others do not
Coded components	React components that match the Figma source	When designers can ship code, or the team keeps rebuilding the same piece

The result: less design debt, faster shipping

The published result is that the design system was established across products, it helped reduce design debt, improved consistency, and significantly accelerated both design and development workflows. I am not going to put a made-up percentage on that. What I can say is what it enabled next.

As the company grew, my role expanded into design engineering. Using Cursor, Claude Code, React, TypeScript and GitHub, I started delivering production-ready components directly to engineering: design the experience, prototype the interaction, build the React component, open the pull request, review the implementation. That only works when the system underneath is clear. A designer opening pull requests against a messy codebase with no shared tokens just adds a fourth version of the card. With a system, the component I designed is the component that ships. I explain that shift in what a design engineer is in software.

The same logic applies to AI tools now. When an agent reads your Figma file, clean tokens and grouped layers come out clean in code. That is why I paid attention when Figma AI icons started coming out as editable strokes: AI output is only useful if it can enter your system.

What you can reuse on your own product

• Audit before you build. List every pattern that appears on two or more surfaces. That list is your first system, not a template from the internet.
• Name tokens by meaning. "Positive change" survives a rebrand. "Green 500" does not.
• Put empty states in the system. They are where trust is won or lost in a new product.
• Let each platform keep its rules. Share tokens and logic, not layouts. An extension inside YouTube is not a small web app.
• Close the loop in code. If nobody turns the system into real components, it is a picture of a system.

Where this does not apply: if you are pre-product-market fit with one screen and one designer, skip the library. Set up type and color tokens, then go talk to users. A system protects decisions. You need to have made some first.

Design system for startups FAQ

When should a startup build a design system?

Start the foundations (type, color, tokens) on day one, because they cost almost nothing. Build shared components when a second surface or a second designer appears, which is usually when inconsistency starts to show up in front of users.

Does a startup design system need to be coded?

Eventually, yes. A Figma-only system still drifts from production. At ViewStats the step that made the system pay off was shipping React components that matched the Figma source, so design and code stayed one thing.

How big should a startup design system be?

As big as what your product repeats, and no bigger. Ours covered foundations, core product patterns, data visualization, empty states, mobile patterns and growth experiences, because a data product across four surfaces repeated all of them.

Can one design system cover web, mobile and a browser extension?

Yes, if you share foundations and logic and let each platform keep its own layout rules. That is how one system served the ViewStats web platform, mobile app, marketing pages and Chrome extension. More on the extension side in Chrome extension UX design.

Need a design system that ships, not just a Figma file?

I design systems and then build the components that use them. If your startup has outgrown its first screens, work with me as your product designer. You can also see my product design work, or the AI experiments where I design and ship the code, including motion and sound.