Empiezo hoy una serie de posts en los que voy a ir contando las aplicaciones que he ido construyendo a lo largo de 2025 mientras aprendía Vibe Coding. No sé cuántas serán, tengo varias en el cajón, pero creo que merece la pena documentar el proceso porque hay más chicha de la que parece a simple vista.

Empiezo por What To Wear, que fue una de las primeras y la que más veces he iterado.
La premisa: cero fricción
La idea de esta aplicación surgió de una necesidad cotidiana y muy tonta, casi ridícula: saber qué ponerme antes de salir de casa sin tener que interpretar iconos meteorológicos, porcentajes de precipitaciones o gráficos de temperatura por horas. Quería algo que me dijera, en lenguaje humano sencillo, qué tipo de ropa era razonable para ponerse ese día.
Pero sobre todo quería una cosa: que no hubiera que hacer absolutamente nada. Ni pulsar botones, ni elegir ciudades, ni configurar preferencias. Abres la aplicación y ya está. Eso es todo. Parece sencillo, ¿verdad? Pues ahí está precisamente estaba el reto.
Lo que hay por debajo
Cuando dices “no hay interacción” lo que en realidad estás diciendo es que toda la complejidad te la comes tú como diseñador y desarrollador. De ese modo la aplicación:
- Pide acceso a la geolocalización del dispositivo (el único momento en que el usuario tiene que hacer algo).
- Conecta con un servicio meteorológico externo para obtener datos en tiempo real.
- Procesa esos datos y los almacena en una base de datos para optimizar las consultas posteriores.
- Traduce la información meteorológica a recomendaciones de vestimenta, categorizadas por tipo de ropa, no por prendas específicas. Esto es importante: no te digo que te pongas una chaqueta Barbour, te digo que necesitas abrigo ligero. La libertad de elección sigue siendo del usuario.
- Detecta condiciones extremas: olas de calor, heladas o tormentas severas y añade recomendaciones de salud cuando corresponde.

Todo esto ocurre en décimas de segundo. Si tarda, falla. Si falla, no sirve.
Decisiones de diseño que importan
He trabajado bastante el estilo visual para que se parezca a lo que hace 37 Signals con sus productos: limpio, tipografía clara, jerarquía visual evidente, cero adornos innecesarios. La información más relevante como qué tiempo hace y qué ponerte, tiene que entrar por los ojos sin esfuerzo. Como cuchillo en mantequilla.
La localidad en la que está el usuario aparece siempre visible para eliminar la incertidumbre: sabes que la aplicación está funcionando correctamente porque te confirma dónde estás.
Un apunte sobre la decoración navideña: intenté añadir algunos elementos decorativos festivos y, siendo honesto, no me ha convencido el resultado. Pero tiene fecha de caducidad: el 7 de enero desaparece automáticamente, así que lo considero un experimento controlado. A veces iterar también significa saber cuándo has estirado demasiado el chicle y la cosa ha quedado un poco meh.

Lo que aprendes construyendo producto
Esta aplicación la hice con Lovable, y de lo que más satisfecho estoy es del resultado final como producto terminado. Funciona. No da errores. Hace exactamente lo que promete.
Pero para llegar ahí he tenido que entender y tomar decisiones sobre:
- Arquitectura de la información: qué mostrar, en qué orden, con qué prioridad.
- Integración con APIs externas: gestión de errores, tiempos de respuesta, fallbacks.
- Persistencia de datos: cuándo guardar, cuándo consultar, cómo optimizar.
- Diseño de interacción (o mejor dicho, de no interacción): anticiparte a lo que el usuario necesita sin preguntarle.
- Diseño visual: coherencia, legibilidad, jerarquía.
- Edge cases: ¿qué pasa si no hay conexión? ¿Y si el GPS falla? ¿Y si el servicio meteorológico no responde?
Esto es construir producto. No es sólo maquetar pantallas bonitas ni escribir código que funcione. Es el conjunto de decisiones que hacen que algo sea útil, fiable y, con suerte, agradable de usar.
Iré publicando más aplicaciones de esta serie. Algunas son más complejas, otras igual de simples pero con otros objetivos. Lo que tienen en común es que todas me han obligado a pensar como diseñador de producto, no sólo como alguien que escribe prompts para que una IA genere código.
Porque al final, las herramientas de Vibe Coding aceleran la ejecución, pero el criterio profesional sigue siendo insustituible.

