Krenno
All projectsCase study
Web AppSocial2024webmobile-web

Kingle

Anonymous conversations at internet speed, engineered as a complete social product.

Meet someone new in seconds — live video or text, no app required.

Client

Krenno Labs

Engagement

internal product

Krenno roleProduct strategyExperience designFull-stack engineeringReal-time systems architecture+2 more
Positioning

Why this product exists

Kingle removes the friction of traditional social apps. There is no profile to build, no feed to maintain, and no download to wait for. People arrive, get matched, and talk — with live video, live text, and the freedom to move on the moment a conversation is over.

Kingle shows that Krenno Labs can ship a full consumer social product spanning live matching, WebRTC media, signaling, presence, and conversation UX in a single architecture. It is evidence that we can take a high-stakes real-time idea — strangers meeting on camera — and turn it into a polished, controllable, commercially presentable platform. For a similar client, Krenno can design the product, the matching rules, the media path, and the safety posture as one delivery, not as disconnected features.

Built for

  • People who want spontaneous one-to-one conversations without creating a social profile
  • Consumer social startups exploring random-match or live-discovery products
  • Community and events teams that need instant, anonymous video rooms
  • Product leaders evaluating real-time media, matching, and presence architecture
The story

Challenge, approach, solution

01

The Challenge

Most social products ask people to invest in a profile before they get a conversation. That delay kills spontaneity. The opportunity was to build an instant meeting product that still feels trustworthy: anonymous by default, fast to match, clear to control, and strong enough to carry live video between two strangers who have never met. The engineering bar is high because the product only works if matching, signaling, media, and session lifecycle all succeed in the same moment. A slow queue, a broken camera handshake, or a stuck 'online' state would collapse the entire experience.

02

Our Approach

We treated Kingle as a real-time operations problem as much as a social interface. The product is organized around three surfaces — a public landing experience, a video conversation workspace, and a text-only conversation workspace — so users always know where they are and what happens next. Behind those surfaces, an anonymous user record, a matching engine, and a Socket.IO signaling layer coordinate who is available, who is already in a session, and how two browsers complete a WebRTC handshake. The design priority was immediate agency: start, talk, skip, or leave, without account friction.

03

The Solution

Kingle is a complete stranger-conversation platform. Users enter anonymously, the platform finds an available counterpart, and a private session opens with live video, live audio, and side-by-side text. Peer-to-peer media keeps the conversation direct. Server-side matching keeps occupancy honest. Presence events keep the live population visible. The result is a product people can use immediately in the browser, including on phones and tablets, with a clear safety posture: chats are anonymous unless a user chooses otherwise, sessions can be ended at any time, and the experience is framed for adults.

Experience

The Experience

A visitor arrives on a focused landing page that explains the product, sets expectations around anonymity and conduct, and offers two clear starts: Text Chat or Video Chat. Choosing video opens a split workspace — local and remote cameras stacked on one side, the conversation transcript and composer on the other. The platform acquires camera and microphone access, registers the user as available, and searches for another idle participant. When a match is found, WebRTC connects the two peers, the remote video appears, and typed messages travel across a data channel without leaving the call. A Next control ends the current pairing and looks for someone new. Leaving the page returns the user to an inactive state so they are no longer offered to others. Text mode offers the same matching-and-conversation rhythm without cameras, for people who want the social spark without video.

Product

What we built into the product

Instant stranger matching

Pairs each available person with another active, unoccupied user in real time, so conversations start from a live pool rather than a static list of profiles.

Peer-to-peer video conversations

Opens a private live video and audio session between two matched users directly in the browser, with local preview and a dedicated remote stage.

In-call messaging

Lets both people type while they are on camera. Messages appear in a shared transcript and travel over a WebRTC data channel alongside the media streams.

Text-only conversation mode

Provides a camera-free path into the same random-match experience for users who prefer writing first or are on a device where video is not the right start.

Skip and rematch

Gives either participant a Next action to leave the current stranger and request a new pairing, keeping the product fast, voluntary, and under user control.

Also included

Anonymous session identity

Creates a lightweight session identity without a public profile, email, or social login, then reuses it on return so availability can be restored without asking the user to sign up.

Live presence and occupancy

Tracks who is connected, who is idle, and who is already in a conversation, then surfaces live occupancy so the product feels populated and operationally honest.

Safety-first conversation framing

Sets adult-only expectations, emphasizes anonymity, makes it easy to stop a chat, and presents video as a monitored, keep-it-clean environment rather than an ungoverned feed.

Browser and mobile-web access

Runs as a responsive web product, so people can start a conversation from a phone, tablet, or desktop without installing an application.

Interest-aware pairing

Supports the product vision of matching people who share selected interests, so random conversation can still feel relevant rather than purely accidental.

Session lifecycle management

Registers users on arrival, marks them engaged when a match starts, and returns them to inactive on leave, preventing ghost users from clogging the match pool.

Direct send-from-keyboard chat

Sends messages from the composer with click or Enter, keeps the transcript scrolled to the latest line, and labels local versus stranger messages for a readable conversation.

Gallery

Product surfaces

Visual placeholders mark where final screens and captures will live. Drop assets at the paths shown on each tile.

Engineering

How it's built

Kingle is split into a server-authoritative match layer and a peer-to-peer conversation layer. A user loads an EJS surface, the client captures media when video is selected, and the session API creates or reactivates an anonymous MongoDB user with active=yes and status idle. Matching runs as an aggregation: exclude the requester, require active and idle, then sample one eligible user. Both records are marked engaged and Socket.IO notifies the pair to start. From that point the browsers run a WebRTC handshake over Socket.IO — offer, answer, ICE candidates — until remote tracks appear and a data channel opens for text. Presence is broadcast on connect and disconnect so occupancy stays live. Leaving the page marks the user inactive so they drop out of the pool. The server never has to carry the video bits; it carries the rules.

API-drivenevent-driven signalingpeer-to-peer mediamodular MVCreal-time presencesession-state machine

Decision

Keep matching and occupancy on the server, and keep video on a peer-to-peer path.

The platform must be the source of truth for who is free to talk, but it should not become a media bottleneck or a surveillance pipe for every frame.

The product stays fair and controllable while conversations remain low-latency and scalable with the number of simultaneous pairs.

Decision

Model availability as an explicit active/status state machine in MongoDB.

In-memory-only presence would vanish on restart and could not be queried for random eligible users. Idle versus engaged has to be durable and filterable.

Matching can sample a real pool, engaged users are not offered twice, and leave events cleanly return people to inactive.

Decision

Use Socket.IO as the WebRTC signaling and presence channel.

Browsers cannot exchange SDP and ICE without a rendezvous service. An evented channel also gives occupancy updates and match-start notifications on the same pipe.

One realtime layer covers connection setup, live user counts, and session coordination without a second protocol.

Stack

Kingle is a Node.js real-time product: Express renders the experience, MongoDB holds availability state, Socket.IO coordinates signaling and presence, and WebRTC carries video, audio, and in-call text between peers. The stack was chosen so matching and occupancy stay under server control while media stays on the shortest path between two browsers. That split is the engineering signature of the product — an authoritative match layer with a peer-to-peer conversation layer — and it is the same pattern Krenno uses when a client needs live communication that still has rules.

EJSVanilla JavaScriptjQueryWebRTCSocket.IO clientCustom CSSNode.jsExpressSocket.IOMongooseMongoDBExpress static asset pipelinedotenvCORS-aware Socket.IO serverAnonymous-by-default sessionsEnvironment-isolated secretsAdult-only access framingGoogle STUN
Process

From brief to shipped product

  1. 01Discovery

    We started from the actual user job: meet a new person immediately, without a profile, and retain the right to leave. That framed the product around matching speed, anonymity, dual conversation modes, and a visible safety posture for live video between strangers.

  2. 02Design

    The information architecture is three surfaces with one brand. Landing explains the offer and the rules. Video uses a split working layout so faces and messages are both first-class. Text keeps the same composer and Next control without cameras. Visual language stays direct: Roboto, sky highlights, and a high-contrast navy action gradient.

  3. 03Development

    Engineering was built as a state machine plus a media path. The session API and MongoDB model own availability. Socket.IO owns signaling and presence. The browser client owns getUserMedia, RTCPeerConnection, and data-channel chat. Each user flow — create, return, match, engage, talk, leave — has a corresponding server transition.

  4. 04Testing

    The critical paths are match eligibility, double-booking prevention, offer/answer/ICE completion, remote track display, data-channel send and receive, occupancy updates on connect and disconnect, and inactive marking on unload. Those flows define whether the product feels alive.

  5. 05Launch

    The platform runs as a Node service with MongoDB and Socket.IO, environment-based configuration, and browser access on desktop and mobile web. Once live, a visitor can go from landing to a matched conversation without installing anything.

Challenges

Hard problems, clear outcomes

Matching strangers without colliding sessions

Problem

A random-chat product collapses if two people are offered the same idle user, if a busy user is still treated as available, or if a departed user remains in the pool.

Approach

We modeled each participant as active/inactive and idle/engaged, sampled one eligible counterpart with an aggregation, then locked both records to engaged before signaling the pair to start.

Outcome

The platform can offer a real person, keep that person off the next search, and return them to inactive when they leave, which is the difference between a conversation product and a noisy queue.

Making live video work between two unknown browsers

Problem

Strangers are on different networks, behind NATs, and on devices that may or may not grant camera access. A product that only previews a local camera is not a conversation.

Approach

We used WebRTC with STUN-backed ICE, a Socket.IO signaling path for offer, answer, and candidates, and an explicit local-to-remote track pipeline so the remote stage fills when the handshake completes.

Outcome

Two people who have never exchanged a link can still end up in a private live session, which is the core commercial promise of the product.

Keeping presence honest in a live occupancy product

Problem

If connect, engage, and leave drift apart, the interface will claim people are online who are not, or hide people who are waiting.

Approach

Socket connections maintain an in-memory registry and broadcast occupancy, while HTTP session routes persist active and status changes, including unload and beforeunload leave updates.

Outcome

Availability is visible and actionable. The match pool reflects who is actually ready to talk, and the product can show a live online count with a straight face.

Unifying video and text without splitting the product in two

Problem

Stranger chat needs both a camera path and a typing path. If those are unrelated apps, the brand fragments and users lose the skip-and-continue rhythm.

Approach

Video sessions carry a WebRTC data channel for in-call messages, and a dedicated text surface reuses the same conversation chrome — transcript, composer, send, and Next.

Outcome

Users get one product with two intensities of presence. They can talk on camera with messages beside the feed, or start in text when video is not the right first move.

Designing trust into an anonymous live meeting

Problem

People will not turn a camera on for a stranger unless the product feels bounded: anonymous, escapable, adult-only, and explicit about conduct.

Approach

The landing experience leads with anonymity, the right to stop, age eligibility, and monitored-video expectations, while the workspace keeps Next and leave immediately available.

Outcome

Safety is part of the product story and the interaction model, which is what a commercially serious stranger-video platform has to look like.

Proof

What this work proves

Kingle concentrates a full real-time social product into one platform: anonymous entry, live matching, peer-to-peer video, in-call text, skip, presence, and a mobile-ready web experience. It gives Krenno Labs a concrete demonstration of consumer social engineering — the kind of system where product design and network architecture have to succeed together. For a client, that translates into a credible starting point for live discovery, event icebreakers, language exchange, or any product that needs two people talking within seconds of arriving.

Consumer social product designReal-time matching enginesWebRTC and peer-to-peer mediaSocket-based signaling architecturePresence and session lifecycleAnonymous identity patternsTrust-and-safety UX for live videoResponsive conversation workspacesNode.js and MongoDB operational backendsMulti-surface information architecture

What's next

AI-assisted conversation safety

Extend the existing monitored-video posture with intelligent detection for policy violations so operators can keep the live pool clean as volume grows.

Interest and language intelligence

Deepen pairing with shared interests, spoken language, and conversation goals so random matches still feel relevant without turning the product into a dating profile.

Operator analytics and moderation console

Give platform owners live occupancy, match success, report queues, and ban controls so Kingle can be run as a managed social service rather than an unattended room.

Have something in mind?

Tell us about your product and we'll help you ship something worth putting on this page.

→Start a project

Next project

KrBets

A white-label sportsbook operators can brand, launch, and run as their own.

View case study