Lo que construimos para usar nosotros primero.

Automatizar los procesos de otros es un trabajo hecho de decisiones. En casi todos los proyectos llega el momento en que un paso del flujo depende de una herramienta ya existente, y decidir cuál usar nos toca a nosotros. Durante mucho tiempo tomamos esa decisión desde afuera: leyendo documentación, probando durante una semana, confiando en la página de precios. El resto lo descubría el cliente: el límite que solo aparece con el volumen del cierre de mes, el soporte que tarda tres días en responder, el reajuste que llega en el aniversario del contrato.

Construir las nuestras fue la forma de traer parte de esa decisión hacia adentro. Ninguna de las herramientas de arriba nació de una reunión de portafolio: todas salieron de un cuello de botella que dolió primero en nuestra operación o en la de un cliente, y que no pudimos resolver comprando. Cuando el mismo problema aparece por tercera vez en tres empresas distintas, ya dejó de ser una excepción y pasa a justificar el costo de construir.

El criterio para empezar es conservador a propósito, y vale la pena decirlo: solo se convierte en producto lo que usamos en nuestro propio día a día. Es un filtro incómodo, porque descarta buenas ideas que nadie aquí adentro usaría. Pero es el único que evita que una empresa que trabaja por proyectos se convierta en una fábrica de software que nadie opera.

La parte más útil es la más aburrida de explicar: pasamos a tener una opinión formada sobre el costo de mantenimiento. Cuando una automatización se puede resolver de tres maneras, la elección rara vez es técnica. Tiene que ver con quién la va a mantener dentro de dieciocho meses, con qué frecuencia el proveedor cambia las reglas del juego y qué pasa el día en que la persona que entendía del tema deja la empresa. Quien entrega y se va no necesita responder eso.

También cambió lo que aceptamos construir desde cero. Haber escrito software propio deja claro el tamaño del compromiso que hay detrás de cada herramienta nueva: documentación, actualizaciones, migraciones, el día en que se rompe. Por eso buena parte de las recomendaciones que salen de un proyecto nuestro es no construir: usar lo que ya existe, o simplemente dejar de hacer el paso que nadie sabe explicar por qué existe.

Y hay un efecto directo: a veces la pieza que faltaba en el flujo ya estaba construida. Cuando eso pasa, decimos de dónde viene y cuánto cuesta, y la decisión queda en manos del cliente. Lo que no pasa es que un producto nuestro entre en el alcance por conveniencia: el criterio es el mismo que aplicamos a las herramientas de terceros.