There's a conversation every SaaS founder eventually has with their team.
A new user signs up, gets through onboarding, and then does nothing. Support looks at the session recording. What they see is someone clicking around a product that, from the outside, makes no coherent sense — menus with twelve items, dashboards with no clear starting point, workflows that require knowing something you only learn by already knowing it.
The founder watches the recording and feels a specific, uncomfortable recognition: this used to be simple.
It didn't become complicated because anyone made bad decisions.
That's the part that's hardest to accept. Every feature your team shipped was justified. The reporting tab, the second dashboard view, the alternative onboarding path for enterprise users, the power-user keyboard shortcuts, the settings nested inside settings — each of these was a reasonable response to a real request from a real customer.
The problem wasn't any individual decision. It was the accumulation. SaaS products don't usually become hard to use because of a single bad design call. They become hard to use because of two hundred individually reasonable ones, made across two years by different people with different mental models of what the product is for.
The result is a product that reflects its own history more than it serves its current users.
There's a name for this: complexity debt.
You know technical debt — the code shortcuts that ship fast and compound into expensive problems later. Complexity debt works the same way, and it's just as real a liability on your product's balance sheet.
Every time you add a feature without reconsidering the information architecture around it, you take on complexity debt. Every time you add a new user type without redesigning the navigation to serve all of them clearly, you take on complexity debt. Every time you solve a specific customer complaint with a specific new UI element rather than fixing the underlying flow, you take on complexity debt.
It doesn't feel like a problem in the moment. It feels like progress. And then one day you look at your churn data and notice that the drop-off isn't at signup. It's at week three.
The thing about complexity debt is that it's invisible from the inside.
Your team knows the product. They know what the settings panel does and why it's in that location and what happens if you skip step two. That knowledge is so embedded in how they navigate the product that they've stopped seeing the product as a new user would.
The people who built your product are the worst possible judges of how usable it is for someone encountering it for the first time. Not because they're bad designers or careless product managers, but because familiarity erases the friction that unfamiliarity reveals.
The symptoms show up before you recognise the cause.
Before founders come to us, there are usually a few consistent patterns: support tickets that keep describing the same confusing flow phrased slightly differently each time; power users who know every workaround and use them without thinking; sales demos that require a lot of narrator framing — "this part is a bit confusing but once you understand it..."; onboarding completion rates that are fine, activation rates that are not.
These aren't separate problems. They're the same problem, surfacing in different places. The product has accumulated enough complexity that the original logic is no longer legible to someone who doesn't already know it.
Fixing this is not the same as a redesign.
This is where a lot of teams go wrong. They see the complexity, assume the answer is a visual overhaul, spend six months redesigning the UI, and ship something that looks cleaner but has the same underlying structural problems. A new coat of paint on a confusing information architecture is still a confusing information architecture.
What complexity debt actually requires is structural thinking. Which features should be primary and which should be secondary? Which user journeys are load-bearing and which have become workarounds because the real path doesn't work? Where are the moments where the product loses a new user's trust — not because of aesthetics, but because of confusion?
Growing products have to earn their complexity.
The SaaS products that stay usable at scale aren't the ones with fewer features. They're the ones with better judgment about how features relate to each other, and the discipline to restructure that relationship as the product grows.
If your product is harder to use than it was eighteen months ago, that's information. Not about your users — about your architecture. The solution isn't to simplify by removing features. It's to understand which features belong at the surface and which belong deeper, which journeys deserve primary navigation and which are edge cases, and how to make the whole thing legible to a user who is encountering it for the first time.
That's the audit. That's where we start.