He lanzado cuatro proyectos paralelos en los últimos dos años. Ninguno genera dinero. Todos me hicieron mejor en mi trabajo.
La paradoja del proyecto paralelo
La mejor forma de mejorar construyendo productos es construir productos. Pero en el trabajo, estás limitado -por fechas de entrega, por la arquitectura existente, por decisiones tomadas antes de que llegaras.
Los proyectos paralelos eliminan esas restricciones. Tú eliges el stack. Tú eliges el alcance. Tú decides cuándo lanzar y cuándo tirar todo y empezar de nuevo.
Lo que aprendí de cada proyecto
Riffims me enseñó a pensar en diseño mobile-first no como una técnica responsive, sino como una restricción de producto. Cuando la interacción principal es un pulgar en una pantalla pequeña, cada píxel importa de manera diferente.
Linkims me enseñó sobre theming a escala. Construir un sistema donde cada perfil se ve diferente pero cada perfil es mantenible requirió pensar en tokens y variables de formas que nunca había hecho.
Prelude Icons me enseñó sobre el handoff entre diseño y código. Cuando un icono funciona en Figma pero se rompe en SVG, el problema casi siempre está en cómo se construyeron los paths -no en cómo el código los renderiza.
El permiso para experimentar
En el trabajo, experimentar es arriesgado. Estás gastando el tiempo de la empresa y la buena voluntad del equipo. En un proyecto paralelo, experimentar es el objetivo.
He probado animaciones con GSAP que habrían sido demasiado ambiciosas para una app en producción. He construido arquitecturas de componentes que resultaron ser over-engineered. He escrito CSS que solo funcionaba en un navegador.
Cada fallo me enseñó dónde están los límites.
Empezar en pequeño
No necesitas una gran idea. Necesitas una pequeña que te importe lo suficiente como para terminarla.
Construye una página link-in-bio. Construye una app de temporizador. Construye un portafolio.
El proyecto en sí no importa. Lo que importa es que elegiste cada pieza y entiendes por qué.