On the 10-minute question: the answer depends entirely on who your actual users are, and right now you're guessing. The privacy crowd might want shorter. People using it to share a quick note with a coworker might want 30 minutes.
Before optimizing the timer or the paid model, I'd suggest watching 5-10 people go through the flow from landing page to creating a room to sharing the link. The create-and-share UX is going to be more important than the timer length — if people can't figure out how to get someone into the room fast enough, the 10-minute clock becomes the wrong problem to solve.
the create > share > join flow is probably the first thing I should validate. If people can’t get someone into the room smoothly, nothing else matters.
- Built using Node + WebSockets
- All chat messages exist only in server memory per room
- When a room expires (10 minutes after first join), the server destroys its in-memory data structure and disconnects clients
- No logs of message bodies (explicitly disabled)
- No database writes for messages; only permanent-room metadata is stored
- Simple per-connection rate limiting to prevent abuse
- Free rooms = 10 minutes, paid rooms = permanent URL with ephemeral messages
- Paid flow uses Stripe; confirmation → claim-room pattern
I’m particularly interested in feedback on:
- Whether 10 minutes is too short/long
- Any privacy or anonymity pitfalls I may be missing
- How to improve reliability / reduce edge case failures
- Whether the paid model makes sense / feels ethical
On the 10-minute question: the answer depends entirely on who your actual users are, and right now you're guessing. The privacy crowd might want shorter. People using it to share a quick note with a coworker might want 30 minutes.
Before optimizing the timer or the paid model, I'd suggest watching 5-10 people go through the flow from landing page to creating a room to sharing the link. The create-and-share UX is going to be more important than the timer length — if people can't figure out how to get someone into the room fast enough, the 10-minute clock becomes the wrong problem to solve.
Thanks!! this is really helpful perspective.
the create > share > join flow is probably the first thing I should validate. If people can’t get someone into the room smoothly, nothing else matters.
really appreciate the feedback!!
Technical details (for anyone curious):
- Built using Node + WebSockets - All chat messages exist only in server memory per room - When a room expires (10 minutes after first join), the server destroys its in-memory data structure and disconnects clients - No logs of message bodies (explicitly disabled) - No database writes for messages; only permanent-room metadata is stored - Simple per-connection rate limiting to prevent abuse - Free rooms = 10 minutes, paid rooms = permanent URL with ephemeral messages - Paid flow uses Stripe; confirmation → claim-room pattern
I’m particularly interested in feedback on: - Whether 10 minutes is too short/long - Any privacy or anonymity pitfalls I may be missing - How to improve reliability / reduce edge case failures - Whether the paid model makes sense / feels ethical