There are two ways to take a trip. You can head for a place with a name, knowing it's about six hours away. Or you can start driving without knowing what the place is called or when you'll get there. Both trips burn fuel. Only one of them ends somewhere.
Building a SaaS product works the same way, and the design system is what gives the destination a name. Skipping it is more tempting than ever. AI can produce a finished-looking interface in minutes, so why not build first and make it consistent later?
Because "later" is when it gets expensive. Most products don't fall apart at launch. They fall apart months afterwards, when the first feature nobody planned for needs a place to live.
This article covers what a design system actually is for a SaaS product, why a set of nice screens doesn't count as one, what yours should contain, and how to tell whether it works. The examples come from Memverr, a member management platform we built and run, currently focused on the fitness industry. It went through exactly this problem.
In short
A design system is a set of rules for where things go and how they look. It isn't a folder of finished screens.
A design that only covers your launch features will break when users ask for something new, and they will.
Build the structure around the data that changes most. In most B2B products that's a person, an account or an order.
The test of a design system is simple: add a feature you didn't plan and see if it fits without a patch.
When anyone can generate an interface, direction and identity are what's left to compete on. You can't prompt your way to either.
A design system is rules, not screens
When people hear "design", they usually picture screens: a dashboard, a settings page, a sign-up flow. Screens are the output. A design system is what produces them.
For a SaaS product, it covers three things:
Color roles. Which color is the page background, which is a card, which means "attention", which means "done". The roles matter more than the exact colors.
Rules. How structure is shown, how things are layered, how dense a table gets, what a primary action looks like. Small decisions made once, so nobody makes them again on every screen.
Overall layout. Where navigation lives, how a list page relates to a detail page, where new sections go when a page grows.
A set of screens tells you what the product looks like today. A design system tells you what a screen you haven't drawn yet should look like. That second part is the one you need once the product is live.
Why a set of nice screens isn't enough
This is the trap we fell into ourselves, even though we had a design.
Memverr went public in February 2026 with a proper version 1 design: clean, lightweight and well structured. It was built around the first set of features, the ones we expected every gym to use.
Then gyms started using it. Once people use a product, they get brave. They ask for features and for changes to how things work and look. That's good news, and many of those requests were things we had never considered. We reviewed the product every day, and something was always being added.
None of those features existed when version 1 was drawn, so their layouts didn't exist either. Every new feature needed a place, and the design had no rule for where that place should be. Screens that started tidy slowly became a patchwork of features that worked but didn't look like they belonged.
The small things added up too. We'd open a screen and ask why this background was that color, or why a card looked like that, or why a page was laid out that way. At some point we didn't enjoy using our own product.
The root cause was simple. Version 1 was made with very little SaaS experience. Its rules weren't clear or concrete, and it leaned on aesthetics. It showed what the first screens should look like and said nothing about the ones that came later.
 Memverr's first design. Clean, but built only for the features that existed at launch.
