4
41 Comments

I stopped asking "How do I get users?" and started asking this instead.

When I first started building ReadRiff, I thought my biggest challenge would be getting users.

I was wrong.

The harder question turned out to be:

"Why should anyone come back after their first visit?"

With AI making it easier than ever to create content, publishing articles isn't difficult anymore.

Earning someone's trust is.

That realization changed the way I'm building ReadRiff.

Instead of chasing page views or publishing every day, I'm focusing on creating a platform where every article has to answer one simple question:

"Is this genuinely worth a reader's time?"

It's slower.

Sometimes frustrating.

But I think long-term trust is a better strategy than short-term traffic.

ReadRiff is still in development, and I'm building it around thoughtful articles, practical insights, and features like audio playback, offline reading, reading queues, and community-driven topic suggestions.

Right now, I'm looking for people who genuinely enjoy learning and are willing to help shape the platform through feedback before launch.

If that sounds like you, I'd love for you to check it out:

๐ŸŒ Website: https://readriff.com

๐Ÿš€ Product Hunt: https://www.producthunt.com/products/readriff

๐Ÿ“ฉ Feedback & ideas: [email protected]

One question for fellow founders:

What's one decision you made that slowed your growth in the short term but made your product better in the long run?

I'd love to learn from your experiences.

on July 15, 2026
  1. 2

    Slowing down to ask if each article is worth someone's time instead of chasing views is a hard discipline to hold onto once growth pressure kicks in. AI making publishing trivial actually makes this harder to defend too, since the noise floor keeps rising around whatever you build. What's the actual test you're using to decide if something's worth publishing, is it a gut check or something more concrete?

    1. 1

      That's something I've been thinking about a lot as well. Right now, it's mostly an editorial checklist rather than a numerical score. Before publishing, I ask whether the article teaches something meaningful, presents a clear takeaway, and is something I'd genuinely recommend someone spend their time reading. It's still evolving, but having that filter has helped avoid publishing just for the sake of publishing.

      1. 2

        An editorial checklist over a numerical score makes sense at this stage, a score would give false precision to something that's really a judgment call about whether it's worth someone's time. Asking whether you'd genuinely recommend someone read it is a good gut check, that's a higher bar than most publishing filters ever bother to set. Do you think that checklist could ever scale past just you, or does it only work because it's your own personal bar for quality?

        1. 1

          That's a great question, and honestly, I think it has to evolve if ReadRiff is going to scale.

          Right now, the checklist is based on my own editorial judgment because I'm the only one reviewing every article. But I don't want ReadRiff's quality to depend solely on my opinion forever.

          My long-term goal is to turn those principles into clear editorial standards that any contributor or editor can follow. Things like:
          Does it teach something meaningful?
          Is the takeaway clear?
          Is it accurate and well-researched?
          Does it add a fresh perspective instead of repeating what's already out there?
          Would we genuinely recommend someone spend 10โ€“15 minutes reading it?

          Another idea I'm exploring is making those editorial standards visible after an article is published. Instead of being hidden behind the scenes, every article could include a small editorial note explaining why it was published and what value the reader should expect to get from it.

          I also want the community to have a voice. Rather than relying only on our internal review, readers would be able to upvote articles they found genuinely valuable. Over time, that community feedback could become another signal of whether an article actually delivered on its promise.

          I don't think quality can ever be reduced to a numerical score, but I do think it can be guided by transparent editorial principles and reinforced by reader feedback. The editorial team decides whether an article is worth publishing, while the community helps validate whether it was worth reading.

          It'll definitely be an ongoing challenge, especially as AI-generated content keeps raising the noise floor. I think transparency and community trust will become two of the biggest differentiators for publications over the next few years.

    2. 1

      I'd use a publish test with three checks: can a reader state what decision changed, cite the source, and name the next action? An editor who can't answer all three sends it back. Then seven-day second-read behavior tests whether that standard predicts trust instead of just sounding rigorous.

      1. 1

        That's a concrete, testable bar, much better than 'does this feel useful.' The seven-day second-read signal is the more interesting one, it's measuring durable value instead of just clarity at publish time. Do you track that manually, or is there a lightweight way to instrument 'did someone come back to reference this' without it turning into a whole analytics project?

        1. 1

          You can keep this very small: emit a reference_opened event with an anonymous document ID, first_view_at, and last_view_at, then count a return only when the same document is opened again after seven days. No session replay or full analytics suite needed; the useful number is simply the share of published work that earns a delayed second read.

  2. 2

    This is such an important pivot in mindset. In the era of AI-generated noise, curation and trust are the new premium.

    To answer your question: One decision we made that slowed our short-term growth was forcing a manual onboarding/vetting process instead of letting anyone sign up instantly. It killed our conversion rate initially, but it ensured that our early cohort was highly qualified. The feedback we got was 10x better, and our retention spiked because the community quality stayed high.

    ReadRiff's focus on features like offline reading and audio playback shows you're actually thinking about the experience of consuming content, not just the clicks. Excited to check out the Product Hunt page!

    1. 1

      I really appreciate this. Slowing down definitely felt counterintuitive at first, but the quality of feedback from early readers improved noticeably once we focused on fewer, better pieces instead of trying to produce more. I'd rather build something people trust over time than chase short-term traffic spikes.

  3. 2

    answering your question: choosing to give the most useful thing away with no gate or ask attached. short term it looks insane because you're handing out the exact thing you could charge for, and day-one conversion is basically zero. but it builds the one thing that actually compounds - people trusting you're useful before you want anything from them. the ones who come back come back because you were worth their time for free first.

    your "worth a reader's time" filter is the same instinct pointed at content. slower, but it's the only version that survives the ai-content flood, since everyone can publish now and almost nobody's actually worth reading

    1. 1

      That's a great way of describing it. In a world where almost anyone can generate content instantly, attention isn't the scarce resource anymore; trust is. If people consistently feel that reading something was worth their time, they'll naturally come back. That's the standard I'm trying to hold myself to while building ReadRiff.

  4. 2

    One decision that slowed me down in the short term was refusing to scale traffic before I was confident the customer journey could support it. At IMP Marketing, because I work with a performance-based and revenue-share model, Iโ€™ve learned that more users or more clicks can hide deeper problems if the offer, product experience, or retention isnโ€™t strong enough. Iโ€™ve had to spend more time fixing the fundamentals first, even when scaling looked like the faster option. It can feel frustrating because the numbers grow more slowly at the beginning, but Iโ€™d rather build something people trust and return to than create a temporary spike that disappears a month later.

    1. 1

      I really like that perspective. It's easy to chase short-term numbers, but much harder to build something people genuinely return to. That's the mindset I'm trying to keep with ReadRiff as well. Thanks for sharing your experience; it reinforces that trust compounds over time.

      If you're ever interested, I'd love your feedback as the platform evolves. You can also join the early waitlist if you'd like to follow the journey: https://readriff.com. Suggestions are always welcome at [email protected].

  5. 1

    Listening before building is rare and underrated. Most founders build in a vacuum and then look for an audience. What's the most surprising thing you've heard from potential users that changed what you're building?

  6. 1

    Hey Meer โ€” you posted looking for feedback on ReadRiff, and the "why should anyone come back?" reframe is the right question. It's also exactly the thing a fresh pre-launch pass can pressure-test: does the first session actually earn a second one, or does it just look good once. Offer: I'll run a structured pass on it โ€” written feedback in a fixed 7-field format, back within 48h (weekend-friendly: the clock flexes, the commitment doesn't), async, no call. Not a service, a swap: in return you run a ~20โ€“30 min pass on a signup funnel of mine, same format, so neither of us is doing a favor. Format up front: https://nonchalant-tv-881.notion.site/UI-UX-Template-Test-Version-v1-3f1e3450b0698217a20881d090a8fee0 ยท this runs under betapair.dev. Want me to start with y

    1. 1

      Thanks so much for taking the time to write this; it genuinely means a lot. I really like the way you reframed the question around the "fresh pass" instead of just the landing page. That's exactly the kind of perspective I was hoping to get. I'll go through your document carefully over the next couple of days and reply with thoughts. Really appreciate you investing that much time.

  7. 1

    The reframe from "how do I get users" to "why would they come back" is such a meaningful shift โ€” and one most founders make too late.

    I've been thinking about this a lot building for a market where trust is the core currency (Vietnamese small business owners). There's almost no brand recognition or review infrastructure there the way there is on the App Store or Product Hunt. The only thing that works is word of mouth โ€” which means retention and genuine value delivered on visit #1 is everything.

    What I've found: the first session needs to give people a "wait, this actually works" moment within 2-3 minutes. Not a promise of value. Actual, tangible value they can use or show someone right now. That's the trigger for organic sharing in tight-knit communities.

    The question you're asking now โ€” why would they come back โ€” directly maps to engineering that moment. How are you currently identifying whether first-time users are hitting that "aha" or bouncing before it?

    1. 1

      I really like your framing of "a visit" versus "this actually works." That distinction made me rethink how I'm defining value for first-time readers. I'm trying to optimize for someone leaving with at least one memorable idea rather than simply increasing page views. Measuring that is definitely the harder part, but I think it's a better long-term direction.

  8. 1

    maps to what you're doing with "is this worth a reader's time?" โ€” that's retention language, not acquisition language. the trap is treating audio / offline / queues as the reason they return. those help habit. trust still has to come from the filter: they believe the next article will also be worth it.

    1. 1

      That's a great way to put it. If readers return because they believe the next article will also be worth their time, that's a much stronger signal than returning because of notifications or habit alone. That's the kind of trust I hope to earn over time.

  9. 1

    I like the shift from "How do I get users?" to "Why would they come back?" I think that's a question more founders should ask.

    One idea I'd add is that people don't usually return for featuresโ€”they return because the product consistently solves the same problem well. Features support that promise, but the promise itself builds trust.

    Building more slowly around real user value can be frustrating, but it's often what creates a product people recommend instead of just trying once.

    Looking forward to seeing how ReadRiff evolves.

    1. 1

      I completely agree. Features can improve an experience, but they rarely become the reason people come back on their own. If the core promise isn't consistently delivered, everything else becomes secondary. That's something I'm trying to keep in mind while building ReadRiffโ€”earning trust first, then adding features that genuinely improve the reading experience.

  10. 1

    The one that comes to mind: refusing to let a tool make claims it can't back with real data, even when the alternative (predictions, benchmarks, comparative scores) is exactly what people ask for and would probably drive more shares. It's slower to grow because you're constantly saying "I don't know that" instead of giving people the satisfying number they wanted. But the tradeoff is that when someone does trust the thing with something specific, that trust actually holds up under scrutiny instead of quietly eroding the first time a number turns out to be wrong.

    Your framing of earning trust vs. capturing attention maps onto that pretty directly - the slow path costs you the users who wanted a quick dopamine hit, but it buys you the ones who actually needed the thing to be right.

    1. 1

      That's a really interesting perspective. Saying "I don't know" when the evidence isn't there feels uncomfortable, but I think it builds more credibility over time than pretending every question has a definitive answer. I'd much rather publish something readers can trust than optimize for quick certainty.

  11. 1

    your web is great for people who likes to study and learn, about your question "What's one decision you made that slowed your growth in the short term but made your product better in the long run?" i think is prepareng the legal documents. especially for startup

    1. 1

      Thanks, I really appreciate that! I'm glad the idea resonates with you.

      That's a great answer as well. Legal work is one of those things that doesn't directly help growth, but it builds a much stronger foundation for the future. It's easy to overlook until you actually start building.

      I'm trying to make the same kind of long-term decisions with ReadRiff, even if they slow things down today. If you ever have ideas or suggestions, I'd genuinely love to hear them.
      You're also welcome to follow the journey or join the early waitlist at
      https://readriff.com.
      You can always reach me at [email protected].

  12. 1

    Easy answer for us.

    With Incipite, we chose Bitcoin blockchain anchoring (OpenTimestamps) instead of just timestamping uploads in our own database. A DB timestamp would have been live in a day. Blockchain took three weeks, requires a background cron job, and is genuinely hard to explain to non-technical users.

    But it means: if Incipite shuts down tomorrow, every proof a creator holds still lives on the Bitcoin blockchain, independently verifiable by anyone, forever. We don't control it.

    That's exactly what you're building toward with ReadRiff โ€” the difference between "trust us" and "here's something independently verifiable." The first scales faster. The second is the only one that actually compounds.

    1. 1

      That's a really thoughtful comparison; I hadn't looked at it from that angle before.

      You're right that the long-term goal is to earn trust through consistency rather than simply asking people to trust us. I think that applies to knowledge platforms just as much as to infrastructure products.

      I really appreciate you sharing Incipite's approach as well. It reinforces the idea that making the "hard" decision early often creates something much more durable over time.

      If you have any other thoughts as ReadRiff evolves, I'd genuinely love to hear them. You're also very welcome to follow the journey or join the early waitlist at https://readriff.com. Feel free to reach out anytime at [email protected] if you'd like to chat in more detail.

  13. 1

    Good question. The decision that slowed growth short-term but made everything better: I stopped broadcasting and started replying. Early on, posting my own content felt productive but mostly reached empty rooms. Replying to existing conversations was slower per unit of effort but each one reached an already-engaged audience. Took months to feel like it was working, then the return became compounding.

    1. 1

      That's a great lesson. I think meaningful conversations are probably more valuable than broadcasting into the void. I'm trying to spend more time listening to what people actually want before building more features.

      If you have any thoughts on what would make a knowledge platform genuinely useful, I'd love to hear them. Feel free to join the waitlist if you'd like to follow the progress: https://readriff.com.

  14. 1

    This lands. "How do I get users" assumes the product is the constant and the users are the variable.

    The version I got stuck on is worse: I built a two-sided marketplace, so "how do I get users" is actually two questions that block each other. Nobody's answer to "how do I get users" has ever helped me, because the real question turned out to be "who goes first, and what does it cost me to make that happen."

    What was the question you switched to?

    1. 1

      For me, it became:

      "Why would someone choose to come back after their first visit?"

      If the answer is only "because there's more content," I don't think that's enough anymore. I'm hoping people return because they trust the quality, discover something useful every visit, and eventually feel like ReadRiff saves them time instead of consuming it.

      I'd love to hear if there's a question that guides your own product decisions as well.

  15. 1

    Audio, offline reading, and queues are retention features, but they can blur whether trust comes from curation or convenience. I'd launch with one metric: the percentage of first-time readers who save or finish a second article within seven days. If that doesn't move, more publishing cadence won't fix the trust loop.

    1. 1

      That's a really useful way to think about it. Retention feels like a much healthier signal than just page views or signups. I'm hoping that if people come back because they consistently find something valuable, the rest will follow naturally.

      Out of curiosity, is there a retention metric you've found most useful in your own projects?

      1. 2

        Iโ€™d use retention tied to the core promise, not a generic weekly-active number: the share of activated users who complete the same valuable action in a second distinct week. Track it by signup cohort, because a rolling WAU rate can look healthy while newer cohorts quietly decay. The useful cut is activation โ†’ week-two return, then the reason for the return.

        1. 1

          That's a really useful framework. I like the idea of measuring whether people return because they experienced the core value, rather than just tracking generic activity. The "reason for the return" is probably the metric that tells the real story. I'll definitely keep that in mind as I start measuring early reader behavior. Thanks for sharing your perspective!

  16. 1

    The shift from acquisition to retention is the interesting one. I'd keep validating whether readers are returning because the content is high quality, or because ReadRiff becomes the place they trust to filter what's actually worth their attention. Those create very different products.

    1. 1

      I completely agree. That's exactly the challenge I'm trying to solve. Features can improve the experience, but they aren't the reason people return. I hope that ReadRiff earns trust by consistently helping people filter what's genuinely worth their time.

      Thanks again for your thoughtful comments; they've been really helpful. If you ever have more ideas, I'd genuinely appreciate them. You can also follow the journey or join the early waitlist at https://readriff.com, and if you'd rather share detailed thoughts, feel free to email me at [email protected].

      1. 2

        Thanks, I really appreciate that.

        I actually sent you an email about three days ago to [email protected]. If you haven't seen it yet, could you check your Spam or Promotions folder? It may have landed there.

        Looking forward to hearing your thoughts whenever you get a chance to read it.

        1. 1

          Thanks for the heads-up! I just found your email; it had indeed landed in my Promotions folder. I'll go through it carefully over the next day or two. Really appreciate you taking the time to write such detailed feedback. Looking forward to continuing the conversation!

          1. 1

            Glad you found it.

            No rush โ€” take your time going through it. Looking forward to hearing your thoughts whenever you get a chance.

Trending on Indie Hackers
How to rank #1 on ChatGPT? User Avatar 112 comments I built a startup-idea scanner. It just told me none of my 3,400 ideas are easy wins. User Avatar 75 comments โ€œIโ€™ll just post on Upworkโ€ is not a client strategy. Hereโ€™s what I built instead. User Avatar 54 comments Building a Shopify bundles app for stores with real fulfillment: here's the wedge User Avatar 42 comments I recorded myself using 200+ indie SaaS products cold. Here are the 7 conversion killers that keep showing up. User Avatar 33 comments How to automate refund reviews without giving AI the final say User Avatar 29 comments