Strategy
How to redesign a product before you have enough users to test it
Most early-stage SaaS teams don’t have enough traffic for perfect usability testing. Here’s how we still make confident UX decisions.

A founder once told us, "We can't A/B test, we only get 40 signups a week." That's the reality for most early-stage SaaS teams. Every UX playbook assumes you have traffic to run experiments on, and most pre-seed to Series A companies simply don't.
So how do you make confident design decisions without that data? A few things we lean on.
Competitor teardown, done properly
Not a screenshot collage. A structured audit of how comparable products handle the exact flow you're designing; onboarding, pricing pages, empty states, whatever the problem is. We look at products slightly ahead of you in maturity, not just direct competitors, because they've often already made and fixed the mistakes you're about to make.
Five conversations beat fifty survey responses
You don't need statistical significance at this stage, you need pattern recognition. Five structured conversations with real or prospective users, watching them actually try to use the product, will surface more usable insight than a survey with fifty responses and no context.
Heuristic evaluation against known principles
Usability heuristics exist because they're tested across thousands of products over decades. Visibility of system status, error prevention, recognition over recall. Running your product against these before you ever get a real user in front of it catches a huge share of problems for free.
Build decision points into the roadmap, not just the launch
The teams that get UX right early aren't the ones with more data, they're the ones who treat every release as a decision point. Ship a change, watch what happens to the metric it was meant to move, adjust. This is slower than a full research team but it compounds, and it's realistic for a team your size.
What we don't do
We don't pretend research substitutes are as good as real usage data. We're honest with clients that early-stage design decisions carry more risk than they will once there's real usage to learn from. What we can do is stack the odds; competitor patterns, direct conversations, heuristic review, and a roadmap that treats every ship as a test.
That's usually enough to get a product to the point where it has real users to learn from, which is the whole point.


