· Quicky
Quicky: lo difícil no fue que funcionara, fue que siguiera funcionando
Fue mi primer proyecto online de verdad, abierto a cualquiera. Lo que en mi compu andaba bien, en internet se rompía de formas nuevas.
Quicky arrancó el 29 de abril para resolver un problema del colegio: pasar texto, código y archivos entre dispositivos sin cuentas ni vueltas. Creás una sala, compartís un código de 6 caracteres y a las 2 horas se borra todo. En mi compu anduvo enseguida. Los problemas empezaron cuando lo puse online para cualquiera.

1. El hosting no estaba hecho para esto
La primera versión vivía entera en un hosting pensado para páginas web, que corta las conexiones que quedan abiertas mucho tiempo. Para un chat en tiempo real, eso es fatal: los mensajes dejaban de llegar y había que recargar. Lo resolví separando el proyecto en dos: la página sigue donde estaba, y el tiempo real y los archivos pasaron a un servidor propio, siempre prendido.
2. El celular se desconecta todo el tiempo
En la compu la conexión es estable. En el celular se corta cuando bloqueás la pantalla, cuando pasás del wifi a los datos o cuando entrás a un aula sin señal. Quicky tenía que darse cuenta solo, avisar con un «Reconectando…» y volver a engancharse sin que nadie tocara nada.
3. El código se me fue de las manos
Con IA avancé rapidísimo: en un mes tenía chat, archivos, encuestas, IA, notas colaborativas y un panel de administración. Y a las semanas no entendía mi propio código. A principios de junio lo reorganicé desde cero, en partes separadas: la página, el servidor y lo que comparten. De ese problema nació RepoGuide.
4. Si cualquiera puede entrar, cualquiera puede romper
Sin cuentas, cualquiera crea una sala. Eso obliga a pensar en lo que en una demo no aparece: límites para que nadie sature el servidor, un freno automático si el disco se está llenando y que un archivo subido no se pueda usar contra los demás. Hice una auditoría de seguridad propia y fui cerrando lo que encontré, como la posibilidad de hacerse pasar por otra persona dentro de una sala.
5. Que no se rompa al cambiar algo
Al final sumé tests automáticos y una prueba que, antes de cada deploy, levanta la app entera, crea una sala y entra. Si algo falla, no se publica. Sin eso, cada arreglo era una apuesta.
Lo que me llevo
- Que algo funcione en mi compu es la mitad. La otra mitad es que siga funcionando con otros adentro, en otras redes y en otros celulares.
- Ir rápido con IA sirve si después entendés lo que hiciste. Si no, lo pagás con una reescritura.
- No pedir cuentas ni guardar datos fue una decisión de producto, y también hizo mucho más simple la seguridad: hay menos que cuidar.
Hoy Quicky está apagado. El caso completo, acá.
Todas las notas
Todas las notas →