Cuándo una empresa necesita software propio y cuándo no

La decisión de construir software propio rara vez se toma como decisión. Aparece por acumulación: un requerimiento que la plataforma no cubre, una hoja de cálculo que se vuelve crítica, una integración que nadie quiere volver a tocar, y un día el proyecto ya empezó.

Construir es una opción legítima y a veces la única razonable. Pero es también la opción con mayor costo de continuidad: lo que se construye hay que operarlo, documentarlo, actualizarlo y sostenerlo cuando cambie quien lo escribió.

Antes de discutir arquitectura o lenguaje, conviene responder tres preguntas sobre el problema, no sobre la solución.

Construir suele justificarse cuando coinciden varias condiciones: el flujo es propio y estable en su lógica de negocio, ninguna plataforma lo cubre sin obligar a rediseñar la operación alrededor del producto, la integración con los sistemas existentes es parte del valor y no un accesorio, y la organización puede sostener el software una vez entregado.

Esa última condición es la que más se subestima. Un sistema propio sin responsable de producto, sin criterio de versión y sin documentación operativa se convierte en deuda antes de cumplir dos años.

No conviene construir cuando el requerimiento es una diferencia de configuración; cuando la insatisfacción con la plataforma actual proviene de una implementación incompleta y no del producto; cuando lo que falta es un dato que nunca se capturó; o cuando el problema es de proceso y el software sólo cambiaría el lugar donde ocurre.

Entre comprar y construir existe un espacio que resuelve una parte importante de los casos: extender lo que ya opera. Una capa de integración, un servicio que expone datos que hoy están encerrados, una interfaz específica sobre un sistema que funciona bien pero no se puede usar en campo.

Estas intervenciones son más pequeñas, se entregan antes y conservan el soporte del proveedor original. También son más fáciles de revertir, que es una propiedad subestimada cuando la operación todavía está cambiando.

La forma más barata de evitar un sistema equivocado es escribir la decisión antes que el código: qué problema resuelve, qué flujo cubre, qué integra, qué se conserva humano, quién lo opera después y con qué criterio se decidirá que funcionó.

Cuando ese documento existe, la discusión técnica se vuelve corta. Cuando no existe, el proyecto la sustituye con reuniones.