Portal Expert: reemplazar una herramienta con una squad de tres

Reemplazar la herramienta sin el equipo estándar

El portal Expert debía reemplazar Impartner en una ventana corta. La decisión de salir de la herramienta ya se había preparado: el tema ya no era convencer a la organización de que un portal propio era necesario, sino entregarlo sin recrear una organización de proyecto pesada alrededor. La dimensión estratégica de esa decisión se cuenta en Reconstrucción del portal Expert: sustentar una decisión estratégica en pruebas. Aquí, el tema es la mecánica de entrega que hizo ejecutable esa decisión.

El producto entregado no tenía una única superficie. Había un front público, el directorio de agencias visible para comerciantes en experts.prestashop.com/fr/agences, y un back-office privado para agencias, accesible solo con una cuenta desde experts.prestashop.com/fr/connexion. Esta separación importa en el relato: lo público se puede enlazar directamente; el espacio agencia permanece mostrado como wireframes.

El equipo núcleo cabía en tres roles: una PM, un tech lead orientado backend, y yo del lado diseño. A esa escala, el modelo clásico de handoff se convertía en un riesgo. Si producto escribía, diseño producía maquetas, y desarrollo reconstruía pantallas interpretando las diferencias, la mecánica habría consumido demasiado tiempo y demasiada atención.

Había que reemplazar la herramienta, pero también la forma de producir.

La trampa del handoff

El handoff funciona cuando el equipo puede absorber la traducción entre oficios. Aquí, esa traducción habría sido el costo oculto del proyecto: rehacer pantallas, explicar estados, corregir espaciados, arbitrar casos vacíos, revisar multilingüe, reabrir temas después de la integración.

No era un problema de buena voluntad. Era un problema de mecánica. Cada relevo añadía una capa de interpretación cuando el equipo necesitaba reducir ambigüedades.

La decisión estructurante fue mover una parte del diseño dentro del producto mismo. Figma siguió siendo útil para aclarar intención, compartir dirección o dejar una traza. Pero el código se convirtió en la fuente de verdad de la interfaz.

Tres roles más nítidos

La PM no fue reemplazada por un prompt. Su rol se volvió más exigente: explicitar el problema, las reglas de negocio, las decisiones abiertas y los compromisos aceptables. El brief no era un ticket lanzado al otro lado del muro, sino un objeto vivo que la IA podía ayudar a cuestionar porque era suficientemente claro.

El tech lead no intervino solo al final para revisar. Su trabajo empezó antes de la generación: poner convenciones, estructurar instrucciones, aclarar las fronteras entre front, backend y API, hacer practicable el codebase. Uno de los aprendizajes más claros vino de un error inicial: demasiadas instrucciones globales, demasiada arquitectura inyectada en el mismo lugar, y la IA mezclaba responsabilidades. La corrección no fue pedir mejor. Fue encuadrar mejor.

Del lado diseño, el rol cambió de naturaleza. Las decisiones de interfaz, densidad, jerarquía y estados ya no se describían solo en una maqueta. Se trabajaban en el front, se corregían en el navegador, se commiteaban, y luego desarrollo las retomaba cuando la integración API lo exigía.

Esta redistribución no borró los oficios. Eliminó una parte de la traducción entre ellos. Producto no se volvió diseño, diseño no se volvió backend, el tech lead no se volvió garante de cada microdecisión visual. Cada rol conservó su soberanía, pero el relevo ocurría sobre artefactos más ejecutables.

Del ticket a producción, un camino marcado

El proyecto se sostuvo porque la trayectoria era repetible. Cada tema pasaba por el mismo camino: ticket Jira, rama dedicada, descomposición, código, review, commit y PR, merge, preproducción, producción.

La descomposición era una etapa de diseño en sí misma. Antes de la primera línea, había que nombrar la feature, los archivos objetivo, los estados esperados, los puntos de integración y las preguntas bloqueantes.

La review no era una lectura ligera. Cubría tests, arquitectura, CSS, i18n, TypeScript, uso del design system, playground y formato de commit. En cada etapa, una persona validaba el rumbo y una salvaguarda encuadraba el gesto.

El playground como lugar de verdad

El principal lever no fue una página de demo. Fue un espacio de trabajo: un playground de secciones, accesible en desarrollo, donde cada parte del portal podía verse en sus estados clave.

Una pantalla nunca se limita a su estado ideal. Tiene estado vacío, carga, error, dato parcial, permiso distinto, idioma más largo. El playground hacía navegables esas variaciones sin esperar todo el backend.

La frontera era importante: los mocks se quedaban en el marco de desarrollo, las llamadas API seguían siendo responsabilidad de la integración, y el design system servía de restricción por defecto. El objetivo no era improvisar más rápido. Era producir un front suficientemente justo para convertirse en base de trabajo, no en ilustración.

El método nacido en este proyecto se formalizó después como Playground-driven design. Este case study muestra el contexto que lo hizo emerger; la metodología explica cómo replicarlo sin copiar la implementación exacta.

El ciclo de diseño front

El ciclo front retomaba el mismo pipeline que desarrollo, pero cambiaba el sentido de codificar. Aquí, codificar era diseñar en el medio final.

Primero: intención enmarcada. El trabajo empezaba con un prompt que ponía la necesidad, el objetivo de la pantalla, las restricciones del design system y los estados a cubrir. Nada de página en blanco.

Segundo: propuesta IA. El agente producía una primera pantalla, nunca vacía, ya restringida por los componentes existentes. Esa primera salida era materia manipulable, no respuesta final.

Tercero: vibe design. La iteración ocurría sobre la pantalla real. Jerarquía, densidad, ritmo, claridad de los labels, equilibrio de los estados: las correcciones partían del render, no de una spec abstracta.

Cuarto: arbitraje y validación. Cuando la pantalla estaba justa, volvía al flujo común: review, commit, PR, merge, preproducción, producción. No era saltarse el diseño. Era desplazar la iteración de diseño a un medio más exigente.

Tres capas de salvaguardas

El sistema no descansaba en una vigilancia permanente. Descansaba en tres capas.

La primera era escrita: instrucciones jerarquizadas cargadas por contexto, con separación clara entre visión producto, convenciones técnicas y reglas de diseño.

La segunda era automatizada: convenciones, type-check, lint, tests, build, hooks y CI. La IA podía escribir rápido porque la base rechazaba mecánicamente una parte de las salidas frágiles.

La tercera era visual: playground local, tests focalizados, reviews especializadas, comparación directa con los estados esperados. Sin visibilidad rápida, la velocidad de generación solo habría acelerado el descubrimiento tardío de errores.

Una regla simple también resumía la escritura front: PUiK primero, custom solo cuando el design system no cubría la necesidad. Salir del sistema debía ser explícito, raro y justificable. Esa restricción hizo que el producto siguiera siendo mantenible después de la aceleración.

Lo que la IA realmente cambió

La IA aceleró la ejecución, pero no cargó con la responsabilidad del producto. Generó, reestructuró, propuso, corrigió, documentó. Los arbitrajes siguieron siendo humanos: qué debía verse, qué debía esperar, qué debía quedar en el design system, qué podía mockearse, qué debía pasar a backend.

La práctica fue medida. En la ventana de reconstrucción, el trabajo representó 206 horas de dirección IA activa, 235 commits y 21 458 acciones IA dirigidas. Esas cifras no prueban que la IA haga el trabajo. Prueban que una gran parte de la ejecución puede desplazarse si el marco es suficientemente explícito para seguir siendo controlable.

Las herramientas también cambiaron durante el camino. Claude Code sostuvo una parte del proyecto, Codex tomó un lugar creciente después. Ese desplazamiento es revelador: el método no dependía de una única herramienta. Dependía de la capacidad de escribir las reglas del juego, verificar el resultado y corregir sin perder la dirección.

Lo que entregó la squad

La V1 del portal propio se entregó para el cutover de junio de 2026. Cuando salí, la herramienta estaba en producción: el directorio público para comerciantes estaba disponible online, y el espacio privado para agencias pasaba por conexión. Lo importante no es solo que se haya reemplazado la herramienta anterior. Es que la nueva mecánica dejó una base más modificable: secciones visibles, estados identificados, decisiones de interfaz versionadas, separación más clara entre experiencia front e integración backend.

En un equipo tan reducido, esa claridad cuenta tanto como la velocidad. Producto podía concentrar la energía en las reglas y los arbitrajes. El tech lead podía asegurar los rieles y los puntos difíciles. Diseño podía avanzar sin esperar que cada dato estuviera disponible, sin salir del producto.

El ciclo diseño-dev no desapareció porque los oficios se hubieran fusionado. Se acortó porque cada rol asumió una responsabilidad más nítida.

Primeros signos después del lanzamiento

La herramienta anterior imponía una restricción mayor: una parte del valor quedaba invisible. El programa sabía que existía actividad, pero no podía leer correctamente vistas, contactos, calificación de solicitudes o dinámica real de las agencias.

El nuevo portal cambió esa situación desde la puesta en producción. En la ventana del 1 de junio al 31 de julio de 2026, los primeros signos se vuelven observables: 247 partners conectados, de los cuales 91 nuevos y 156 reactivados; 139 cuentas creadas en self-service; unos 36 comerciantes únicos que enviaron un brief, para 87 envíos brutos; 70 certificaciones compradas; 211 suscripciones activas; 417 tiendas verificadas.

Estas cifras no son una conclusión definitiva. Dicen sobre todo que el programa salió de la niebla. Lo que antes era imposible de objetivar ahora se puede seguir, comparar y mejorar.

Perfect Match es la consecuencia lógica de esa nueva base, no una prueba de producción que reclamar aquí. El directorio anterior podía mostrar perfiles. El nuevo portal puede estructurar un brief de comerciante, calificar la necesidad, explotar datos de agencia más limpios y preparar un matching más creíble. Lo que hay que valorar es la capacidad que el portal hace posible, no un estado de lanzamiento de Perfect Match.

Lo que el modelo no prueba

Este caso no dice que una squad de tres baste siempre para reemplazar una herramienta. Dice lo contrario: el modelo solo se sostiene si el perímetro V1 está acotado, si la capa backend puede aislarse, si el design system ya cubre gran parte de las necesidades, si las instrucciones de trabajo se tratan como infraestructura, y si alguien verifica de verdad lo que produce la IA.

Sin esas condiciones, la aceleración se convierte en deuda.

La lección duradera es esta: diseñar en código no es una postura anti-Figma ni una fascinación por la IA. Es una manera de eliminar una traducción cuando esa traducción cuesta más que lo que protege.