We work with companies at different stages — early-stage startups, growing scale-ups, and more established small-to-medium businesses. And across all of them, there's a pattern that comes up with enough regularity that it's worth naming clearly.
What happens in the startup phase
In the early days, there's no time for process. Everything is speed and survival — get the product to a point where it works, find the right users, secure the next round of investment, pivot if something isn't landing. That's the right approach at that stage. You can't slow down to build a proper design system or run thorough user testing when the product's existence is still in question.
The teams are small, everyone knows what's being built, and decisions happen quickly in the same room. There are gaps and inconsistencies in the product, but they're manageable because the team is tight enough to patch things as they go.
Where it starts to break down
Then the company stabilises. More people join. A second product team forms, then maybe a third. The roadmap gets longer. Features start getting built by people who weren't in the original conversations.
And at some point — usually when it's becoming hard to ignore — everyone starts feeling like the product isn't quite delivering on its promise. The design looked right in Figma. The shipped product feels different. Not broken, but not quite right either.
This isn't a coincidence. It's the predictable result of a product that scaled without the design infrastructure to support that growth.
The specific things that compound
A lot of it comes down to planning and communication breaking down at the edges.
With data-heavy products especially, you need to design for every scenario — including the ones where data is incomplete. If you're building detail pages from a database of companies or retailers, some of those records will be missing fields. Modular design that adapts gracefully to missing data isn't optional at that point, it's the job. But that kind of thinking rarely happens without someone specifically responsible for it.
Beyond the design details, there's usually a more structural issue: no one is overseeing the whole picture. Small things get lost in handoffs from design to development. Edge case logic never makes it into the conversation. A component gets used slightly differently across different parts of the product. None of these feel significant on their own.
But they compound. The product starts to feel like it's been assembled from pieces rather than built as a whole. Users can feel it even if they can't name it. PMs and salespeople stop feeling confident during demos. Clients sense that something's off.
We see this pattern in roughly seven out of ten clients we work with, whether we come in from day one or join later in the product's lifecycle.
What usually happens next — and why it's avoidable
At some point the team recognises the problem and the response tends to be a full redesign. Which makes sense as a reaction, but it's expensive, time-consuming, and it still doesn't address the root cause. If the structural issues that created the problem are still there, a redesign will eventually produce the same result.
The more sustainable fix is earlier: someone needs to own the process before the gaps start compounding, not after. Someone who is watching the handoffs, maintaining the design system, making sure the product feels like a coherent whole as it grows — not just at launch, but continuously.
That's what we bring when we come into a company at that stage. Not a redesign, but the design oversight that prevents the need for one.
Articles
