Mood-based social lounge built around brief check-ins, time-limited per-response chats, and conversations that expire naturally — connection without relationship maintenance.

Positioning

Weple is an online social lounge designed for brief, low-pressure connection with people whose mood and conversation window match yours right now. Meeting in person isn’t the goal — connection itself is the goal, and time spent inside the lounge is its own complete experience.

Market and Problem

Most social products assume profile maintenance, persistent follow graphs, and ongoing feed participation — high overhead. But many users want something simpler: “I want to connect for a moment, right now.” Dating apps are too heavy. Anonymous chat is too light, and unsafe.

Weple lives in between — enough conversational context to feel real, low enough commitment to feel free. Auto-expiry of check-ins and chats is the core mechanism.

Core Audience and Personas

Users who want light connection — Brief emotional exchange over deep relationship building
Mood-first users — People who pick “who to talk to right now” by current state, not by photo / résumé
Socially fatigued users — Those avoiding both the maintenance cost of public feeds and the irresponsibility of fully anonymous chat

Value Proposition and Differentiation

Mood-first matching — The primary match key is current state and conversation tone, not personal credentials. Mood comes before identity
Auto-expiring sessions — Check-ins and chat rooms close on a schedule. The system removes relationship maintenance pressure structurally — “it can end” replaces “it has to end”
Per-response separate rooms — Multiple responses to one check-in open into separate 1:1 rooms, avoiding the noise of group chats
Private check-ins — Invite-link-only mode for friend / colleague / interest groups using Weple as a private lounge

Core User Flow

Minimal profile: Nickname + lightweight preferences. No long bio required
Open a check-in: Pick lounge (atmosphere category), mood, connection style, conversation window, and visibility — post in 1–2 lines
Receive responses + match: Other users with matching mood and time respond → notification
Enter chat: 1:1 room per response, conversation within preset time limit
Natural close: Room expires automatically. Exchange external contact if you want to continue, or let it dissolve naturally

Check-in → match → time-bounded conversation flow

flowchart TD
    User1["User A
opens check-in
(mood · time · lounge)"]
    User2["User B
finds it in feed
responds"]
    Match["Response = match
dedicated room created"]
    Chat["1:1 chat
preset time limit"]
    End["Time expires
room auto-closes"]
    Keep["Exchange external contacts
(continue outside system)"]
    Forget["Let it dissolve naturally
(no obligation)"]

    User1 --> Match
    User2 --> Match
    Match --> Chat
    Chat --> End
    End --> Keep
    End --> Forget

Ephemerality is the system default — not continuing a relationship is the natural ending, not a failure mode.

Business Model Hypothesis

Monetization will be validated in stages.

Pro lounges (hypothesis) — Bundled paid tier: longer check-in windows, response priority, unlimited private lounges
Group / company lounges — Companies, clubs, communities lease members-only private lounges as casual internal social space
Event-coupled lounges — Time-bounded lounges tied to offline events (meetups, concerts, conferences) for in-the-moment connection between attendees

System Architecture (planning decisions become system structure)

Two planning decisions drove the architecture.

1. “Ephemerality must be enforced by the system.” → Check-ins, chat rooms, and responses all carry expiration metadata. Firestore TTL + client-side filters drop expired items immediately. The lounge always shows only “conversations alive right now” — no operator intervention required.

2. “Light connection should also have light authentication and operations.” → The workspace standard is a self-hosted backend (Hono + MySQL), but Weple stays on Firebase (Auth + Firestore + Storage). Bundling realtime chat, expiry handling, and authentication on a single platform keeps operational cost low — a deliberate exception that lets a solo operator carry a different lifecycle from the other eight services.

flowchart LR
    Web["Vite + React 19
web app"]
    Auth["Firebase Auth
(Google sign-in)"]
    FS[("Firestore
users · checkins
rooms · messages")]
    Storage["Firebase Storage
(avatars, etc.)"]
    CDN["CloudFront → S3
weple.oos.kr/web"]

    Web --> Auth
    Web --> FS
    Web --> Storage
    CDN --> Web

Separated from the other services’ shared Hono API. api.oos.kr/v1/* exists as a health-only stub for future expansion.

Technology Choices and Trade-offs

Frontend: Vite + React 19 + TypeScript. Same build stack as the other services for shared tooling and learning
Backend / Realtime: Firebase Auth + Firestore + Storage (the exception). Bundling realtime chat, social graph, and TTL on one platform simplifies operations. The other eight services share a Hono core — this is a deliberate split: “ephemeral + realtime” workloads play to Firebase’s strengths
Hosting: Build artifacts follow the workspace standard — S3 (weple.oos.kr/web/) + CloudFront. Service-level operational consistency
What was dropped: Self-hosted chat infrastructure (Firebase is fast and cheap enough), persistent social graphs (other SNS does that well — we own ephemerality), recommendation algorithms (with sparse early check-ins, simple chronological + mood filters are more honest)

Operational Automation

Expiry cleanup — Messages from expired check-ins and closed rooms are auto-deleted after a retention window. Manages Firestore cost and user privacy together
OG auto-generation — Sharing a lounge composes a static OG image with mood color + lounge name
Build guardrails — tsc + theme-lint block off-token color and typography use; new components stay design-consistent by construction

Current State and Operational Signals

Status: Live. Check-ins, matching, time-bounded chat, and private lounges operational
Started: 2026-03 (initial release on Vite + React + Firebase)
Infrastructure: Firebase (Auth + Firestore + Storage) + S3 (weple.oos.kr/web/) + CloudFront
Verification signals: Tracking same-user return visit patterns (vs one-shot check-ins), average conversation duration, and post-expiry external-contact exchange rate

Retrospective and Next Hypotheses

What worked: Encoding ephemerality as a system default — users do not feel guilt about “not continuing” a relationship. Mood-first matching produces a tone clearly distinct from dating apps
What I would redo: Opening too many lounge categories early created an “I don’t know which one to enter” friction. Starting with 3–5 and expanding by usage signal would have onboarded more naturally
Next hypotheses: (1) Pro lounges (extended time, response priority), (2) Private leased lounges for companies / groups, (3) Event-coupled time-bounded lounges, (4) Mood embedding-based recommendation (after enough check-in accrual)

Comparable Engagements

The capabilities developed solo on Weple transfer cleanly to other domains.

Social / collaboration products where ephemerality is the default — Group chats, event lounges, temporary collaboration spaces — anywhere “the relationship ending is natural” is part of the product thesis
Firebase-native realtime chat + matching systems — Auth + Firestore TTL + Storage bundled into a solo-operable realtime social backend
Mood / context-first matching UX — Designing flows where current state (mood, time, intent) is the primary match key, not credentials (profile, photo, résumé)
Choosing exception stacks in a multi-service environment — Knowing when to deliberately exempt a workload from the standard stack because the workload’s profile fits a different platform better
Low-overhead social MVPs that validate fast — Spending validation time on the hypothesis, not on building infrastructure

I prefer engagements where one person carries the work end to end. Reach me via /work-with-me or /contact.