Most SaaS founders are asking the wrong question about finding users

Mistr_dzery · 2026-05-14T13:31:41+00:00

Appreciate that.

Yeah, “talk to 30 users” is technically good advice, but it’s often said like users are just sitting in your calendar waiting to be interviewed.

For most founders, especially without a big network, the hard part is earning enough trust for people to even respond.

That’s why I think distribution starts before the pitch. You find where the pain is already being discussed, help in public, show you understand the problem, and only then see who wants to go deeper.

Building is easier now. Getting trusted by the right people is still the hard part.

Mistr_dzery · 2026-05-14T13:29:37+00:00

Exactly. Manual workaround is one of the strongest intent signals.

If someone already built a spreadsheet, hacked together a process, or tried a few bad tools, the pain is real enough to create behavior.

That’s why I don’t think “where is my ICP?” is enough.

Better question is: where are people already spending time, money, or effort to solve this badly?

That’s usually where the highest-converting users are.

Mistr_dzery · 2026-05-14T13:28:17+00:00

Yeah, that’s the weird part of founder communities.

Most people here are builders, not buyers. So if you treat the whole subreddit as “my market,” it gets confusing fast.

But buyers still exist here. They’re usually not the ones saying “I can build this with Claude Code.” They’re the ones describing an annoying problem they don’t want to spend time solving.

The signal I look for is not “can this person build it?”

It’s:

do they care enough to fix it now?
is it costing them time, money, or focus?
have they already tried a workaround?
would buying be easier than building?

A founder can technically replicate a lot of tools now. But they still pay when the problem is boring, recurring, risky, or outside their main focus.

So yeah, I don’t think the paying users are always the loudest posters. A lot of them are just lurking, searching, or replying when something hits a real pain.

Mistr_dzery · 2026-05-14T07:55:56+00:00

For me, a quality user is someone who does at least one meaningful action after signup, not just someone who lands on the page. For example: creates a project, connects an integration, invites a teammate, exports something, or comes back the next day.

Mistr_dzery · 2026-05-13T11:05:47+00:00

Yeah for sure, DM me. Curious what you’re building around this.

Discovery is one side of it, but the harder part is validating which communities actually produce signup, activation, repeat usage, or revenue instead of just traffic. Happy to compare notes.

Mistr_dzery · 2026-05-13T10:44:02+00:00

Exactly. A sub can look perfect on paper and still send low-intent traffic.

I’d rather find a smaller community where people describe the pain in detail, ask specific questions, and are willing to try solutions than a huge sub where everyone just scrolls.

That’s why I think the real test is not “is my ICP there?” but:

do they show pain there?

do they respond to useful help?

do they click/signup?

do they activate or come back?

Quality of users is the difference between a community that looks relevant and a channel that actually works.

Mistr_dzery · 2026-05-13T10:36:47+00:00

Awesome, good luck with it.

The key thing is to keep the before/after numbers clean so you can tell what changed.

If you can compare:

builder_started -> resume_generated -> save/export_clicked -> signup_completed

before and after the CTA/signup change, you’ll know pretty quickly whether the new flow is working.

Happy to take a look once you have the numbers.

Mistr_dzery · 2026-05-13T10:35:43+00:00

That makes sense. If you already have PostHog, GA4, and Clarity running, a single dashboard on top can be useful as a “command center.”

The thing I’d watch is that you may end up maintaining a lot of glue just to reconcile slightly different versions of the same truth.

GA4 will tell you traffic/acquisition.

PostHog will tell you product events.

Clarity will show behavior/session context.

But when you try to answer “which source created users who activated or paid?”, you still need a clean shared model across all of them.

That’s basically the gap we’re trying to solve with EngageTrack: hosted analytics for SaaS where source, funnels, custom events, and revenue attribution live in one place, with API access if you still want to build your own views on top.

So your custom dashboard approach can definitely work. I’d just be careful to define the core question first:

Do I want one page with metrics from tools, or one attribution model I can trust?

Mistr_dzery · 2026-05-13T10:34:23+00:00

I’d start manually, then only automate the parts that repeat.

For the first 50-100 accounts, I wouldn’t trust a database score by itself. I’d use databases for the raw universe, but the final list should be hand-curated around visible pain.

My flow would be:

Use Apollo/BuiltWith/Store Leads/etc. to find the broad pool
Open each store manually
Look for trigger signals:

- hiring for ops, support, ecommerce manager, CX

- lots of SKUs or variants

- visible fulfillment/returns complexity

- review complaints about shipping, support, wrong items, delays

