El coste real de mantener software a medida
Semana editorial: 2026-09-28 · Publicado:
Qué determina el coste de mantenimiento de software a medida: soporte, seguridad, infraestructura y evolución, con criterios para definir un alcance claro.
Construir software a medida suele empezar con una pregunta legítima: cuánto cuesta crear la primera versión. Pero cuando la aplicación gestiona ventas, operaciones, documentación, clientes o datos críticos, la pregunta que protege la inversión llega después: ¿cuánto costará mantenerla útil y segura durante los próximos años?
El lanzamiento no cierra el proyecto. Lo convierte en un sistema vivo: aparecen incidencias reales, cambian los navegadores y los sistemas operativos, vencen dependencias, evolucionan las integraciones y el negocio aprende qué necesita de verdad. El mantenimiento no es un extra que se añade cuando algo falla; es la capacidad de seguir operando y cambiando sin poner el negocio en riesgo.
Esta guía ayuda a separar las partidas que conviene prever, los factores que hacen variar el esfuerzo y las preguntas que permiten comparar propuestas sin confundir soporte urgente con desarrollo de nuevas funcionalidades.
El software no termina cuando se publica
Una aplicación recién lanzada puede funcionar correctamente y, aun así, necesitar atención continua. Un formulario puede depender de un proveedor externo que modifica su API. Una actualización de seguridad puede afectar a una librería que nadie tocaba desde hace meses. El equipo puede descubrir que un paso manual bloquea el proceso justo cuando aumenta el volumen de trabajo.
No se trata de suponer que todo fallará. Se trata de diseñar una forma previsible de detectar, priorizar y resolver cambios.
El coste de mantener software a medida depende menos del número de pantallas que del papel que tiene en la empresa. Una herramienta interna sencilla, con pocos usuarios y sin datos sensibles, no exige el mismo servicio que un portal que atiende a clientes, conecta ERP y CRM o sostiene una operación de campo.
Antes de pedir un presupuesto, conviene plantear cuatro preguntas:
- ¿Qué ocurre si la aplicación deja de funcionar una hora, un día o una semana?
- ¿Qué sistemas, proveedores o datos externos necesita para operar?
- ¿Quién detecta un problema y quién puede decidir cómo se resuelve?
- ¿Qué cambios de negocio deberán estar listos en los próximos seis a doce meses?
Las respuestas convierten “mantenimiento” en un alcance que se puede gobernar.
Qué incluye el mantenimiento de software a medida
Un plan útil no es una frase genérica sobre “soporte incluido”. Debe dejar claro qué trabajo recurrente cubre, qué se activa ante una incidencia y qué se considera evolución. Estas son las áreas que normalmente requieren presupuesto y responsabilidad explícita.
Soporte correctivo: resolver incidencias sin improvisar
El soporte correctivo cubre fallos que impiden o degradan un uso esperado: un error al guardar un pedido, una pantalla que no carga, un cálculo incorrecto o una integración que deja de sincronizar.
La clave no es prometer que nunca habrá errores, sino acordar cómo se gestionan. Una incidencia debe poder registrarse, clasificarse por impacto, asignarse a alguien y cerrarse con una comprobación. Para los problemas más graves, el equipo necesita saber quién recibe la alerta, en qué plazo se empieza a investigar y cómo se informa a negocio.
Un buen acuerdo distingue, por ejemplo, entre una caída total, una función importante degradada y una mejora menor. Sin esa distinción, cualquier petición urgente compite con el trabajo planificado y el coste se vuelve imprevisible.
Infraestructura, copias y observabilidad
El software necesita un entorno donde ejecutarse y señales para saber si está sano. Según la solución, esto puede incluir hosting, base de datos, almacenamiento, dominios, certificados, servicios de correo, colas, monitorización y copias de seguridad.
No basta con pagar la infraestructura. Hay que decidir quién revisa alertas, qué se monitoriza, cuánto tiempo se guardan logs y cómo se prueba una restauración. Una copia de seguridad que nunca se ha restaurado es una hipótesis, no una garantía operativa.
Para un sistema relevante, los indicadores no deberían limitarse a “el servidor está encendido”. También importan los errores de aplicación, los trabajos fallidos, el consumo anómalo, la disponibilidad de integraciones y las métricas que anticipan fricción para usuarios.
Seguridad y actualizaciones de dependencias
Frameworks, librerías, navegadores, sistemas operativos y proveedores de identidad cambian. Mantener el software implica revisar actualizaciones, corregir vulnerabilidades relevantes, retirar accesos que ya no proceden y verificar que la autenticación, los permisos y el tratamiento de datos siguen respondiendo al uso real.
La prioridad debe basarse en riesgo, no en ansiedad. No todas las actualizaciones requieren la misma urgencia, pero dejar pasar indefinidamente las que afectan a componentes expuestos o datos sensibles aumenta la dificultad y el coste futuro.
Si el sistema usa IA, esta partida también incluye revisar permisos de las herramientas, límites de uso, trazabilidad, calidad de respuestas y cambios en los proveedores de modelos. Un agente que puede leer o escribir en sistemas de negocio necesita controles y supervisión acordes a su impacto.
Deuda técnica: el coste que se acumula en silencio
La deuda técnica aparece cuando una decisión rápida hace más difícil cambiar después: código duplicado, pruebas ausentes, dependencias obsoletas, reglas de negocio escondidas en una pantalla o integraciones sin documentación.
No es un defecto moral del equipo. A menudo es el resultado de priorizar una salida al mercado, una fecha comercial o una incidencia. El problema empieza cuando nunca se revisa. Entonces, tareas pequeñas comienzan a requerir semanas, cada modificación abre regresiones y sólo una persona entiende el sistema.
La forma práctica de gestionarla es convertirla en un backlog visible y priorizarla por riesgo de negocio: seguridad, disponibilidad, coste de cambio y dependencia de conocimiento individual. No hace falta reescribir una aplicación para reducir deuda; a menudo basta con aislar un módulo crítico, añadir pruebas a un flujo sensible o documentar una integración que nadie se atreve a tocar.
Evolución funcional: cambiar con criterio de negocio
Mantener también significa adaptar el producto a lo que aprende la empresa. Nuevos roles, reglas comerciales, informes, integraciones o automatizaciones pueden aportar más valor que el desarrollo inicial si se priorizan con cuidado.
Esta evolución no debe ocultarse dentro de una cuota de soporte. Es trabajo de producto: requiere definir el problema, validar el alcance, estimar impacto y comprobar el resultado. Separarlo permite que dirección vea cuánto invierte en continuidad y cuánto en nuevas capacidades.
Qué determina el coste de mantenimiento
No hay una cifra responsable que sirva para todo el software a medida. Lo importante es hacer visibles los factores que cambian el esfuerzo y el nivel de servicio necesario.
Criticidad, usuarios y horario de servicio
Cuanto mayor sea el coste de una interrupción, mayor deberá ser la preparación. Una herramienta que se usa una vez a la semana admite tiempos de respuesta distintos de un sistema que procesa pedidos o atiende a clientes durante toda la jornada.
El número de usuarios influye, pero no es el único factor. Importa la concentración del riesgo: si una aplicación la usan pocas personas pero bloquea la facturación, su criticidad es alta.
Integraciones y proveedores externos
Cada ERP, CRM, pasarela de pago, servicio de correo, API de logística o proveedor de IA añade una dependencia que puede cambiar fuera de vuestro control. Mantener estas conexiones exige observabilidad, gestión de credenciales, tratamiento de errores y un plan cuando un proveedor modifica condiciones o deja de ofrecer una función.
Por eso, al comparar propuestas, conviene preguntar qué integraciones están incluidas y quién es responsable de investigar un fallo cuando el origen está en un tercero.
Calidad del código, documentación y propiedad
Un sistema bien documentado, con repositorio accesible, despliegues reproducibles y pruebas en los flujos críticos es más sencillo de mantener, incluso si cambia el proveedor. Lo contrario crea una dependencia costosa: cada modificación exige primero descubrir cómo funciona todo.
La propiedad del código, las cuentas de infraestructura, los dominios y los servicios externos debe estar clara desde el inicio. No es una cuestión administrativa; determina si la empresa conserva capacidad de decisión cuando necesita evolucionar o sustituir un proveedor.
Datos, privacidad y requisitos sectoriales
Los datos personales, la información comercial sensible y los requisitos propios del sector cambian el nivel de control necesario. Permisos, auditoría, retención de datos y revisiones de seguridad no deben aparecer por sorpresa tras una incidencia.
Mapear qué datos existen, dónde se guardan y quién puede acceder a ellos ayuda a dimensionar el mantenimiento con rigor. También evita que una automatización se convierta en una vía de acceso innecesaria a información sensible.
Soporte, mantenimiento y evolución no son lo mismo
Mezclar estos términos es una de las causas más frecuentes de frustración entre empresa y proveedor.
- Soporte correctivo: recupera el funcionamiento esperado ante una incidencia.
- Mantenimiento preventivo: reduce riesgos con revisiones, actualizaciones, copias, seguridad, monitorización y reducción selectiva de deuda.
- Evolución funcional: incorpora cambios de producto o de proceso que aportan nuevas capacidades.
Los tres son necesarios, pero no se gestionan igual. El soporte requiere canal y prioridad. El mantenimiento preventivo necesita una rutina. La evolución pide backlog, contexto de negocio y validación. Cuando se separan, el presupuesto y las expectativas se vuelven mucho más claros.
Cómo presupuestar sin convertirlo en una bolsa de horas opaca
La mejor estructura no es necesariamente la más compleja. Debe permitir saber qué se está pagando, qué riesgo se está reduciendo y qué decisiones quedan pendientes.
Separar una base recurrente de la evolución
Una base recurrente puede cubrir la operación acordada: vigilancia, actualizaciones prioritarias, copias, revisión de seguridad, gestión de incidencias y una cadencia de seguimiento. Las nuevas funcionalidades, cambios de alcance o integraciones relevantes se estiman y priorizan aparte.
Esta separación evita dos extremos: pagar una cuota sin entender qué entrega y tratar cada pequeña tarea como una urgencia que rompe la planificación.
Definir SLA y responsabilidades
Un SLA útil especifica alcance y lenguaje común. Debe aclarar horarios de cobertura, canales de contacto, niveles de severidad, tiempos de primera respuesta, objetivo de recuperación, responsabilidades del cliente y exclusiones conocidas.
No es necesario sobredimensionarlo. Para muchas empresas B2B, un acuerdo realista en horario laboral, con un protocolo claro para incidencias críticas, es más valioso que prometer disponibilidad absoluta sin capacidad para sostenerla.
Crear un backlog y un roadmap trimestral
El mantenimiento gana valor cuando se revisa con negocio. Una reunión periódica puede revisar incidencias, deuda técnica, cambios de proveedores, métricas de uso y oportunidades de evolución.
El resultado debería ser un backlog priorizado y un roadmap trimestral pequeño: qué hay que proteger, qué se puede mejorar y qué conviene aplazar. Así el equipo no sólo reacciona a tickets; conserva capacidad para invertir en cambios que reduzcan coste o desbloqueen crecimiento.
Señales de que el mantenimiento ya es un riesgo de negocio
Estas señales no significan que haya que reescribir todo. Indican que conviene auditar la situación y definir un plan antes de que una incidencia obligue a decidir deprisa:
- Nadie sabe con seguridad dónde están el código, las credenciales o las copias.
- Cada cambio pequeño exige tocar muchas partes y provoca errores nuevos.
- Una persona o proveedor concentra conocimiento crítico sin documentación suficiente.
- Las alertas llegan por quejas de usuarios, no por monitorización.
- Hay dependencias o sistemas operativos sin actualizar desde hace mucho tiempo.
- Soporte urgente y nuevas funcionalidades compiten siempre por las mismas horas.
- El negocio tiene prioridades nuevas, pero el software no puede adaptarse al ritmo necesario.
Preguntas que hacer al proveedor antes de firmar
Una propuesta sólida responde de forma concreta a estas preguntas:
- ¿Qué incluye exactamente la cuota de mantenimiento y qué queda fuera?
- ¿Cómo se clasifican las incidencias y qué tiempo de respuesta aplica a cada nivel?
- ¿Quién supervisa infraestructura, copias, logs y alertas?
- ¿Cómo se gestionan actualizaciones de seguridad y dependencias?
- ¿Qué acceso tendrá nuestra empresa al repositorio, cuentas, documentación y credenciales?
- ¿Cómo se estiman y aprueban las evoluciones funcionales?
- ¿Cómo se prueba un cambio antes de ponerlo en producción?
- ¿Qué ocurre si una integración externa cambia o falla?
- ¿Qué indicadores revisaremos periódicamente?
- ¿Cómo podemos cambiar de proveedor sin perder el control del sistema?
Si las respuestas se reducen a una cifra mensual sin alcance, SLA, responsabilidades ni proceso de priorización, no hay suficiente información para comparar el coste real.
Un plan de 90 días para recuperar control
Si ya existe software sin un plan de mantenimiento claro, no hace falta resolverlo todo de una vez. Un primer ciclo de 90 días puede dar visibilidad y reducir riesgos relevantes.
Primeros 30 días: inventario y riesgos. Reunid acceso a repositorios, infraestructura, dominios, proveedores e integraciones. Identificad los flujos que no pueden detenerse, los datos sensibles y las personas que conocen el sistema. Documentad las incidencias recurrentes y el estado de copias, monitorización y despliegues.
Días 31 a 60: priorización y operación mínima. Corregid riesgos altos: accesos sin control, dependencias críticas, alertas inexistentes, copias no verificadas o puntos únicos de conocimiento. Definid canal de soporte, severidades y responsable de decisión. No intentéis eliminar toda la deuda técnica: elegid las acciones que reducen riesgo de negocio ahora.
Días 61 a 90: roadmap y presupuesto. Separad la operación recurrente de las mejoras. Estimad las iniciativas prioritarias, acordad una cadencia de seguimiento y publicad un roadmap trimestral breve. El objetivo no es producir documentación por sí misma, sino poder decidir qué mantener, qué evolucionar y qué no merece más inversión.
Conclusión: mantener es proteger la capacidad de cambiar
El mantenimiento de software a medida no es un gasto residual después del lanzamiento. Es la disciplina que mantiene disponible la operación, reduce riesgos de seguridad y permite que el producto siga acompañando al negocio.
La pregunta adecuada no es “¿cuál es la cuota más baja?”. Es “¿qué nivel de continuidad, control y capacidad de evolución necesitamos para que este sistema siga teniendo sentido?”. Cuando la respuesta se traduce en alcance, responsabilidades, métricas y roadmap, el coste deja de ser una sorpresa y se convierte en una inversión gobernable.
FAQ
¿Qué incluye normalmente el mantenimiento de software a medida?
Suele incluir soporte ante incidencias, actualizaciones prioritarias, supervisión de infraestructura, copias, seguridad, revisión de dependencias y un proceso de seguimiento. Las nuevas funcionalidades y cambios de alcance deben diferenciarse como evolución funcional para poder estimarlos y priorizarlos aparte.
¿Cuándo debería contratar mantenimiento para una aplicación?
Desde que la aplicación entra en producción y afecta a un proceso real. El nivel de servicio dependerá de su criticidad, usuarios, datos, integraciones y coste de una interrupción. Esperar a la primera incidencia grave suele encarecer la recuperación y limita las opciones de decisión.
¿Cuál es la diferencia entre soporte y mantenimiento?
El soporte corrige incidencias que rompen o degradan un comportamiento esperado. El mantenimiento añade trabajo preventivo: actualizaciones, seguridad, copias, monitorización y reducción de riesgos. Ambos son distintos de la evolución, que incorpora nuevas funciones o cambios de producto.
¿Cómo sé si mi software tiene demasiada deuda técnica?
Hay señales prácticas: cada cambio pequeño tarda demasiado, aparecen regresiones frecuentes, sólo una persona entiende partes críticas, faltan pruebas o documentación y las dependencias se acumulan sin revisar. Un diagnóstico técnico puede convertir esas señales en prioridades según impacto de negocio.
¿Necesito un SLA 24/7?
No necesariamente. El SLA debe corresponder al impacto real de una interrupción y a los horarios en que el sistema es crítico. Muchas empresas B2B necesitan una cobertura clara en horario laboral y un protocolo específico para incidencias graves, no una promesa 24/7 que no refleja su operación.
¿Puedo cambiar de proveedor de mantenimiento?
Sí, si la empresa conserva acceso al código, documentación, cuentas de infraestructura, dominios y credenciales. Por eso conviene acordar propiedad, accesos y un proceso de transición desde el inicio, en lugar de depender de conocimiento no documentado.