Del hallazgo al módulo: el software que tu equipo habría pedido

La operación de una pyme vive en Excels duplicados, en WhatsApp y en la cabeza de dos o tres personas clave. Las herramientas para ordenarla existen —Airtable, Glide, Retool— pero todas exigen que alguien sepa qué pedir y lo diseñe. Ese alguien no existe, o no tiene tiempo.

Cómo funciona

• El detector lee los hallazgos del mapa y propone un módulo cuando ve un dato repetido, un Excel compartido o un traspaso manual entre personas.
• El modelo no escribe código de pantallas: escribe una especificación —datos, vistas y, por cada campo, la entrevista que lo justifica— que un catálogo cerrado de seis componentes pinta.
• Nada se publica sin una persona: el admin revisa, renombra, quita o añade campos y aprueba.
• Cada campo enlaza a la frase que lo hizo nacer. «Por qué existe este módulo» es un botón, no una pregunta al consultor.

La regla de construcción es alquilar todo lo que no es foso: el render, los conectores y las automatizaciones ya existen. Se construye sólo el mapa, el detector de oportunidades, el paso de aprobación y la trazabilidad.

El examen de F1

Se prueba primero en CooWeb, con un proceso que hoy vive en un Excel o en una herramienta hecha a mano. Pasa si el módulo está en uso en menos de 48 horas desde el hallazgo, si se aprueban más de la mitad de las propuestas, si el admin rediseña menos del 20 % de los campos y, sobre todo, si dos personas lo usan dos semanas seguidas sin que nadie se lo pida.

«Si ningún módulo de CooWeb tiene dos personas usándolo dos semanas seguidas, se para el motor. Sin uso real, más funcionalidad no salva el producto.»

La mecánica que lo sostiene es la de siempre en UnifyFlow: la gente usa lo que ayudó a definir. La entrevista no es un trámite previo al software; es donde el software se diseña, con las palabras del equipo.