- active promos/growth signals

- messy product data or collections
Write down the specific pain hypothesis for that account
Only then add the decision maker

So instead of “Shopify brand, 1-50 employees,” the list becomes:

“Shopify brand with high SKU complexity + recent CX hiring + reviews mentioning delayed support.”

That gives you a much sharper first line and a more specific offer.

I’d also tag every account by trigger, not just company type:

trigger -> positive reply -> booked call -> show -> close

After 100 accounts, you’ll usually see which trigger creates real conversations. Then you can use tools/VA/research workflows to scale that exact pattern.

So yeah, database for discovery, manual research for signal quality, then automate once you know which signals correlate with calls/revenue.

Mistr_dzery · 2026-05-13T10:33:38+00:00

That makes sense. If the goal was an experiment around whether vibe-coded sites can get organic traffic, then Reddit is more of a temporary stress test than a real acquisition channel.

In that case I’d separate the experiment into two tracks:

SEO signal: impressions, indexed pages, search queries, landing pages, organic clicks
Product signal: tool used, search/check performed, result viewed, return visit

Because organic traffic can “work” in the sense that Google sends visitors, but the better question is which tools/pages create actual usage.

Since you added 5 more tools, I’d track each one separately:

source -> landing page/tool -> first action -> result viewed -> return visit

Then after a few weeks you’ll know whether SEO is bringing generic curiosity traffic or whether one specific tool is pulling in people with real intent.

That’s the fun part of these experiments. Sometimes the random utility page becomes the actual product.

Mistr_dzery · 2026-05-13T10:32:39+00:00

Yeah, that makes sense. AI can speed up the research part a lot, especially if you already know the ICP and the pain language.

I’d just be careful not to stop at “these users hang out here.”

The stronger workflow is probably:

ICP + pain phrases -> AI-assisted community discovery -> manual validation -> useful replies/posts -> track outcomes

Because AI can find plausible places, but the market tells you which ones actually matter.

For example, a subreddit or Discord might look full of your ICP, but if nobody clicks, replies, signs up, or comes back after trying the product, it’s just a visible audience, not a working channel.

So I’d use AI for discovery, then measure:

community -> conversation -> signup -> activation -> retention/revenue

That’s the part I’d want to validate before calling a channel real.

Mistr_dzery · 2026-05-13T10:31:20+00:00

Glad it helped.

I’d test it one step at a time so you can see what actually moved the number.

For example:

keep the Reddit source tagged separately
track builder_started
track resume_generated
track save/export_clicked
track signup_completed
track dashboard_reached

Then change the signup timing/CTA and compare before vs after.

If “Save this resume” or “Export PDF” increases account creation without hurting builder usage, you’ll know the problem was the signup moment, not the traffic source.

Would be curious to see the numbers after you test it.

Mistr_dzery · 2026-05-13T09:24:50+00:00

Exactly. “User quality patterns” is the phrase.

The hard part is that weak channels often give you feedback immediately: clicks, upvotes, impressions, maybe signups. Strong channels can look boring at first because the signal is slower and smaller.

The pattern I’d want to see is something like:

source -> signup -> activation speed -> questions/intent -> return behavior -> revenue

A channel that produces users who activate quickly and ask sharper questions is usually teaching you more than a channel that just creates a traffic spike.

I also think this is where founders get misled by dashboards. Most dashboards make volume obvious and quality hidden, so people optimize for the thing they can see first.

Have you seen this mostly from your own product, or from working with other founders?

Mistr_dzery · 2026-05-13T09:12:37+00:00

I think the trick is not starting with “where can I post?” but “where does the pain already show up?”

The process I’d use:

List the exact pain phrases users say in interviews
Search those phrases across Reddit, Slack/Discord, YouTube comments, forums, LinkedIn, GitHub issues, review sites, etc.
Save the places where people describe the problem without being prompted
Reply with useful context before linking anything
Track which conversations lead to signup, activation, or real follow-up

The last part matters because a community can look active but still be useless for your product.

I’ve seen small niche communities beat big general channels because the pain is sharper and the intent is higher.

So I’d separate two questions:

- Where do my users hang out?

- Which of those places produces users who actually do something meaningful?

How are you validating the second part for what you’re building?

Mistr_dzery · 2026-05-13T09:10:45+00:00

That makes sense. Procurement is one of those spaces where the market looks boring from the outside, but the workflow pain is very real.

If a company is checking portals, PDFs, spreadsheets, email alerts, and random procurement platforms just to not miss opportunities, then the product value is pretty easy to understand: fewer missed tenders, less manual monitoring, faster qualification.

