Cuánto Cuesta Mantener Software Después del Launch: Benchmark SaaS DACH
El launch no termina el presupuesto de software. Cambia su forma. Antes del launch, el dinero compra discovery, implementación, QA y despliegue. Después, compra continuidad: bugs, upgrades de dependencias, cloud y observabilidad, seguridad, compliance, soporte, iteración de producto y trabajo de emergencia.
Este artículo está separado a propósito de nuestra guía de desarrollo de software a medida. Esa guía responde a la intención de coste de construcción. Este benchmark responde a la intención post-launch: cuánto cuesta mantener una aplicación SaaS al año cuando ya está viva.
¿Necesitas un presupuesto de mantenimiento defendible?
Planificar el modelo operativoLa respuesta benchmark
Para un SaaS DACH, presupuestar entre el 18 y el 30 % del coste original de construcción por año es un primer rango razonable si el producto sigue evolucionando. Una herramienta interna estable puede acercarse al 10-16 %. Un SaaS regulado, intensivo en integraciones o en crecimiento rápido puede llegar al 35-60 % cuando compliance, soporte, seguridad e iteración están activos a la vez.
En nuestro benchmark direccional de 24 productos SaaS y similares en DACH mantenidos entre 2023 y mediados de 2026, el gasto mediano fue del 24 % del coste de build en el año uno, 21 % en el año dos y 26 % en el año tres. El repunte del tercer año vino de versiones mayores de frameworks, crecimiento cloud, peticiones acumuladas, evidencia de compliance, hallazgos de seguridad e integraciones convertidas en críticas para negocio.
| Año post-launch | Gasto mediano | Rango central | Para un build de EUR 150k | Qué lo impulsa |
|---|---|---|---|---|
| Año 1 | 24 % del build | 16-34 % | EUR 36k | Defectos de launch, soporte, observabilidad, seguridad básica, primera iteración. |
| Año 2 | 21 % del build | 13-31 % | EUR 31,5k | Menos bugs de launch, más soporte, updates de dependencias, producto medido. |
| Año 3 | 26 % del build | 15-40 % | EUR 39k | Upgrades mayores, compliance, escala, drift de integraciones y limpieza arquitectónica. |
Qué entra en mantenimiento de software
La terminología ISO/IEC separa mantenimiento correctivo, adaptativo, perfectivo y preventivo. En SaaS real: lo correctivo arregla defectos; lo adaptativo mantiene el producto usable cuando cambian browsers, APIs, dispositivos o leyes; lo perfectivo mejora producto y mantenibilidad; lo preventivo reduce riesgo futuro.
| Línea | Incluye | No incluye |
|---|---|---|
| Bug fixes | Defectos en producción, regresiones, edge cases de datos, workflows rotos. | Features grandes disfrazadas de bug. |
| Dependencias y frameworks | Packages, runtimes, SDKs, clientes de base de datos, migraciones con breaking changes. | Rewrites por gusto. |
| Cloud y observabilidad | Hosting, logs, métricas, trazas, alertas, backups, uptime checks, revisión de costes. | Gasto cloud sin dueño. |
| Seguridad | Remediación de vulnerabilidades, rotación de secretos, access review, SAST/SCA, fixes de pentest. | Una casilla anual. |
| Compliance | GDPR, DPAs, evidencia de auditoría, retención, readiness AI Act/CRA/NIS2 si aplica. | Solo asesoría legal. |
| Soporte | Triage técnico, problemas de usuarios, solicitudes admin, comunicación de incidentes, documentación. | Estrategia de customer success. |
| Iteración de producto | Mejoras pequeñas, UX fixes, reports, polish de workflow, mejoras de conversión. | Una línea de producto nueva. |
| Emergencias | Caídas, incidentes de proveedor, fixes urgentes de seguridad, reparación de datos, rollback. | Presión de roadmap llamada urgente. |
Años uno, dos y tres por partida
| Partida | Año 1 | Año 2 | Año 3 | Por qué cambia |
|---|---|---|---|---|
| Bug fixes | 4,0 % | 2,5 % | 3,0 % | Los bugs de launch bajan; las integraciones antiguas crean nuevos casos. |
| Dependencias y frameworks | 2,0 % | 3,0 % | 5,0 % | Si se posponen updates, las versiones mayores llegan juntas. |
| Cloud y observabilidad | 4,0 % | 4,0 % | 5,0 % | Uso, logs, retención y monitoring crecen con adopción. |
| Seguridad | 3,0 % | 2,5 % | 3,0 % | Primero se instalan básicos; luego se corrige drift de supply chain y accesos. |
| Compliance | 2,0 % | 2,0 % | 3,0 % | Clientes y reguladores piden más evidencia. |
| Soporte | 3,0 % | 3,0 % | 4,0 % | Más usuarios implican más triage, admin y documentación. |
| Iteración de producto | 5,0 % | 3,0 % | 2,0 % | El feedback inicial es denso; luego suele pasar a roadmap aparte. |
| Emergencias | 1,0 % | 1,0 % | 1,0 % | Una reserva evita discutir compras durante un incidente. |
| Total | 24,0 % | 21,0 % | 26,0 % | Ajusta con la calculadora. |
Calculadora interactiva de mantenimiento
Úsala como primera estimación para dirección o board. Parte del benchmark y ajusta por tipo de producto, compliance, uso, soporte y deuda técnica.
Dependencias, cloud, seguridad, compliance y soporte
El SaaS moderno no es solo código propio. Es supply chain: frameworks, packages, SDKs, herramientas de build, imágenes de contenedor, servicios cloud y APIs. Los datos de Sonatype sobre Log4j, reportados por ITPro, muestran que años después de Log4Shell seguían descargándose versiones vulnerables pese a existir fixes. La razón práctica es simple: si nadie posee el mantenimiento de dependencias, la vulnerabilidad se queda.
Cloud y observabilidad tampoco son opcionales. Tráfico, logs, trazas, métricas, storage, backups, colas, email, búsqueda, APIs de IA y monitoring se vuelven costes recurrentes. Seguridad y compliance son trabajo de ciclo de vida: GDPR ya aplica; NIS2, Cyber Resilience Act y EU AI Act aumentan la presión según producto y sector. Soporte convierte el mantenimiento oculto en señales visibles.
Iteración sin canibalizar el coste de build
La guía de costes de construcción responde: cuánto cuesta crear el producto. Este benchmark responde: cuánto cuesta mantenerlo útil después de existir. Pequeñas mejoras de workflow, UX, reports y conversión pertenecen al mantenimiento. Nuevos módulos, nuevas personas, pricing nuevo o app móvil junto al producto web suelen necesitar presupuesto de roadmap aparte.
La ruta comercial es: desarrollo de software a medida para construir, QA de software para confianza y regresión, y fractional CTO cuando el producto necesita ritmo operativo, decisiones de arquitectura y accountability de proveedores.
Fuentes y caveat
Benchmark basado en observaciones de Wavect sobre 24 productos DACH anonimizados, más evidencia externa sobre categorías de mantenimiento, supply chain y regulación UE. Es direccional, no encuesta representativa. Para categorías de mantenimiento, consulta ISO/IEC/IEEE 14764 y SWEBOK. Para riesgo de supply chain, ver ITPro sobre Sonatype/Log4j y SLSA en arXiv. Para obligaciones UE, revisa GDPR, NIS2, Cyber Resilience Act y EU AI Act. Para precios, revisa AWS CloudWatch, Datadog y Sentry.
Reflexiones finales
Un presupuesto sano de mantenimiento SaaS no es un retainer difuso. Es un modelo operativo post-launch con partidas nombradas: bugs, dependencias, cloud, observabilidad, seguridad, compliance, soporte, iteración y emergencias. Para un SaaS normal que sigue evolucionando, 18-30 % del coste original de build por año es un primer rango defendible.
Separa presupuesto de build, mantenimiento y roadmap. Si los mezclas, llega la sorpresa clásica después del launch: todos creían que el producto estaba terminado, mientras el software ya era un sistema vivo con usuarios, dependencias, leyes e incidentes.
¿Quieres convertirlo en tu plan de mantenimiento?
Hablar con WavectConstruye el producto, no solo el backlog
Si este artículo conecta con una decisión real de producto, Wavect puede ayudarte a definir, construir, endurecer o liderar el trabajo de software con criterio senior de founder.
Rutas de servicio útiles: