When founders or product heads describe their product as “complex,” they rarely mean the business logic.
They usually mean the UX is buckling.
New features take longer to ship.
The interface feels inconsistent.
Users are getting lost – and support calls are rising.
But here’s the truth: most products in this state aren’t actually too complex.
They’re just not modular yet.
What Complexity Really Feels Like
It shows up as:
- Teams rebuilding the same component five slightly different ways.
- New flows that break old patterns without meaning to.
- A backlog full of UX tweaks that never feel worth prioritising.
- Copy that shifts voice mid-journey because no one owns the language.
The real problem isn’t scale. It’s a lack of structure.
Not a big design system – just a set of shared rules the product can build on.
Why Most Design Systems Don’t Work at This Stage
For small SaaS teams, full-blown design systems are usually overkill:
- No one has time to maintain them.
- The codebase is still evolving.
- The product is shipping weekly, not quarterly.
What’s needed instead isn’t systemisation – it’s modular thinking.
A mindset, not a framework.
What Modularity Looks Like (Practically)
1. Repeatable Flows, Not Just Reusable Components
A button isn’t a pattern. A flow is. Instead of designing screens in isolation, modular UX builds around outcomes:
- “How do users add something?”
- “How do they undo?”
- “Where do they go after success?”
2. A Clear Vocabulary
Start small. Agree on the names of things. If your product calls the same thing a “workspace,” a “dashboard,” and a “hub” – the UX is broken before it starts.
3. Content with Reusable Logic
When to show a tooltip. How to word empty states. What tone to use in modals. These can be rules, not reinventions.
4. Code and Design That Actually Talk
Not a full library. Just enough dev-design pairing to avoid reinvention:
- Shared Figma components
- Usage notes inline (not in Notion)
- Weekly reviews that include real UI, not just prototypes
How This Helps Right Now
With modular thinking in place, product teams ship faster – and support fewer problems later.
- New features get designed by remixing known UX instead of starting from scratch.
- Users understand new screens because the logic feels familiar.
- Founders and PMs can focus on value, not layout.
But it goes beyond that:
- Fewer small redesign debates. If the product has a language, teams don’t waste time arguing over the same decisions every sprint.
- Faster alignment between design and dev. Everyone’s building from the same mental model – even if you haven’t written it down yet.
- Less UX sprawl. One pattern, used well, beats five half-baked ones.
- More intuitive onboarding. Users don’t have to relearn how the product works every time they click into a new tab.
Modular UX becomes a speed boost. A shared compass. Not just cleaner design – faster delivery.
What to Watch Out For
Modular UX isn’t the same as uniform UX.
Repeating bad patterns doesn’t make them better. It just makes them harder to remove later.
Here are the most common traps:
1. Over-repeating bad patterns.
Just because something’s consistent doesn’t mean it’s right. If your modal logic is clunky, modularising it only helps that clunkiness scale faster.
2. Confusing modular with minimal.
Stripping something down to a bare UI doesn’t make it modular – it makes it vague. Users still need clarity, guidance, and context.
3. Mistaking documentation for shared understanding.
Having a Notion page with components and rules doesn’t mean your team knows how the product behaves. Modular thinking has to show up in conversations, code, and design reviews.
The goal isn’t sameness. It’s predictability.
- If a user learned one way to delete something, let them do it the same everywhere.
- If one modal uses humour and another reads like a GDPR policy, the voice isn’t consistent – it’s confusing.
Modularity only works if the pieces are good.
Don’t freeze junk.
Final Thought
Most early-stage SaaS teams don’t need a design system. They need a shared understanding of how the product behaves.
That’s what modularity gives you.
Not more documentation – more coherence.
The product feels easier to use. Easier to build. Easier to change.
Because the problem was never complexity.
It was chaos.