FOMO
01 — El problema
Quedar es fácil. Que la noche funcione, no.
Un grupo de amigos se organiza por WhatsApp: cincuenta mensajes, tres encuestas y nadie confirma. Cuando por fin quedan, el pre se improvisa: hay bebida pero no plan, ganas pero no chispa.
Siempre falta ese amigo que "anima". Los juegos se olvidan, las fotos acaban desperdigadas en cinco móviles distintos y, al día siguiente, la noche se recuerda a trozos. No hay un hilo que conecte todo.
¿Y si una app se encargara de animar la noche por ti?
02 — Investigación
Lo que aprendí observando cómo salen los grupos
Sin encuestas grandes ni datos inventados: observación directa de mi propio entorno y cómo se comporta un grupo cuando sale.
El pre es el momento clave de la noche, pero es donde menos herramientas hay. Todo pasa en un grupo de chat que no está pensado para eso.
Siempre hay un líder natural que propone. Si esa persona se despista, el grupo se queda mirando el móvil en silencio.
Los juegos que funcionan son cortos, sociales y sin reglas complejas. En cuanto hay que leer un tutorial, se abandona.
Nadie quiere otra red social pública. Lo que pasa en el grupo se queda en el grupo. La intimidad es parte de la gracia.
03 — Visión de producto
Un compañero para la noche, no otra red social
FOMO no organiza eventos. FOMO se sienta con el grupo y se encarga de que la noche fluya: propone juegos, lanza retos, guarda los momentos y, al final, los devuelve convertidos en recuerdo. Por colegas, para colegas.
La propuesta de FOMO en una imagen: squad, juegos y momentos.
04 — Recorrido de usuario
El arco de una noche con FOMO
Todo el producto está pensado como un recorrido continuo, del primer pre al recap del día siguiente.
05 — Decisiones de diseño
Cada decisión responde a un problema real
El corazón del case study: por qué FOMO es como es.
¿Por qué squads y no eventos?
¿Por qué decide el líder?
¿Por qué modo oscuro siempre?
¿Por qué no hay feed público?
¿Por qué juegos cortos?
¿Por qué código y QR para unirse?
06 — La interfaz
Flujos clave de la app
Mockups promocionales que recorren los flujos principales: squad, juegos, retos y momentos.
Desliza para ver el mockup completo
07 — Identidad visual
Una marca con la energía de la noche
Color
Tipografía
Por colegas
Titulares bold y contundentes · texto directo y coloquial
08 — Decisiones técnicas
Arquitectura móvil de producto
09 — Alcance técnico
Un producto completo, no una demo
FOMO me permitió trabajar el ciclo completo de un producto móvil: definición, diseño, arquitectura, implementación, estado global, backend gestionado y validación de flujos reales.
La aplicación se construyó como un producto real: con onboarding, squads, juegos, retos, momentos, estado compartido e integración con servicios backend. El foco no fue solo diseñar pantallas, sino conectar decisiones de producto con una implementación mantenible.
Qué se alcanzó
Qué demuestra
El valor principal del proyecto está en haber recorrido todas las fases: entender el problema, convertirlo en flujos, diseñar una experiencia móvil, elegir stack, implementar la lógica y preparar una base técnica lista para seguir creciendo.
FOMO funciona como evidencia de criterio de producto y capacidad técnica aplicada a una app completa, no como una landing pensada para vender una idea.
Hoy FOMO se presenta como caso de estudio de diseño de producto, arquitectura móvil y desarrollo de aplicaciones sociales: un producto concebido, diseñado y construido de extremo a extremo.
10 — Aprendizajes
Qué me llevo de construir FOMO
El producto empieza en el comportamiento, no en la pantalla
La mejor decisión de FOMO (el rol de líder) no salió de un Figma, salió de observar que en cada grupo hay alguien que tira del carro. Diseñar es traducir comportamiento.
Restringir es diseñar
Decir "no" al feed público, a los juegos largos y a las votaciones definió el producto más que cualquier feature que añadí. Cada límite tenía un motivo.
Llegar a producción no termina en el código
Superar revisión en Android y encontrar un límite editorial en iOS me enseñó que la distribución es parte del producto. Construir algo real implica navegar plataformas, categorías y decisiones que el diseño por sí solo no anticipa.