Los costos recurrentes que no aparecen en la cotización inicial de un desarrollo: hosting, dominios, SSL, backups, monitoreo, actualizaciones, soporte y corrección de bugs.
Cuando una empresa recibe una cotización por un desarrollo de software, el foco suele estar en el número que aparece al final. ¿Cuánto cuesta construir? ¿En cuánto tiempo está listo? Esas son las preguntas que dominan la conversación inicial. Pero hay una pregunta que se hace mucho menos y que, con el tiempo, pesa tanto o más que la inversión inicial: ¿cuánto cuesta mantener esto funcionando?
Mantener una aplicación no es un gasto que aparece una vez y desaparece. Es un conjunto de costos recurrentes que empiezan el día que la aplicación se pone en producción y no terminan mientras la aplicación siga en uso. Algunos son fijos y predecibles. Otros son variables y dependen del uso, del crecimiento o de factores externos. Casi todos son inevitables. Y muchos no figuran en la cotización inicial porque no forman parte del desarrollo propiamente dicho.
Este artículo enumera y explica cada uno de los costos ocultos de mantener una aplicación. El objetivo no es desalentar la inversión en tecnología, sino evitar la sorpresa de descubrir que el presupuesto anual de operación supera ampliamente lo que se previó durante la etapa de desarrollo.
Toda aplicación necesita vivir en algún lado. Ese "algún lado" es un servidor —físico o, cada vez más frecuentemente, en la nube— que tiene un costo mensual o anual.
El costo de hosting depende de varias variables:
En proyectos chicos, el hosting puede costar desde unas pocas decenas de dólares por mes. Pero a medida que la aplicación crece en usuarios, en datos o en complejidad, ese costo escala. Y lo hace de manera no lineal: duplicar la cantidad de usuarios no necesariamente duplica el costo de infraestructura, pero casi seguro lo aumenta en una proporción que conviene haber anticipado.
Un error frecuente es dimensionar la infraestructura para el escenario actual y no para el crecimiento previsto en los próximos doce o veinticuatro meses. Migrar una aplicación a una infraestructura más grande cuando el costo actual ya se volvió insostenible es más caro y más riesgoso que planificar ese crecimiento desde el inicio.
Parecen costos menores comparados con el desarrollo y el hosting, pero son recurrentes y obligatorios:
Ninguno de estos rubros es caro por sí solo. Pero sumados y multiplicados por la cantidad de entornos, dominios y aplicaciones que una empresa puede llegar a tener, el costo anual deja de ser insignificante.
Los datos que una aplicación genera —transacciones, registros de clientes, documentos, configuraciones— son, en muchos casos, más valiosos que la aplicación misma. Perderlos no es un contratiempo técnico: es un problema de negocio que puede implicar desde la imposibilidad de operar hasta consecuencias legales.
Proteger esos datos tiene un costo:
El costo de un esquema de backups robusto es un gasto recurrente predecible. El costo de no tenerlo no se puede predecir, pero en el peor caso puede ser la pérdida total de los datos del negocio. La ecuación, en casi todos los escenarios, favorece al backup.
Una aplicación en producción necesita ser vigilada. No por desconfianza, sino porque los problemas que no se detectan a tiempo son los que más daño generan.
El monitoreo incluye:
Las herramientas de monitoreo tienen un costo —algunas cobran por volumen de datos procesados, otras por cantidad de servidores monitoreados, otras por funcionalidad— y también lo tiene el tiempo del equipo que configura las alertas, investiga las que se disparan y mantiene el sistema de monitoreo actualizado a medida que la aplicación evoluciona.
El monitoreo no es opcional si la aplicación es importante para el negocio. Lo que es opcional es el nivel de sofisticación: se puede empezar con herramientas básicas —gratuitas o de bajo costo— e ir agregando capacidad a medida que la aplicación crece.
El software no se construye desde cero. Se construye sobre bibliotecas, frameworks y servicios de terceros que, a su vez, se actualizan constantemente. Cada una de esas dependencias es un punto de entrada potencial para vulnerabilidades de seguridad, y cada actualización es una decisión que alguien debe tomar.
Mantener las dependencias actualizadas implica:
Este trabajo no es visible para el usuario final —la aplicación hace lo mismo que hacía antes—, pero es indispensable para que siga siendo segura y compatible con los entornos donde opera. Postergarlo indefinidamente no ahorra plata: la acumula como deuda técnica que, cuando se vuelve inevitable pagar, cuesta más que si se hubiera mantenido al día.
Una vez que la aplicación está en producción, los usuarios van a tener preguntas, dudas y problemas. Alguien tiene que atenderlos.
El soporte puede ser interno —un equipo de la empresa dedicado a atender consultas— o externo —el proveedor que desarrolló la aplicación ofrece un servicio de soporte post-entrega—. En cualquier caso, tiene un costo:
El error más común es asumir que el soporte post-entrega está incluido en el costo de desarrollo. Rara vez lo está, y cuando lo está, suele estar acotado en tiempo —treinta, sesenta o noventa días— y en alcance —solo corrección de errores, no mejoras ni consultas de uso—. Pasado ese período, el soporte se paga aparte.
Ningún software sale sin errores. Incluso después de pruebas exhaustivas, aparecen bugs que solo se manifiestan en condiciones específicas de producción: cierta combinación de datos, cierto volumen de usuarios simultáneos, cierta secuencia de acciones que nadie probó porque parecía improbable.
Corregir esos bugs tiene un costo que se paga de dos maneras:
La primera opción es predecible —un costo fijo todos los meses— pero puede resultar cara si la aplicación es estable y genera pocos errores. La segunda es impredecible y puede dispararse si la aplicación tiene más bugs de los esperados.
Conviene definir este punto antes de que aparezca el primer error post-entrega. Una conversación incómoda durante la negociación del contrato es mejor que una discusión sobre si algo es un error o una mejora cuando la aplicación ya está en producción y el negocio depende de que funcione.
Muchas aplicaciones dependen de servicios externos que tienen un costo recurrente:
Cada uno de estos servicios se cobra por separado —mensual, anual o por uso— y cada uno tiene sus propias condiciones de renovación, sus propios aumentos de precio y sus propios cambios de funcionalidad que pueden afectar a la aplicación.
Una aplicación que depende de diez servicios externos tiene once facturas que pagar todos los meses: la del hosting y las diez de los servicios. Si alguna de esas facturas deja de pagarse —porque venció la tarjeta, porque el proveedor cambió las condiciones, porque alguien del equipo que gestionaba eso ya no está—, algo de la aplicación deja de funcionar. Y dependiendo de qué servicio falle, el impacto puede ir desde una funcionalidad menor inaccesible hasta la imposibilidad de cobrar o de comunicarse con los clientes.
Mantener una aplicación no es barato, pero no mantenerla es más caro. Las consecuencias de postergar el mantenimiento se acumulan:
El mantenimiento no es un lujo ni un seguro contra catástrofes: es la condición necesaria para que la inversión inicial en desarrollo no se deprecie antes de tiempo. Una aplicación que se construyó y se abandonó a su suerte deja de ser un activo y se convierte en un pasivo.
Antes de firmar un contrato de desarrollo, conviene pedirle al proveedor —o armar con el equipo interno— un detalle de los costos operativos estimados para el primer año de funcionamiento. Ese detalle debería incluir:
Si el proveedor no puede estimar estos rubros, al menos sabés que hay un riesgo no cuantificado. Si puede estimarlos, tenés un punto de partida para armar el presupuesto operativo del primer año y para decidir si el costo total —desarrollo más operación— es viable para el negocio.
Desarrollar una aplicación es una inversión. Mantenerla es un compromiso. Los dos tienen costos. El error no es asumirlos: es no haberlos contemplado.
Si querés entender mejor por qué dos cotizaciones por el mismo proyecto pueden diferir tanto —y cuánto de esa diferencia se explica por lo que incluyen o excluyen del mantenimiento posterior—, revisá por qué dos presupuestos de software llegan a precios tan diferentes. Y si el proyecto es a medida y querés compararlo con una solución estándar, el artículo sobre software a medida versus software estándar analiza las diferencias de costo total, incluyendo el mantenimiento.
Más contenido sobre planificación financiera de proyectos en la categoría de costos y presupuestos.
¿Quieres evaluar cómo aplicar esto a tu proyecto?
Cuéntanos tu caso →