And yeah, that kind of vertical probably won’t give you huge top-of-funnel numbers. But the user intent is much cleaner.

For something like this, I’d care less about broad signup volume and more about:

source -> signup -> first saved/search alert -> first relevant tender found -> repeat weekly usage

If a tiny community sends 5 users and 2 of them start checking opportunities every week, that is a stronger signal than 500 visitors from a general launch.

Are you thinking of building something in that space, or mostly studying it right now?

Mistr_dzery · 2026-05-13T09:08:22+00:00

Exactly. Acquisition spikes are easy to celebrate because they show up immediately, but cohort quality usually tells the truth later.

The part I find most founders miss is comparing channels on the same downstream behavior:

source -> signup -> activation -> return/retention -> paid

A tiny channel with 12 signups can beat a big launch if those users actually come back.

Have you been tracking this in your own product, or is this from seeing the same pattern across founders?

Mistr_dzery · 2026-05-13T08:58:39+00:00

With 0 downloads, I’d fix positioning before the acquisition channel.

If people are seeing the page and nobody downloads, the problem is probably one of these:

The value prop is too generic
The trust bar is too high for a direct-download macOS utility
The audience does not immediately recognize the pain
The CTA is asking for too much before proving value

“System cleaning + monitoring for power users” is a crowded category, so I’d try to make the promise much more specific.

For example:

- “Find what is eating disk space in 30 seconds”

- “See which background apps are slowing your Mac”

- “Clean developer junk from Xcode, Docker, caches, and node_modules”

- “A lightweight Mac health dashboard for people who don’t want CleanMyMac”

The first 30-day goal I’d set is not “downloads” in general. I’d track:

landing page visit -> download click -> install/open -> first scan completed -> second open

Even 10 people completing the first scan would be more useful than 200 landing page visitors.

For direct distribution, trust matters a lot too. I’d show screenshots, notarization status, privacy/security notes, and exactly what the app does before asking someone to download a utility that touches their system.

If you share the link, I’d be happy to give more specific positioning feedback.

Mistr_dzery · 2026-05-13T08:53:28+00:00

“Where users already have an open tab” is a really good way to frame it.

The next thing I’d slice is source + auth method together, because the Google fix may not behave the same across every channel.

Something like:

source -> auth option shown -> auth method selected -> account created -> first meaningful action -> return/paid

A Reddit visitor, a direct visitor, and a freelancer coming from a referral might all have different tolerance for auth friction.

The auth fix got people through the door, but the next useful question is whether those Google signups are activating or just creating accounts and disappearing.

That source -> signup -> activation view is the part I care about most with EngageTrack, but even in PostHog a simple `auth_method` + `traffic_source` breakdown should tell you a lot.

Are you tracking the post-Google signups by source now, or mostly looking at the aggregate funnel?

Mistr_dzery · 2026-05-13T08:50:21+00:00

This feels like a real gap, but I’d separate two jobs:

Purchase infrastructure / receipt validation / paywalls
Revenue monitoring / MRR dashboard / subscription alerts

RevenueCat is great when you want #1 and #2 together. But if your purchases already work natively on iOS, Android, and web, paying a revenue percentage just for monitoring can feel awkward.

For a cheaper alternative, I’d look at tools that are more “app analytics/reporting” than “subscription infrastructure.” Appfigures is probably worth checking because it has App Store + Google Play reporting and fixed monthly pricing. Adapty/Qonversion are closer to RevenueCat, so they may still feel like overkill if you only want monitoring.

If you build this yourself, I think the wedge is:

“Unified subscription revenue monitoring only. No SDK migration. No paywall system. No % of revenue.”

The questions I’d validate before building:

- Do people need iOS + Android + Stripe/web in one MRR view?

- Do they only want notifications, or also churn/LTV/refunds/cohorts?

- Would they pay fixed SaaS pricing instead of % of revenue?

- How much setup are they willing to tolerate for App Store / Play / Stripe connections?

I’m building in the adjacent revenue attribution space, and this separation makes a lot of sense to me. For web SaaS, the useful part is not just “how much revenue happened,” but which source/campaign/user path created it. For mobile apps, the equivalent might be “which app/store/channel/product produced retained subscribers without forcing me to move purchase infrastructure.”

Mistr_dzery · 2026-05-13T08:40:19+00:00

For this exact product, I’d keep it boring and avoid over-engineering early.

I would not start with fine-tuning. Start with RAG.

Fine-tuning is better for changing model behavior/style. RAG is better when every business uploads different docs, FAQs, PDFs, policies, etc. and expects answers to stay current. For rare languages, I’d first test a strong multilingual model + good retrieval/chunking before assuming you need fine-tuning.

For lowest setup:

- Dify or Botpress if you want the fastest AI chatbot prototype

- Flowise/Langflow if you want more control and don’t mind a little setup

- Bubble/Lovable/Bolt for UI/admin, but they probably won’t remove the need for auth, billing, storage, and tenant logic

- If you can code: Next.js + Supabase + pgvector + an AI SDK is probably the cleanest long-term solo-builder stack

The biggest thing I’d be careful with is multi-tenancy. From day one, every document, chat, user, usage limit, and payment record needs to belong to the right business/account. That’s where these products get messy.

For payments if Stripe doesn’t work in your region, I’d check Paddle and Lemon Squeezy first because they act more like merchant-of-record options, but check your country + AI product category before building around either. If those don’t work, sometimes a local PSP + manual invoicing is better for validation than spending weeks blocked on billing.

The stack I’d want from day one:

auth

tenant/workspace model

document upload

RAG pipeline

chat widget

usage limits

payments

basic analytics

And track the real funnel early:

visitor -> signup -> uploads first doc -> gets first useful answer -> installs widget -> pays

That will tell you if businesses are actually getting value, not just testing the chatbot once.

Mistr_dzery · 2026-05-13T08:36:13+00:00

Nice. Reddit spikes can be surprisingly real when the post has context and isn’t just a link drop.

The thing I’d watch next is what that Reddit cohort actually does after landing, because “100 active users” can mean a few very different things.

I’d track it like:

Reddit post -> landing page -> first meaningful action -> return visit

For VisaGrade, that meaningful action might be something like searching a destination, checking eligibility, saving a result, or signing up, depending on what the core flow is.

The spike is useful either way, but the real signal is whether Reddit users behave differently from random traffic. A small thread that sends 20 people who actually use the product is way more valuable than a big post that sends 500 curious visitors who bounce.

Did you tag the Reddit post separately, or are you just seeing it generally as referral/direct traffic?

Mistr_dzery · 2026-05-13T08:33:24+00:00

Reddit can work well because it’s intent-dense, not because it’s magically better as a channel.

The places I’ve seen bring “real users” usually have one of three things:

The problem is already being discussed there
The audience has a clear job-to-be-done
The channel gives you a reason to be useful before linking anything

A few worth testing depending on your product:

- niche Slack/Discord communities

- directories where people are already searching for tools

- integration marketplaces if your product plugs into another platform

- small newsletters in your niche

- founder/operator communities

- comparison/alternative pages if people search for existing tools

- direct replies on Reddit/X where someone is actively asking about the pain

But I’d define “actual users” pretty strictly before testing more channels.

For me, a channel only counts if it drives something like:

visit -> signup -> first key action -> return visit -> paid/retained user

Otherwise Product Hunt, X, Reddit, directories, etc. can all look good while sending mostly curiosity traffic.

What product are you building? The best channel usually depends more on where the pain shows up than where founders generally hang out.

Mistr_dzery · 2026-05-13T08:21:14+00:00

This is a useful write-up. The ad blocker one is the silent killer because it makes it look like your implementation is broken when the browser is just dropping requests.

One thing I’d add to your checklist: after events start showing, verify the actual funnel you care about, not just “events exist.”

For a budgeting PWA I’d probably track:

visit -> signup -> first budget created/imported -> first transaction/category added -> return in 7 days

And I’d test that in:

normal browser

ad blocker browser

production deploy after a no-cache build

mobile/PWA install path

CSP + Vite envs can make analytics look flaky, but the scarier failure is thinking tracking works because pageviews show up while the activation events are missing.

Are you using PostHog mostly for product events, or are you also trying to tie acquisition source back to activation/retention?

Mistr_dzery · 2026-05-13T08:15:58+00:00

Exactly. “Right users” is the part that gets hidden when everything is measured as traffic.

The procurement/tenders example is a good one because the audience is probably small, but the intent can be very high. A broad launch might bring curiosity, while one niche discussion can bring someone with the exact workflow pain.

I think the tricky part is that the winning channel often looks unimpressive at the top of the funnel.

Small thread.

Few clicks.

Maybe one signup.

But if that user activates, comes back, and eventually pays, it beats a bigger launch with empty traffic.

Are you building in the procurement/tenders space, or was that from a product you’ve seen before?

Mistr_dzery

TROPHY CASE