5 de septiembre de 2026
Diseñar software alrededor de las operaciones
El software debe empezar por cómo funciona realmente el negocio—no por una pantalla en blanco y una lista de features.
Rara vez empiezo preguntando: “¿Qué app deberíamos construir?”
Empiezo preguntando cómo funciona el negocio hoy.
¿Dónde se rompe?
¿Qué es repetitivo?
¿Qué confunde?
¿Qué debería facilitar la tecnología?
Esas preguntas suenan simples. No lo son.
Operaciones primero
La mayoría del software roto no está roto porque el código sea malo.
Está roto porque el producto se diseñó alrededor de un flujo imaginado en vez del real.
En negocios reales, el trabajo suele moverse así:
- un lead llega por Instagram, WhatsApp o un formulario
- alguien responde a mano
- los detalles viven en el chat
- un estimado se escribe en otro lado
- el pago ocurre en otro sistema
- el seguimiento depende de la memoria
Si el software ignora ese camino, la gente inventa workarounds. Luego el workaround se vuelve el proceso.
Que el sistema encaje con el trabajo
El buen software operativo se siente obvio para quien hace el trabajo.
Eso normalmente significa:
- menos pantallas entre la intención y la acción
- estado claro de lo que está esperando
- documentos pegados a la cosa a la que pertenecen
- roles que coinciden con cómo el equipo divide la responsabilidad de verdad
La complejidad puede existir por debajo. La superficie debe permanecer calmada.
Del dolor repetido al producto
Cuando ves el mismo dolor operativo a través de negocios, dejas de resolverlo con un parche custom cada vez.
Empiezas a diseñar un producto.
Ese es el camino del trabajo de implementación al SaaS: notar el patrón, aislar el flujo, construir algo reutilizable y mantenerlo cerca de la realidad.
Así pienso en Nexo Operativo, y así quiero seguir construyendo.