Quicky
Temporary rooms to move text, code and files between devices, no account needed.
- Role
- Everything: product, design, frontend, server and deploy
- Period
- Apr — Jun 2026
- Team
- My own project: 196 of the 232 commits
- Status
- Shut down
Stack: Next.js · TypeScript · Bun · Elysia · Redis · Yjs · Playwright
At school, getting something from the computer to your phone was a chore. Quicky solved it with a room and a 6-character code: you joined, shared messages, code, files and notes in real time, and after 2 hours everything was deleted. It was my first serious project: it was online for anyone, with its own server and built to grow. It's shut down now.
The problem
At school, getting something from my computer to my phone, or to a classmate's computer, was a chore. WhatsApp Web depends on the network not blocking it; Drive asks you to log in, upload and download again. For something that lasts five minutes, every option was slow.

How it works
- You create a room and get a 6-character code. Everyone else joins with that code, no account needed.
- Inside there's a real-time chat with code blocks, polls, notes everyone edits at the same time, and files up to 1 GB you can view without downloading: images, video, audio, PDFs, documents.
- There's an AI assistant inside the room: you call it with @ai in the chat.
- After 2 hours the room closes and everything is deleted: messages, files and notes.

Product decisions
- No accounts. Asking people to sign up for something they use for five minutes loses them at the door.
- Everything gets deleted. A 2-hour room isn't a limitation: it's what lets me not store anyone's data.
- Built for the phone. One end is almost always a phone: menus you swipe to close, long-pressing a message to react, and a "Reconnecting…" notice when the signal drops.
- Whoever creates the room controls it. They can set a password and remove people.
What made it a serious project
It was the first thing I built that was online for anyone, and that brought problems a demo never has: the hosting kept cutting off the real-time connection, the code got away from me and I had to reorganize it from scratch, and I had to think about what happens when someone comes in to break things. I tell the story in this note. What I ended up with:
- The website on one side, and a separate always-on server for the real-time part and the files.
- Limits so nobody can overload the server, and an automatic brake if the disk starts filling up.
- Tests and a check that runs the whole app before every deploy: if anything fails, it doesn't ship.
And one consequence I didn't expect: a few weeks into moving that fast, I couldn't understand my own code. RepoGuide came out of that problem.
From the project · Notes