2
12 Comments

Building a no-login WebRTC app with Node.js: How we reached 65K organic Google clicks in 28 days (Zero Ads)

Hey everyone,

Over the past month, I experimented with a simple idea:
What happens if you remove all friction from a product?

Most chat platforms require users to:

  • create an account
  • verify email or phone
  • share personal data

For something as simple as starting a conversation, this felt unnecessary.

So instead of following the usual approach (DB + OAuth + verification), I built a completely anonymous, browser-based system:

  • no login
  • no registration
  • no tracking
  • instant connection

You open the page and you're immediately in a live session.

Tech stack & architecture

To keep everything fast and lightweight, I used:

  • WebRTC for peer-to-peer communication
  • Node.js + Socket io for signaling

The server only handles:

  • session creation
  • SDP exchange
  • ICE candidates

Once the WebRTC handshake is complete, everything (text, audio, video) flows directly between peers.

Biggest challenge

Without user accounts, everything becomes stateless and temporary.

That created challenges around:

  • socket lifecycle management
  • handling unexpected disconnects
  • maintaining room states (especially for region-based rooms)

A lot of effort went into making the signaling layer reliable under these constraints.

##Growth: 65K clicks in 28 days

The biggest change wasn’t technical — it was removing friction.

Because users don’t need to sign up:

  • entry barrier is zero
  • drop-offs are minimal
  • sessions start instantly

This led to:

  • very low bounce rate
  • higher session duration
  • strong engagement signals

Combined with targeting long-tail queries like:

  • “chat without login”
  • “anonymous video chat instant”

the site grew to ~65,000 clicks from Google Search in 28 days, without any paid ads.

##What I built

To test this idea, I created a simple page for random video chat without login:
https://chatzyo.in/

##Key takeaway

Simplicity is not a limitation — it’s a growth strategy.

Instead of adding features, removing steps made a bigger impact on both UX and SEO.

Question

For those building real-time apps:

How are you handling scaling for signaling servers when traffic spikes unpredictably?

Would love to hear how others are solving this.

posted to Icon for group Product Launch
Product Launch
on April 23, 2026
  1. 1

    Scaling real-time apps with unpredictable traffic sounds like a real challenge. I happen to know a couple of software engineers who've built and scaled real-time applications with signaling servers, so they might be able to answer your questions.

  2. 1

    Congrats on the 65K clicks! That is a massive win for a no-friction UX. Regarding your question on scaling signaling: have you looked into using a Redis adapter with Socket io? It’s usually the first line of defense to scale horizontally across multiple Node js instances. For unpredictable spikes, moving signaling to a serverless provider or using a managed service like Ably or Pusher can also take the infrastructure headache off your plate so you can focus on the WebRTC stability.

    1. 1

      Thanks, this helps a lot.
      I haven’t tried Redis yet, but planning to test it as traffic grows. Right now, I’m keeping the backend simple and relying more on WebRTC after the connection.
      Will also explore managed services like Ably/Pusher.

      Appreciate the suggestion!

  3. 1

    so its similar to what omegle was, looks interesting

    1. 1

      Yeah, similar concept,
      But I’m trying to keep it simpler — no signup, faster connection, and less clutter.
      Still improving it step by step.

  4. 1

    Sounds very interesting. But how do you plan to monetize this app?

    1. 1

      Right now I’m focusing on growth and user experience. Still figuring out monetization

  5. 1

    Gowrishankar, hitting 65K organic clicks by treating "zero friction" as a growth strategy is a masterclass in product-led SEO. By removing the traditional DB/OAuth barrier and relying on a lean WebRTC/Node.js stack, you’ve proven that for high-intent long-tail queries, the user experience is the distribution engine.
    I’m currently running Tokyo Lore, a project that highlights high-utility logic and validation-focused tools like yours. Since you’re building the definitive case for how removing friction scales product-market fit, entering Chatzyo could be the perfect way to turn this growth milestone into a winning case study while your odds are at their absolute peak.

    1. 1

      Thanks a lot, really appreciate this

      “User experience as distribution” is exactly what I’m starting to realize now.

      Initially I thought SEO = keywords + backlinks, but in this case:

      • reducing friction improved engagement
      • which improved rankings

      Still experimenting with this approach.

      Curious — how are you handling validation/early traction in Tokyo Lore? Are you also focusing more on UX signals or distribution channels?

      Also, I wrote a more detailed breakdown of what worked here if you're interested:
      https://chatzyo.hashnode.dev/no-login-webrtc-chat-app-nodejs

      1. 1

        hat shift you described is exactly it — UX → engagement → rankings. Most people don’t connect that loop early enough.

        On Tokyo Lore, we actually look at both, but in a slightly different way:

        → UX signals: does the idea create immediate clarity + low friction (like yours)
        → distribution: can it naturally spread or get picked up in the right places

        But more than metrics, we focus on how real builders react to it — what they notice, what they question, what sticks.

        That’s where early traction signals usually show up.

        Your “no login + instant use” approach fits really well into that — it’s inherently shareable.

        Also checking out your breakdown — looks solid 👀

        Tokyolore.com

        1. 1

          That makes a lot of sense,

          The “how real builders react” part is interesting — I’m starting to see that too from feedback and usage patterns.
          The no-login approach seems to reduce hesitation, which probably helps it spread more naturally.
          Still experimenting, but this gives me a clearer direction.

          Appreciate you sharing this.

          1. 1

            Yeah exactly — that “reduced hesitation → more usage → more sharing” loop is where things start compounding.

            What you’re seeing is a strong early signal already.

            If you want, we can actually test this more deliberately inside Tokyo Lore — see how builders interact with it and what patterns show up.

            Could be a good way to validate what’s working vs what to double down on.

            Happy to share the link if you’re open 👍

Trending on Indie Hackers
Hi IH — quick update. The MVP is live. User Avatar 33 comments Building ExpenseSpy solo, no funding — launching June 17 on iOS & Android User Avatar 27 comments Day 7: 51 people answered my question. I wasn't ready for what they said. User Avatar 18 comments I Built a Football Sentiment Platform in 18 Days. The World Cup Starts in 7 Days. Now I Need Distribution. User Avatar 17 comments Built an n8n booking alert system — is cold outreach dead for B2B micro-tools? User Avatar 16 comments I built a $5/1k-listing CRE data API because CoStar is overkill for first-pass scans User Avatar 14 comments