Una guía para anticipar los costos de mantener un sistema funcionando después del lanzamiento, más allá del desarrollo inicial.
Cuando una empresa decide invertir en un sistema de software, la conversación suele girar alrededor del costo de desarrollo. Se habla de funcionalidades, de plazos, de diseño. Pero hay una pregunta que muchas veces queda afuera de esa primera conversación y que, con el tiempo, se vuelve inevitable: ¿cuánto va a costar mantener esto funcionando?
El desarrollo inicial es un momento en el tiempo. La operación, en cambio, es permanente. Servidores que hay que pagar todos los meses, actualizaciones de seguridad que no pueden esperar, backups que alguien tiene que verificar, usuarios que necesitan ayuda cuando algo no funciona como esperaban. Nada de eso aparece en la cotización del proyecto, pero todo empieza a facturarse desde el día uno después del lanzamiento.
Para ordenar la conversación, conviene separar los costos operativos en tres categorías. No son compartimentos estancos —se superponen y se afectan entre sí—, pero sirven para no olvidar ninguna pieza.
Infraestructura es todo lo que hace que el sistema esté disponible: servidores, bases de datos, almacenamiento de archivos, ancho de banda, certificados de seguridad. En la mayoría de los casos, estos costos son mensuales y variables: crecen a medida que crece el uso del sistema. Un error frecuente es proyectar el costo de infraestructura con los números del primer mes y asumir que van a mantenerse iguales durante dos años.
Mantenimiento cubre las tareas técnicas que mantienen el sistema saludable: actualizaciones de librerías y frameworks, corrección de bugs que aparecen con el uso real, mejoras de rendimiento cuando algo se vuelve lento, parches de seguridad. Es un trabajo que no se ve desde afuera pero que, si se posterga, acumula deuda técnica y eventualmente obliga a reconstruir partes enteras del sistema.
Soporte es la capa de atención a usuarios: resolver dudas, investigar comportamientos inesperados, ayudar con configuraciones, recibir y clasificar reportes de error. En sistemas internos de una empresa, el soporte suele recaer en alguien del equipo que absorbe esa carga sin que esté contemplada en su rol. En productos que se venden a clientes externos, el soporte afecta directamente la percepción de calidad.
Muchas empresas presupuestan el desarrollo como si fuera el costo total y después descubren —generalmente en el primer trimestre de operación— que mantener el sistema cuesta entre un 15% y un 25% adicional del costo de desarrollo por año. Si eso no está contemplado, el proyecto queda descapitalizado apenas arranca.
No hace falta ser ingeniero para estimar estas partidas. Algunas reglas prácticas ayudan a poner números sobre la mesa sin depender de una cotización detallada.
Para infraestructura, el punto de partida es responder tres preguntas: ¿cuántos usuarios va a tener el sistema en los primeros seis meses?, ¿qué volumen de datos va a manejar?, ¿necesita estar disponible 24/7 o puede tolerar ventanas de mantenimiento? Las respuestas definen el tipo de servidor, la estrategia de backups y la necesidad de redundancia. Un sistema interno para quince personas no cuesta lo mismo que una plataforma pública con cientos de accesos simultáneos.
Para mantenimiento, la variable clave es la complejidad del sistema. A más integraciones con servicios externos, más puntos de falla y más dependencia de actualizaciones de terceros. Un sistema que conecta cinco APIs distintas requiere más mantenimiento que uno autónomo. También importa la madurez de las tecnologías elegidas: un framework con una comunidad grande y activa reduce el riesgo de quedarse sin soporte, pero no lo elimina.
Pedile a tu proveedor tecnológico que separe explícitamente en la cotización qué incluye el desarrollo y qué incluye la operación posterior. Si la propuesta no distingue entre ambas fases, preguntá por qué. La respuesta te va a decir más que cualquier número.
Para soporte, la estimación depende de quiénes son los usuarios y qué nivel de autonomía tienen. Usuarios internos entrenados generan menos consultas que clientes externos que usan el sistema por primera vez. También importa la madurez del sistema: los primeros meses después del lanzamiento concentran la mayor cantidad de incidencias, tanto por bugs como por curva de aprendizaje.
El verdadero problema no es que existan estos costos —existen en cualquier sistema, no importa quién lo haya construido— sino que no estén contemplados desde el principio. Cuando el presupuesto inicial solo cubre el desarrollo, la operación se financia con lo que va quedando, y eso genera una dinámica peligrosa: se postergan actualizaciones, se recorta soporte, se estira la infraestructura más allá de lo razonable.
La alternativa es simple: incluir la operación en la conversación desde la primera reunión. Preguntar cuánto va a costar mantener el sistema en el primer año, qué servicios requieren pago mensual, cuántas horas de soporte están incluidas y cuántas se facturan aparte. Son preguntas que cualquier proveedor serio puede responder sin necesidad de un análisis extenso.
Si ya tenés un sistema funcionando y estás sintiendo que los costos operativos se desbordaron, el camino no es recortar a ciegas sino entender qué está consumiendo más recursos. A veces el problema es una infraestructura sobredimensionada que se contrató por las dudas. Otras veces es un sistema que requiere demasiado mantenimiento porque se construyó sin pensar en la operación a largo plazo. En cualquiera de los dos casos, entender qué gastos tecnológicos son inevitables y cuáles son evitables es el primer paso para recuperar el control.
También conviene revisar qué costos aparecen específicamente después del lanzamiento, porque algunos solo se vuelven visibles cuando el sistema ya está en producción y es demasiado tarde para negociarlos. La diferencia entre un proyecto que escala de forma sostenible y uno que se frena por falta de presupuesto casi nunca está en el desarrollo inicial: está en cómo se planificó la operación desde el día cero.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →