Construir producto te cambia la mirada

Llevo meses usando una aplicación que me he hecho yo mismo. Se llama Alba Tracker y sirve para registrar mis sesiones de ejercicio matinal. Nada sofisticado: caminar, correr, andar en bici pública. Duración, distancia, alguna nota si me apetece. Eso es todo.

La he construido con Mocha, una herramienta de lo que ahora llamamos Vibe Coding. Escribes lo que quieres, la herramienta genera código, tú lo revisas, ajustas, vuelves a pedirle cosas. Un diálogo iterativo entre tu intención y la capacidad técnica de la máquina.

Lo interesante no es la aplicación. Es lo que pasa cuando la construyes.

El descubrimiento de los pliegues

Cuando diseñamos interfaces, pensamos en flujos, en jerarquías, en estados, en feedback visual. Es un trabajo que dominamos. Pero cuando construyes el producto entero, aparecen cosas que desde el diseño no se ven.

Por ejemplo: la autenticación con Google dejó de funcionar y la pantalla se quedaba en blanco. El problema estaba en un worker de Cloudflare que no exportaba correctamente un endpoint. Palabras que hace cinco años me habrían sonado a chino y que ahora, gracias a estas herramientas, puedo entender, empezar a diagnosticar y resolver con ayuda.

O el cálculo de calorías. Implementarlo significa definir fórmulas específicas según el tipo de actividad, almacenar el peso del usuario, recalcular datos históricos cuando cambia ese peso o mostrar todo eso en la interfaz sin que haga ruido. Son capas que desde Figma no podemos ver porque no existen.

Cada funcionalidad tiene sus recovecos. La paginación de resultados. El modo oscuro automático según la configuración del sistema. El favicon, la imagen para compartir en redes sociales, el orden cronológico de las sesiones. Decisiones que parecen menores pero que, sumadas, definen si un producto suena bien o parece descuidado.

Lo que cambia cuando ves la cocina

Construir producto con estas herramientas no te convierte en desarrollador, ni mucho menos. Pero te da algo muy valioso: la capacidad de entender qué pasa debajo del capó. Y eso tiene consecuencias directas para tu trabajo de diseño. Lo dijo Freddy Vega el otro día.

Más adelante, cuando entiendes que una funcionalidad implica tocar la base de datos, crear migraciones, gestionar estados de error, la forma de proponerla cambia. No la simplificas por miedo técnico, pero tampoco la complicas de manera innecesaria; ni de lejos. En realidad lo que pasa es que adquieres criterio sobre lo que cuesta y lo que implica hacer las cosas.

También empiezas a ver el producto como un sistema vivo. Alba Tracker tiene un changelog que documenta su evolución: primero la estructura básica, luego el modo demo para probar sin registro, después las estadísticas en tiempo real, más tarde las calorías, la bici pública o las mejoras de layout móvil. Cada iteración resuelve algo que la anterior dejó pendiente.

Eso es pensar en producto. No es sólo diseñar pantallas, es diseñar un sistema que evoluciona.

El conocimiento como piedra angular

Hay en todo esto una trampa fácil: pensar que estas herramientas van a sustituir a los profesionales o que cualquiera podrá hacer lo que hacemos nosotros.

Mi experiencia dice exactamente lo contrario.

Mocha genera código. Pero cada decisión que tomé durante la construcción de Alba Tracker venía de mi conocimiento de diseño:

• Por qué el estilo visual se inspira en 37signals
• Por qué los botones de acción tienen el tamaño que tienen en móvil
• Por qué la información se agrupa de esa manera
• Por qué el pie de página existe
• Por qué hay un modo demo que permite probar antes de registrarse

La herramienta acelera la ejecución. La intención sigue siendo humana. Y la posibilidad de que todo estalle si el código no se audita, también.

Y eso es lo importante: el qué construir, para quién, y por qué. Esas preguntas no las responde ninguna IA. Las respondemos los profesionales que llevamos años observando usuarios, entendiendo contextos, diseñando sistemas de información.

Las herramientas pasan. Los criterios permanecen.

Mayor valor, mayor control del outcome

Lo que me ha dado construir Alba Tracker con Mocha es algo muy concreto: control sobre el resultado.

Antes, mis ideas de producto dependían de que alguien las desarrollara. Ahora puedo iterar directamente sobre el producto. Ver que algo no funciona bien en móvil y arreglarlo en el momento. Probar una funcionalidad, descartarla si no aporta o incorporar otra que no había previsto.

Ese ciclo corto de feedback me resulta tremendamente valioso. Y genera un tipo de eficiencia que no tiene que ver con ir más rápido, sino con ir más directo al objetivo.

No es magia, es herramienta

Conviene de todos modos bajar las expectativas. Construir Alba Tracker me llevó iteraciones, errores, correcciones y replanteamientos (además de bastantes cabreos y sensación de que por momentos esto se me iba de las manos). La herramienta no adivina lo que quieres. Tienes que saber pedirlo. Tienes que revisar lo que genera. Tienes que tener criterio para decidir si lo que ves está bien o necesita ajustes. Es decir: tienes que saber de lo tuyo.

Estas herramientas amplían lo que ya sabes hacer. Pero si no sabes nada, amplifican ese vacío y se te ven las costuras. Un diseñador con criterio puede construir productos coherentes. Alguien sin criterio generará código que aparenta funcionar pero que no tiene sentido.

La diferencia no está en la herramienta. Está en quién la usa y cómo.

Una invitación

Si eres diseñador y no has probado a construir algo completo con estas herramientas, te lo recomiendo. No para convertirte en otra cosa, sino para entender mejor lo que ya eres. Pensar en producto tiene muchos pliegues y muchos matices. Algunos sólo se ven cuando te manchas las manos. Y mancharse las manos, ahora, es más accesible que nunca.

Alba Tracker es una aplicación pequeña para un problema pequeño. Pero construirla me ha enseñado más sobre producto que muchos proyectos profesionales de mayor envergadura en los que tenía una capacidad de intervención distinta.

A veces, lo valioso no está en la escala sino que está en la profundidad del ejercicio.