En esta nota (9 secciones)
El presupuesto de un desarrollo se discute durante semanas. El costo de tenerlo funcionando después casi nunca se discute, y es el que se paga todos los años durante toda la vida del sistema.
Como referencia de industria, el mantenimiento anual de un software a medida se ubica entre el 15% y el 20% del costo del desarrollo. Sobre un sistema de USD 15.000, eso son entre USD 2.250 y 3.000 por año. El número sirve para presupuestar, pero no explica nada: no dice qué se está pagando ni por qué varía tanto. Esto es el desglose.
Los cuatro costos, separados
Meterlos en una sola bolsa llamada "mantenimiento" es lo que hace que la discusión sea confusa. Son cuatro cosas distintas, con lógicas distintas.
1. Infraestructura
El sistema corre en algún lado y ese lado se factura por mes. Servidor, base de datos, almacenamiento de archivos, dominio, certificados, servicio de envío de mails.
Para un sistema chico o mediano, entre USD 20 y 200 mensuales según volumen. Es el costo más predecible de los cuatro y el que menos sorpresas da.
Lo que sí sorprende: escala con el uso, no con las funcionalidades. Un sistema que no cambió en dos años puede duplicar su factura de infraestructura porque la empresa creció.
2. Correctivo
Los errores. Los que aparecen en producción, con datos reales, en situaciones que nadie probó.
La curva es bastante estable: el grueso aparece en los primeros dos o tres meses y después baja fuerte. Por eso casi todo contrato serio incluye una garantía de 3 a 6 meses sobre lo entregado, donde esto no se cobra aparte.
Conviene tener claro qué entra en garantía y qué no, porque acá está la discusión típica. Un botón que no guarda es un error: entra. Un reporte que ordena por fecha y vos lo querías por cliente, si el pedido decía fecha, es un cambio: no entra.
3. Actualizaciones y seguridad
Este es el que más se subestima, porque el sistema funciona igual de bien tenga o no tenga el mantenimiento hecho. No hay ningún síntoma visible hasta que hay un problema grave.
Un desarrollo se apoya en decenas de librerías de terceros que publican parches de seguridad, versiones nuevas y, cada tanto, cambios que rompen compatibilidad. Si nadie las toca durante tres años, actualizar deja de ser rutina y pasa a ser un proyecto.
Un sistema sin mantener no se degrada: acumula. Y la cuenta se paga entera el día que hay que tocarlo.
Lo mismo con las integraciones: si tu sistema habla con un banco, con ARCA o con una plataforma de pagos, esas APIs cambian por decisión de ellos y en su calendario, no en el tuyo. Un cambio de versión con fecha límite no es negociable.
Presupuestalo aunque no pase nada. Es exactamente el tipo de gasto que se recorta el primer año y se paga al triple el cuarto.
4. Evolutivo
Lo que le agregás porque la empresa cambió: un reporte nuevo, un campo más, un circuito que ahora tiene un paso adicional, una integración que antes no existía.
Es el único de los cuatro que es opcional y proporcional a lo que quieras hacer. También es, en la mayoría de los sistemas vivos, el más grande de los cuatro. No es mantenimiento en sentido estricto: es desarrollo nuevo sobre una base que ya existe.
Para esto la forma sana de contratar suele ser una bolsa de horas mensual, porque el alcance genuinamente no se puede definir por adelantado.
Qué mueve el número hacia arriba
Dos sistemas del mismo precio pueden tener costos de mantenimiento muy distintos. Lo que hace la diferencia:
- Cantidad de integraciones. Cada sistema externo con el que hablás es una dependencia que puede cambiar sin avisarte. Es el factor que más pesa.
- Usuarios concurrentes y volumen de datos. Mueve infraestructura y, pasado cierto punto, obliga a trabajo de optimización.
- Cuánta lógica de negocio tiene. Un sistema con reglas de precios, comisiones y aprobaciones tiene más superficie donde algo puede salir mal que un ABM.
- Qué tan viejo es el stack elegido. Un desarrollo hecho sobre tecnología que ya estaba de salida cuando se construyó arranca con deuda desde el día uno.
- Si hay tests automatizados. Sin tests, cada cambio chico requiere probar a mano media aplicación. Se paga en cada modificación, para siempre.
Ese último punto es el que más conviene mirar antes de firmar un desarrollo, no después.
Las tres formas de contratarlo
Bolsa de horas. Comprás un paquete mensual y se consume contra lo que pidas. Es lo más común y lo más flexible. Preguntá siempre si las horas no usadas se acumulan o se pierden.
Abono fijo. Un monto mensual que cubre infraestructura, correctivo y actualizaciones, con el evolutivo aparte. Da previsibilidad y sirve cuando el sistema es crítico para la operación.
Por incidente. No pagás nada hasta que algo pasa. Es lo más barato en el papel y lo más caro cuando importa: sin relación activa, quien te atiende tiene que volver a entender un sistema que no toca hace un año, y eso se factura.
Para un sistema que sostiene la operación diaria, el "por incidente" es una economía falsa. Para una herramienta interna secundaria, puede ser perfectamente razonable.
Las preguntas que conviene hacer antes de firmar el desarrollo
No después. El costo de mantener se define en decisiones que se toman durante la construcción.
- ¿Cuánto dura la garantía y qué entra exactamente?
- ¿El código queda a mi nombre, en un repositorio al que tengo acceso?
- ¿Qué pasa si el mantenimiento lo quiere hacer otro? ¿Hay documentación para que alguien más lo tome?
- ¿Hay tests automatizados? ¿Qué cobertura?
- ¿La infraestructura está a mi nombre o al del proveedor?
- ¿Qué versiones de las dependencias principales usa, y hasta cuándo tienen soporte?
La tercera y la quinta son las que más incomodan y las más importantes. Un sistema que sólo puede mantener quien lo hizo, corriendo en una cuenta que no controlás, no es un activo tuyo. Es una suscripción con un solo proveedor posible, y el precio lo pone él.
El número, otra vez
Volviendo al 15-20% anual: sirve como orden de magnitud para el presupuesto, pero armalo por partes. Infraestructura la podés cotizar exacto. Correctivo debería estar en garantía el primer semestre. Actualizaciones es un piso fijo que hay que sostener. Evolutivo es una decisión de negocio, no un costo técnico.
Un sistema que no evoluciona no es un sistema barato. Casi siempre es uno que dejó de acompañar a la empresa, y ese es el paso previo a reemplazarlo entero.