El costo que nadie pone en la hoja: quién mantiene tu sistema

"Ingeniero, el que nos hizo el sistema ya no trabaja aquí." Es la frase que más escucho cuando un director nos llama por un sistema propio. El sistema funciona, más o menos. Nadie sabe por qué falla los lunes, nadie se atreve a moverle y nadie sabe bien dónde están las contraseñas del servidor.

En 2026 se volvió fácil construir. Con IA, una persona que sabe arma en semanas lo que antes tomaba meses. Lo que no cambió es lo que viene después: alguien tiene que mantenerlo. Ese costo casi nunca aparece en la hoja donde se compara contra la suscripción del SaaS, y es el que decide si construir fue buena idea.

Resumen ejecutivo

• Construir un sistema es la parte visible; mantenerlo funcionando, seguro y entendible es el trabajo que dura años.
• El riesgo mayor no es técnico: es que la única persona que lo entiende se vaya.
• Lo que reduce ese riesgo es aburrido: documentación, reglas de negocio ubicadas en el código, pruebas automatizadas y medición.
• Las fallas más caras de un sistema propio son silenciosas: el sistema dice que todo va bien y no es cierto.
• Si no tienes quién lo mantenga, adentro o afuera, no construyas: compra o conecta.

¿Cuánto cuesta mantener un sistema propio?

Más que construirlo, si se mide a tres años. Hay que pagar horas de quien lo atiende, hospedaje, respaldos, actualizaciones de seguridad, cambios en las APIs de los sistemas con los que se conecta y pruebas antes de cada cambio. Con un SaaS esas partidas vienen dentro de la suscripción; con lo construido las pagas tú.

Partida	Con un SaaS	Con un sistema propio
Corrección de errores	El proveedor	Tu equipo o tu proveedor de soporte
Parches de seguridad y dependencias	El proveedor	Tú, cada mes
Cambios en la API del ERP o del banco	El proveedor ajusta su integración	Tú, cuando el otro sistema cambia
Respaldos y recuperación	Incluidos, con sus límites	Los diseñas, los pruebas y los vigilas
Guardia cuando falla de noche	Mesa de soporte del proveedor	Alguien con acceso y conocimiento
Documentación	Del producto, genérica	La que tú escribas; si no existe, nada
Que la persona que sabe se vaya	No te afecta	El riesgo más grande de todos

No te puedo dar una cifra general sin conocer tu sistema, y desconfía de quien te la dé. Lo que sí te digo: si en la comparación solo aparece el costo de construir contra un año de suscripción, la comparación está incompleta.

¿Por qué las fallas de un sistema propio son tan peligrosas?

Porque casi nunca truenan; se callan. El sistema sigue respondiendo y los números se ven razonables, pero están mal. Sin pruebas y sin alguien que mida, nadie se entera hasta que un cliente reclama o una decisión ya se tomó con un dato falso.

Te cuento tres que nos pasaron en nuestra propia plataforma en 2026, todas ya corregidas:

• Cero rebotes que no eran cero. En agosto, nuestro motor de correo registró cero rebotes en 406 envíos. No era buena entregabilidad: el sistema no estaba recibiendo la señal. Lo corregimos el 26 de agosto.
• Un chat que no guardaba contactos. El chat del sitio esperaba una marca que el modelo de IA nunca emitió. Resultado: 0 de 674 mensajes dejaron el contacto en el CRM. Lo encontramos revisando números, no confiando en que funcionaba, y quedó corregido el 16 de septiembre.
• Un pedido "entregado" que nunca salió. Una consulta de logística decía "entregado" de un pedido que no se había embarcado. Eran tres defectos encadenados; los corregimos el 7 de septiembre y reprocesamos 18 pedidos con respaldo previo.

Ninguna de las tres la habría detectado un usuario. Las detectó alguien cuyo trabajo es mirar los números del sistema. Ese alguien es el costo que no está en la hoja.

¿Qué hace que un sistema sobreviva a su autor?

Cuatro cosas: documentación que explica por qué existe cada regla, reglas de negocio ubicadas en el código y no en la memoria de alguien, pruebas automatizadas que corren antes de cada cambio, y un procedimiento para desplegar y regresar que cualquiera del equipo pueda seguir.

Es lo que llamamos un Sistema Vivo: un sistema que evoluciona con la empresa porque está documentado, probado y se puede consultar desde Claude, ChatGPT o WhatsApp con los permisos de cada persona. Lo vivo no es la tecnología. Es que alguien que no lo construyó puede entenderlo y cambiarlo sin miedo.

Te digo cómo lo hacemos con el nuestro. El paquete de documentación que levantamos el 8 de septiembre de 2026 tiene 39 diagramas, 95 reglas de negocio con la ruta del archivo donde vive cada una, una matriz de 238 casos de prueba y 16 videotutoriales narrados. La suite automatizada supera las 900 pruebas. Desplegar es un comando y regresar es otro, con respaldo diario en tres destinos.

Nada de esto es original. El marco de desarrollo seguro del NIST (SP 800-218, febrero de 2022) pide prácticas parecidas para reducir vulnerabilidades. Y la investigación de DORA mide la salud de un equipo de software con métricas como el tiempo para recuperarse de un despliegue fallido y la proporción de cambios que requieren intervención inmediata. Si nadie en tu empresa puede contestarte esas dos cifras, el sistema depende de la suerte.

¿Y la IA no resuelve el mantenimiento?

Ayuda, pero no lo resuelve. La IA escribe código rápido, encuentra errores y redacta documentación. No decide qué regla de negocio es la correcta ni se da cuenta sola de que un número está mal. Para eso hace falta alguien que conozca la operación y que tenga pruebas contra las cuales comparar.

Un ejemplo nuestro: una consulta de ventas agrupaba por un campo que parecía el correcto y estaba poblado en 145 de 862 pedidos; el correcto lo estaba en 854. La cifra de una vendedora cambiaba 3.7 veces. El código no tenía ningún error de sintaxis. El error era de negocio, y lo encontró una persona mirando los datos.

Mi postura: la IA baja el costo de escribir software y sube el riesgo de tener software que nadie entiende. Las dos cosas son ciertas a la vez.

¿Cuándo no conviene construir?

Cuando no tienes quién lo mantenga, ni adentro ni con un proveedor que se comprometa por escrito. También cuando lo que necesitas es regulado, como el timbrado o la nómina, cuando lo usas poco o cuando un producto ya lo hace bien y tu forma de trabajar no tiene nada distinto.

1. No hay una persona responsable con nombre y horas asignadas.
2. No hay presupuesto para mantenerlo después del primer año.
3. El proceso es igual al de cualquier empresa de tu giro.
4. El proceso cambia por regulación, no por decisión tuya.
5. Nadie va a escribir pruebas ni documentación "porque no hay tiempo".

Si te identificas con dos o más, compra o conecta. Construir en esas condiciones es heredarle un problema a quien venga después. El marco para decidir qué herramientas sí reemplazar está en comprar, construir o conectar.

Si ya tienes un sistema propio y el que lo hizo ya no está, agenda un diagnóstico de tu sistema: lo levantamos, documentamos sus reglas y te decimos qué tan frágil está antes de moverle. Para saber qué incluye un buen esquema de soporte, lee la guía de soporte técnico para empresas; para entender cómo se construye un sistema que no dependa de una sola persona, cómo implementamos un Sistema Vivo en dos semanas y la guía de software a la medida.

Ing. Armando Cortés