All articles Build the Right Thing

User Research on a Budget: 5 Methods That Cost Almost Nothing

By the FabricLoop Team  ·  May 2026  ·  9 min read

Big companies have UX research departments. They run longitudinal studies, recruit participants from panels, and spend months synthesising data before making a product decision. You don't have that. But here's what you do have: direct access to your users, a short feedback loop, and the ability to move fast.

User research doesn't require a lab. The five methods below cost little to nothing, can be run this week, and will tell you more about your product than most founders learn in a year of building in the dark.

Why "I think my users want X" is dangerous

Founders are pattern-matchers. You live with the problem, you've talked to some people, and you've formed a strong mental model of what your users need. That model feels accurate — but it's built on incomplete signals.

Topic Assumption (guess) What research often reveals
Why users sign up "They want the core feature" They saw a specific use case in a review or referral
Why users churn "The price was too high" They couldn't figure out how to set it up in the first week
Who your real user is "The person who pays" An employee three levels below who drives adoption (or blocks it)
What feature to build next "Feature requests in the inbox" A workflow workaround users built themselves, hiding the real gap

The cost of guessing wrong isn't just time — it's credibility. Shipping features nobody uses, or ignoring the friction that's killing your retention, compounds over months.

"Your opinion about what users want is a hypothesis. Their behaviour is the data."

Five methods that cost almost nothing

1

The 5-user moderated interview

Schedule 30-minute calls with 5 current users. Ask open-ended questions about their workflow, not your product. Five is enough — you'll hear the same themes three times by interview four. Record with permission, transcribe, and tag patterns across sessions.

Free
2

Session recordings (Hotjar / Microsoft Clarity)

Both tools have generous free tiers. Watch 10–20 real sessions of users moving through your key flows. Look for rage clicks (repeated clicking in frustration), U-turns (going back immediately after landing somewhere), and drop-off points. You'll see confusion you never imagined.

Free
3

The 3-question in-app micro-survey

Trigger a short survey on a specific action (e.g., after completing a key task or after 7 days of use): "What brought you here today? / Did you accomplish it? / What almost stopped you?" Keep it to 3 questions maximum — response rates collapse after 3.

Free
4

Competitor review mining

Go to G2, Capterra, Trustpilot, or the App Store reviews for your top 3 competitors. Filter for 3-star reviews — those are the most honest. Look for phrases like "I wish it could," "the only thing missing," and "we switched because." These are your market's unmet needs, handed to you for free.

Free
5

Guerrilla usability testing

Find 3 people who match your target user roughly — a colleague's partner, someone at a coffee shop, a contact in your network. Give them a task ("try to sign up and complete X"). Watch silently. Don't explain, don't help. 20 minutes of watching someone struggle with your onboarding is worth more than 20 hours of internal debate.

~$0–30

What to do with what you learn

Research is useless unless it changes something. After each round of research, write down exactly three things:

  1. What we confirmed: assumptions that held up. This is important — it narrows your decision space.
  2. What we learned we were wrong about: the most valuable output. Don't minimize this. Share it widely.
  3. What we're going to do differently: a specific, committed action. If research doesn't change a decision, you didn't need the research.
Tip Share research findings with your whole team, not just product. Engineers who hear directly from users write better code. Support teams who see session recordings develop more empathy. Customer-facing people who read interview transcripts give better advice. Research is a cultural practice, not a department.

How often to run research

Early stage (pre-product-market fit): run some form of research every week. At least one user conversation. At least one session recording review. The feedback loop needs to be tight because you're still discovering who you're for.

Growth stage: monthly or bi-weekly. Designate someone to own the research rhythm — even if it's the founder or a product person spending 2 hours a week. Let it decay and you'll start building for yourself again.

Common mistake Stopping research after you find product-market fit. PMF is not permanent — markets shift, users evolve, new competitors emerge. The companies that stay relevant treat research as ongoing, not as a phase they went through.

The one question that beats them all

If you're pressed for time and can only ask users one thing, ask this: "Walk me through the last time you used [product] to solve [problem]. Start from the beginning."

This question forces a narrative, not a rating. It reveals actual context, actual friction, and actual outcomes — not hypothetical preferences. Listen for what they skip over (they've given up caring about it) and what they describe in detail (it matters a lot).

How FabricLoop supports continuous research Research insights live in too many places — Notion docs, email threads, Slack messages, call recordings nobody revisits. FabricLoop keeps your research notes, synthesis docs, and follow-up tasks in one thread, so findings don't evaporate and the context is searchable months later when it becomes relevant again.

10 things to take away from this article

  1. Founder intuition is a starting hypothesis, not a substitute for research.
  2. Five user interviews reveal the dominant themes — you don't need 50.
  3. Session recording tools like Microsoft Clarity have free tiers and reveal invisible friction.
  4. In-app surveys should be 3 questions maximum — completion drops sharply after that.
  5. Competitor 3-star reviews are a goldmine of unmet needs your market is broadcasting publicly.
  6. Guerrilla usability testing with 3 people in 20 minutes reveals more than weeks of internal debate.
  7. Research is only useful if it changes a decision — document the "what we'll do differently" explicitly.
  8. Share findings across the whole team, not just product — it changes how engineers and support staff think.
  9. Pre-PMF: research weekly. Post-PMF: at least monthly. Never stop entirely.
  10. "Walk me through the last time you used this" is the single best research question you can ask.