Paso
Una ticketera construida desde un handoff de diseño, con cada pantalla medida contra su mock.

Paso es una ticketera argentina para fans, organizadores, RRPP y gente de puerta. Lo que vende es confianza: cada cargo en su propia línea, un QR que la puerta valida sin internet, reventa oficial con tope y RRPP que cobran por lo que venden. El handoff de diseño tenía 66 artboards y 98 pantallas. Construirlas era la mitad del trabajo. La otra mitad era que siguieran fieles al diseño mientras el producto cambiaba por debajo.
Tres decisiones que lo definieron.
- 01
El handoff de diseño como test, no como referencia
Por qué. Un script corta cada artboard en paneles sueltos. Un manifiesto asocia cada panel con la ruta y el estado que lo implementan, con query strings que fijan cosas como un reloj corriendo. `pnpm visual` saca foto del mock y de la ruta real al ancho del artboard, corre pixelmatch y guarda mock, implementación y diff. Con menos de 0,5% de diferencia, la pantalla cuenta como verificada. Una pantalla sin ruta aparece como pendiente, así la lista no se desfasa.
El costo. El diff de píxeles es estricto con cosas que nadie nota. Un breakpoint apenas por encima del ancho de un artboard movió cuatro pantallas entre 5% y 8%. Cuando el producto se aparta del mock a propósito, la pantalla queda marcada como decidida, con el motivo escrito, y se sigue midiendo.
- 02
Las reglas de plata escritas dos veces, atadas con vectores dorados
Por qué. El servicio es el 4% por entrada, con tope de $400. La pantalla lo calcula en un paquete de TypeScript puro. La API en Go calcula lo que se cobra de verdad. Un script genera vectores dorados desde las reglas de TypeScript, incluido el punto exacto donde el tope empieza a mandar, y los tests de Go leen el mismo archivo.
El costo. Dos implementaciones de la misma cuenta. Los vectores detectan un desacuerdo sólo en los casos que listan, así que cada regla nueva pide vectores nuevos.
- 03
Un QR que la puerta valida sin servidor
Por qué. Los lugares pierden señal justo cuando la fila es más larga. Cada entrada lleva una firma Ed25519 y rota cada 30 segundos, así la app de puerta la valida en el teléfono. Las entradas escaneadas quedan en IndexedDB y se comparten entre pestañas por BroadcastChannel. Los teléfonos con señal intercambian sus escaneos cada 20 segundos.
El costo. Dos puertas sin nada de señal pueden aceptar la misma entrada una vez cada una. Cerrar ese hueco pide Bluetooth entre teléfonos, que todavía no está hecho.




Paso
Una ticketera construida desde un handoff de diseño, con cada pantalla medida contra su mock.
- Rol
- Arquitectura frontend y desarrollo full-stack
- Stack
- Next.js + React, pnpm + Turborepo, Go, Postgres + Drizzle, Valkey, Playwright + Vitest

Paso es una ticketera argentina para fans, organizadores, RRPP y gente de puerta. Lo que vende es confianza: cada cargo en su propia línea, un QR que la puerta valida sin internet, reventa oficial con tope y RRPP que cobran por lo que venden. El handoff de diseño tenía 66 artboards y 98 pantallas. Construirlas era la mitad del trabajo. La otra mitad era que siguieran fieles al diseño mientras el producto cambiaba por debajo.
Tres decisiones que lo definieron.
El handoff de diseño como test, no como referencia
Por qué. Un script corta cada artboard en paneles sueltos. Un manifiesto asocia cada panel con la ruta y el estado que lo implementan, con query strings que fijan cosas como un reloj corriendo. `pnpm visual` saca foto del mock y de la ruta real al ancho del artboard, corre pixelmatch y guarda mock, implementación y diff. Con menos de 0,5% de diferencia, la pantalla cuenta como verificada. Una pantalla sin ruta aparece como pendiente, así la lista no se desfasa.
El costo. El diff de píxeles es estricto con cosas que nadie nota. Un breakpoint apenas por encima del ancho de un artboard movió cuatro pantallas entre 5% y 8%. Cuando el producto se aparta del mock a propósito, la pantalla queda marcada como decidida, con el motivo escrito, y se sigue midiendo.
Las reglas de plata escritas dos veces, atadas con vectores dorados
Por qué. El servicio es el 4% por entrada, con tope de $400. La pantalla lo calcula en un paquete de TypeScript puro. La API en Go calcula lo que se cobra de verdad. Un script genera vectores dorados desde las reglas de TypeScript, incluido el punto exacto donde el tope empieza a mandar, y los tests de Go leen el mismo archivo.
El costo. Dos implementaciones de la misma cuenta. Los vectores detectan un desacuerdo sólo en los casos que listan, así que cada regla nueva pide vectores nuevos.
Un QR que la puerta valida sin servidor
Por qué. Los lugares pierden señal justo cuando la fila es más larga. Cada entrada lleva una firma Ed25519 y rota cada 30 segundos, así la app de puerta la valida en el teléfono. Las entradas escaneadas quedan en IndexedDB y se comparten entre pestañas por BroadcastChannel. Los teléfonos con señal intercambian sus escaneos cada 20 segundos.
El costo. Dos puertas sin nada de señal pueden aceptar la misma entrada una vez cada una. Cerrar ese hueco pide Bluetooth entre teléfonos, que todavía no está hecho.



