Personal Project
Anonymous Chat Platform
Personal project building a truly anonymous, ephemeral chat platform, combining technical and design implementations to obfuscate messages and protect users, deployed as a production-grade product.
- OUTCOMES
- Architected a zero-trust privacy model
- Engineered a per-message anonymization engine
- Shipped a full 0-to-1 production-grade product
- OWNERSHIP
- Solo build
- TIMELINE
- 2026 - Present
Problem
Camonote is a place to talk with anyone, strangers or friends, without leaving a digital footprint. Every user is anonymous and every conversation is temporary. Two uses drove it: anonymous, topic-based conversation with no accounts and no usernames, closer to Reddit as a live chat than to a messaging app, and a safe way to organize activism, where a paper trail is a liability.
The hard part is that real anonymity and real ephemerality fight almost every default of how chat is built. Messaging apps create records. Even the secure ones tie identity to a phone number, keep metadata, or store history on a device that can be seized. Building the opposite means giving up the things that make chat easy to ship:
- No accounts means no identity to attach activity to
- No message storage means no history to hand over
- No user list means nobody, including you, can see who is in a room
- Anonymity inside a conversation means participants cannot identify who sent what message
These are constraints that shaped the architecture from the first decision, which made this a strategy problem before it was a design or engineering one.
Approach and key decisions
I owned the entire product lifecycle. This included strategizing around its constraints, creating the design system and interface in Figma, and building and deploying to Vercel. I used Claude Code as my engineering partner, comparing tools, workflows, architecture calls, and third-party analytics platforms while weighing tradeoffs.
Key decisions and tradeoffs included:
Per-message anonymity. Every message is stamped with a random emoji identifier the moment it is sent, so one person sending five messages appears as five different identifiers. Nothing stable ties a message back to a user.
Tradeoff: this gives up threaded, reply-to readability. For a product whose whole promise is that you cannot tell who said what, conversational continuity is the right thing to trade away.
Keep messages in memory and let them vanish. Messages live only in server memory and the current browser tab. A channel wipes its history when a person leaves, and a refresh discards whatever the client was holding. There is no database and no archive.
Tradeoff: the same choice that guarantees ephemerality creates an empty-channel problem, since an empty channel has no history to make it feel alive. This is an intentional decision to keep conversations moving forward instead of dwelling on past context.
Channels with no owner. A channel is just a name that doubles as its address. Anyone can create or join one, there is no admin, no roster, and no way to enumerate who is present.
Tradeoff: no ownership means the usual moderation levers do not exist by default. This is the biggest risk to keeping the platform safe and preventing it from becoming another 4chan or 8chan.
Real-time on Durable Objects. I built the real-time layer on PartyKit and Cloudflare Durable Objects, one object per channel, broadcast and forget. There is no persistent backend to run and infrastructure cost stays near zero.
Tradeoff: one object per room is simple and cheap, and it puts a ceiling on how much a single hot channel can take before it needs a rethink. That was the right cost for a 0-to-1 build.
Built a design system as the foundation. I built Playcraft, a small atomic design system with its own tokens, theming, and components, deployed to Storybook as the source of truth.
Tradeoff: more upfront work than styling screens directly. It is the reason the interface is consistent, documented in Storybook, and testable in isolation.
The biggest risk. Content moderation. With no accounts and no stored messages, the usual moderation tools do not apply, and I shipped without automated filtering, reporting, or bans. That is a real gap, and I scoped it as known future work instead of claiming the problem was solved. Anonymity should enable freedom without excusing abuse, and closing that gap responsibly is the next hard problem I need to solve.
Impact
Camonote is live at camonote.com and anyone can use it today. The outcome I care about is proof that I can take a product from a strategic idea through design, engineering, and production deployment on my own. User count and adoption were never the point.
This is a hard problem solved cleanly. Per-message anonymity, zero message persistence, no user roster, and real-time chat at near-zero infrastructure cost. The architecture itself enforces the privacy properties, so they hold by construction without depending on a policy to keep a promise.
This is production-grade work, built to run. A self-built design system with full component coverage, unit tests on the core logic, security and accessibility checks, visual regression, and CI. It is built like something meant to run in the real world, because it is already running.