What goes wrong without one
Whether you skip the design entirely or have screens without rules, the symptoms look the same:
Every feature is designed from scratch. Each new screen reopens questions that should have been settled once, so the build slows down as the product grows.
The layout takes the hit first. New features get squeezed into whatever space is left, and the product starts to feel patched.
Consistency drifts. Colors, spacing and components slowly diverge because nothing says which version is right.
Nobody can judge new ideas. Without a direction, you can't tell whether an idea fits, so every change is a guess.
That last one applies to AI-generated design as well. When we built our own website, we let AI produce the first two drafts from start to finish. Every revision looked fine on its own, but step back and the whole thing had no identity. It felt generated, and the pieces didn't fit each other. The tool wasn't the problem. We had no direction to judge its output against. AI can make almost anything you ask for, but it can't decide what you should make. That decision needs professional judgment, and it has to come first.
"Function first" is not a reason to skip it
A fair objection: shouldn't a product work before it looks good? Yes. Our own rule is function first, aesthetics later. It's the gym principle: get healthy first, build muscle later.
There's no contradiction, because design and aesthetics aren't the same thing. Design sets direction: what the product is, how it's structured and what the rules are. Aesthetics is the last layer on top, and that's the part you can safely postpone.
Design also isn't a single step. A product always needs more work: features that are missing, things to add, things to fix. The healthy flow is a loop:
Design → build → test → revise → design → build, and around again.
Going round that loop many times is normal. The one part you can't skip is the first design, because that's where the direction gets set. Without it you're driving without a destination, and every lap makes the patchwork bigger.
What to put in a SaaS design system
You don't need a hundred pages. You need a handful of decisions that are specific enough to settle arguments. Here is what we focus on.
1. Build around the data that changes most
This decision shapes the rest. Find the thing in your product that changes all the time, and make it the center of the structure.
In Memverr's first version, payment proof and attendance each lived on their own pages, and a member's profile held only basic information. To understand one member, an owner jumped between pages.
In the redesign we went member first. Every member now has a personal panel where payments, attendance and anything else tied to their plan can be managed. Member data is what changes constantly in a gym, so the product starts from the member.
Your product's center might be a customer, a project, an order or a device. Whatever it is, when new features arrive they'll usually attach to that object, so give it room to grow.
2. Set color roles, and keep them
Decide what each surface is and never break the pattern. One of our rules in the current Memverr design: the background and the cards are always different tones, lighter behind, darker in front, on every screen. Users stop noticing the pattern, which is the point. They read the structure without thinking about it.
3. Make structure visible
Our rule is "don't be shy with lines". Structure should be drawn, not implied. In a data-heavy product, clear borders and divisions make dense screens readable and make new sections easy to add without redesigning the page around them.
4. Allow freedom, but require the same impression
A design system that makes every screen identical will fight you. Ours allows bold, exploratory layouts, as long as every screen leaves the same impression as the others. Consistency lives in the rules and the feel, not in copying one layout everywhere.
5. Pick a direction someone would recognize
"Clean and modern" isn't a direction, because almost every interface already looks like that. For the Memverr redesign we chose a modern neo brutalist style. It gave us a specific target, and it's hard to arrive at by accident. With AI making new SaaS products cheap to produce, a committed visual direction is one of the few things that visibly shows craft.
 Memverr after the redesign: member first, with rules new features can follow.
How to tell if your design system works
Add a feature you didn't plan for, and watch what happens.
If it needs a new pattern, a new color or a layout exception, the system didn't hold. If it slots into an existing place and looks like it was always there, it did.
Since Memverr's redesign we've added booking, a member activity filter, RFID check-in for coaches and coach analytics. None of these were in the redesign. Each of them found a place, because the rules already said where things go and how they should look. Under version 1, each would have been another patch.
When to redesign an existing product
If you already have a product that feels patched, the timing matters.
Memverr ran on its first design from February to August 2026, and we waited on purpose. Early on the job was to make it work: fix what broke, add what gyms asked for, and learn how they actually operate. A redesign during that stage would have been a guess about a product that was still changing every week.
We redesigned once things were stable, with error reports down and no longer arriving in waves. By then we knew what the product really was. Because the concept was clear, the redesign itself took only about two to three weeks.
So if your product is still finding its shape, stabilize it first. Once it has settled, redesign it around what you've learned, not around what you guessed at launch.
What no design system can predict
No design gets everything right up front, and it's better to plan for that than pretend otherwise.
Gyms kept surprising us. We never thought of a drop-in feature for people who don't want a membership and only visit once or twice. We didn't think of something as simple as showing how long a member has been with the gym. When they asked, our reaction was: of course, how did we miss that?
The answer isn't to design more before you build. It's to observe, test in real use, take the feedback and revise. A good design system doesn't predict every feature. It gives the features you didn't predict somewhere to go.
Before you build: a short checklist
If you're about to start a SaaS product or an internal system, make sure the design phase gives you these four things:
A feature list, including what users are likely to ask for later, not just what launch needs.
The flows, meaning how people actually move through the product.
The UI, built on a design system: color roles, rules and overall layout, sized to the scope of the project.
A build plan, so the build has a named destination and an estimate for reaching it.
Already have one or two screens? Good. Expand them into a system before you build more.
Direction is the part you can't generate
It has never been easier to make software that looks finished, so looking finished is no longer the hard part. The hard part is knowing what you're building, what fits and what doesn't. That's the job of a design system.
Name the destination first. Then build.
Layerice is a software design and development studio for businesses. We design and build B2B SaaS and internal business systems, and we start every build with a design.