Cuando un experimento empieza a comportarse como producto
Las ultimas 24 horas dejaron pocos repos con commits, pero muy concentrados:
2026-06-09 21:44-Update Reveal It builder and scratch experience2026-06-09 22:15-Create Loop It Synth project2026-06-09 22:22-Improve loop quality controls2026-06-09 22:41-Make loop download explicit2026-06-09 22:45-Add MP3 loop export2026-06-09 22:48-Add Gitea Pages workflow2026-06-09 22:59-Deploy Loop It Synth with Cloudflare Pages2026-06-09 23:16-Turn Loop It Synth into a track composer2026-06-10 10:04-Prioritize tracks in Loop It Synth layout
La lectura rapida es: una app de rasca recibió mejoras de UX y otra app musical nació deprisa.
La lectura correcta es mas interesante: las dos dejaron de comportarse como demos aisladas y empezaron a pedir reglas de producto.
La senal no fue el volumen de codigo
Reveal It tuvo un diff enorme: builder, scratch card, sonidos, i18n, checkout, Worker y smoke tests.
Loop It Synth tuvo una secuencia corta pero intensa: generacion del proyecto, controles de calidad del loop, export MP3, despliegue en Pages, compositor por pistas y luego una correccion de layout para dar prioridad al secuenciador.
No son el mismo producto. Ni siquiera son el mismo tipo de interfaz.
Pero ambos activaron la misma cadena:
Lo importante es eso: el punto de madurez no lo marca la cantidad de lineas, sino el momento en que una mejora visible deja de poder vivir sola.
Reveal It: arreglar la preview obligo a tocar el contrato
La conversacion de Reveal It empezo con algo que parecia visual:
la preview de la home debia parecerse a la de
configure, el texto revelado no podia seguir dentro de la imagen, y hacia falta sonido con mute.
Eso parecia CSS. No lo era.
En cuanto la home paso a usar la misma estructura visual que el configurador, aparecieron decisiones mas profundas:
| Capa | Lo que hubo que decidir | Por que importaba |
|---|---|---|
| UI | mover el texto revelado fuera del frame e introducir un boton de mute | la demo de home deja de ser decoracion y empieza a prometer la experiencia real |
| Estado | persistir soundLibraryId ademas del audio generado |
sin eso no puedes distinguir entre "sin sonido" y "tarjeta antigua sin campo" |
| Publicacion | hacer que la tarjeta publicada conserve esa seleccion | si el comportamiento cambia al publicar, la demo estaba mintiendo |
| Pruebas | acotar smoke tests porque la home oculta ya tenia otra .scratch-card |
reutilizar estructura visual cambia tambien lo que las pruebas creen estar mirando |
| Operacion | dejar de usar puertos fijos en smoke | un servidor viejo en 5189 ya habia contaminado la lectura de resultados |
La parte valiosa del chat fue esta: cada vez que una mejora de experiencia tocaba una frontera, hubo que convertir una suposicion implicita en contrato.
No basto con "poner musica". Hubo que decidir que significa el silencio, donde vive el mute, como sobrevive al clon publicado y como se comprueba que no estamos leyendo un servidor viejo.
Loop It Synth: el MVP pidio mezcla, export y jerarquia visual en horas
Loop It Synth comprimio una mini hoja de ruta de producto en menos de un dia:
- Se creo el proyecto.
- Se endurecieron controles para que el loop sonara mas consistente.
- Se hizo explicita la descarga.
- Se anadio export MP3.
- Se sustituyo Gitea Pages por Cloudflare Pages.
- El secuenciador dejo de ser un generador simple y paso a compositor por pistas.
- A la manana siguiente hubo que recolocar el layout porque el monitor empujaba el secuenciador demasiado abajo.
La conversacion final lo dijo con precision: en viewport medio el monitor seguia robando demasiado primer plano y habia que priorizar que las pistas entraran antes que los ajustes.
Eso es una decision de producto, no de maquillaje.
Cuando una app musical pasa de "genera algo" a "compone, exporta y se despliega", la jerarquia de pantalla cambia:
- el secuenciador deja de ser un detalle y pasa a ser la accion principal,
- exportar deja de ser un extra y pasa a ser una promesa,
- y el deploy deja de ser un paso administrativo porque ya hay una URL publica que debe responder
200.
La leccion compartida: una demo tolera ambiguedad, un producto la cobra
En ambos casos hubo una frontera que se volvio visible:
| Caso | Ambiguedad tolerable en demo | Ambiguedad inaceptable en producto |
|---|---|---|
| Reveal It | que la home se parezca "mas o menos" al configurador | que la experiencia publicada no conserve audio, mute o layout prometido |
| Loop It Synth | que el generador produzca algo util aunque el flujo sea lineal | que componer, exportar y usar en distintos viewports no tenga una accion principal clara |
Lo que cambia entre una y otra fase no es solo la interfaz.
Cambia el nivel de precision que exige todo lo demas:
- nombres de estado,
- persistencia,
- selectores de test,
- politica de puertos,
- workflow de deploy,
- y criterio de que ocupa el primer viewport.
Por que esta fase importa
Hay un error comun en proyectos pequenos: pensar que producto significa "hacerlo mas bonito" cuando ya funcione.
Estas 24 horas muestran lo contrario.
Producto aparece cuando el sistema te fuerza a responder preguntas que una demo podia esquivar:
- si el usuario silencia, donde vive esa verdad,
- si el layout compite por atencion, que tarea gana,
- si la publicacion cambia comportamiento, cual de las dos versiones esta mintiendo,
- y si una prueba falla, estas validando codigo nuevo o un proceso viejo todavia escuchando en un puerto fijo.
Lo que me llevo de este tramo
- Un ajuste visual serio casi siempre destapa una deuda de contrato.
- Cuando una demo reutiliza piezas reales, las pruebas dejan de poder ser ingenuas.
- Exportar y desplegar convierten un experimento en una promesa externa; desde ahi la operacion ya forma parte del producto.
- La jerarquia del viewport tambien es arquitectura: decide que accion domina y cual queda subordinada.
Estas apps no crecieron mucho solo en funciones. Crecieron en exigencia.
Y esa es una buena senal: cuando una mejora de interfaz te obliga a alinear estado, smoke tests y deploy, ya no estas puliendo una demo. Estas entrando en territorio de producto.
Parte de mis notas de producto y plataforma. Sigue el blog o escribeme.