Costo de mantenimiento de software: la línea del presupuesto que todo founder no técnico subestima
Una guía directa para el founder no técnico sobre lo que realmente paga después del lanzamiento, por qué “15% del build” es la regla equivocada para startups en etapa inicial, y el diagnóstico de cinco preguntas para estimar tu número real antes de que llegue.
Un founder con el que trabajamos el año pasado entregó un MVP limpio de USD 86.000. Checkout con Stripe, un panel administrativo, una app móvil pequeña. Cerró su ronda seed a tiempo, le dijo al board que el riesgo técnico estaba resuelto. Nueve meses después nos reenvió una factura de USD 14.200 y preguntó qué había pasado.
Lo que había pasado era ordinario. AWS deprecó el runtime de Node 14 en el que corrían sus Lambdas. Su proveedor de pagos mandó un aviso de 60 días sobre un cambio de firma de webhook que él no podía leer. El target SDK de Android estaba a punto de caer por debajo del mínimo de la Play Store, lo que habría sacado la app de la tienda entera. Sentry, agregado en un plan gratuito en el mes uno, había cruzado discretamente a un tier de USD 79/mes. Y su único developer se había ido a otro trabajo tres meses antes, así que el founder tuvo que traer a un contractor de USD 190/hora para perseguir todo eso.
Nada de eso fue sorpresa para nadie que entregue software para vivir. Todo eso fue sorpresa para él.
Costo de mantenimiento de software es el costo operacional recurrente de mantener un sistema vivo funcionando, seguro y útil después del lanzamiento. Está separado del costo de build. No es 15% de nada de manera significativa. Y para startups en etapa inicial, es la línea más consistentemente subestimada del presupuesto en los primeros dieciocho meses de un producto real en el aire.
Este texto es un framework de presupuesto para founder no técnico. Nombra las tres cosas que de verdad estás pagando, explica por qué la regla del porcentaje estándar falla en tu etapa, lista los costos escondidos que nadie te cotiza, y te da un diagnóstico de cinco preguntas para estimar tu número real antes de firmar lo que sea.
Las tres cosas que de verdad estás pagando
Toda cotización creíble de mantenimiento de software cubre alguna combinación de tres categorías. La mayoría de las cotizaciones no las separa. La mayoría de los founders, por consecuencia, no puede decir cuál está comprando lo suficiente.
Mantener las luces encendidas
El trabajo que tiene que pasar para que el producto siga vivo, con o sin feature nueva. Parches de seguridad. Actualización de dependencias. Upgrade de runtime cuando el cloud provider deprecia el que estás usando. Renovación de certificados. Verificación de backup. Migración cuando Stripe o el equivalente local cambia el contrato de un webhook. Cambios disruptivos de browser y de mobile OS.
Ese trabajo no es negociable. Si lo saltas, el producto eventualmente se rompe de una forma que sale más caro arreglar que el trabajo habría salido. El founder de arriba pagó USD 14.200 en un mes en gran parte porque nueve meses de mantener-las-luces-encendidas saltados se le acumularon de golpe.
Para un producto SaaS o marketplace típico de pre-A a Serie A con uno a tres servicios en producción, presupuesta 8 a 25 horas por mes de tiempo enfocado de ingeniería. Eso mapea a algo entre USD 1.500 y USD 5.000 al mes a tarifas razonables de contractor.
Pequeños ajustes
Bugs en producción. Edge cases que el beta no detectó. Un cliente específico no puede iniciar sesión. Un export genera un CSV mal formado. Un off-by-one de huso horario rompe un reporte diario. El form de signup rechaza un formato de email real.
La mayoría de los founders no técnicos mira esta categoría y piensa “cosas saliendo mal”. Es más preciso pensarla como el ruido irreducible de operar un producto real con usuarios reales. Un producto con cero pequeños ajustes es un producto que nadie está usando.
El volumen aquí escala con usuarios activos diarios y cadencia de release, no con el tamaño del código. Un producto B2B con 40 clientes genera de dos a seis pequeños ajustes por mes. Un producto B2C con 5.000 activos genera veinte. Presupuesta 15 a 40 horas por mes para producto en etapa inicial. Los founders subestiman esta categoría a la mitad porque el testing que ellos mismos hicieron antes del lanzamiento sacó a la luz una fracción pequeña de lo que los usuarios reales van a sacar.
Evolucionar
El trabajo que no es exactamente mantenimiento y no es exactamente producto nuevo. Es mantener el software con la forma de tu negocio mientras el negocio cambia. La página de pricing que lanzaste tenía tres tiers; la operación comercial que de verdad usas tiene cuatro. El onboarding asumía self-serve; tus clientes reales son demos guiadas. El panel admin funciona para un operador; ahora tienes tres y cada uno quiere filtros distintos.
Si no presupuestas para evolucionar, todo cambio de negocio se vuelve un debate sobre hacerlo ahora o esperar el siguiente release grande. Ese debate sale más caro que el trabajo. Para una startup iterando su modelo, presupuesta 20 a 60 horas por mes en los primeros dieciocho meses post-lanzamiento, bajando conforme el modelo se estabiliza.
Esas tres categorías suman. No se sustituyen entre sí. Una cotización que no las nombra es una cotización que no puedes presionar.
Por qué la regla del “15% del costo de build” está equivocada para founders
Pregúntale a internet cuánto cuesta el mantenimiento de software y te devuelve un porcentaje. Quince por ciento del build. Veinte. A veces treinta. Esa regla viene del lifecycle management de software empresarial, donde el alcance es estable, la base de usuarios es acotada, y la mayor parte del trabajo de mantenimiento es mantener-las-luces-encendidas más parches menores en un horizonte de cinco a diez años.
Ese mundo no es tu mundo.
En los primeros dieciocho meses post-lanzamiento, tu alcance no es estable. Sigues buscando product-market fit. Tu bucket de evolucionar a veces es más grande que tu costo de build porque cada conversación con cliente reconfigura la superficie. Tu base de usuarios crece un orden de magnitud por trimestre, lo que significa que cada bug de pequeños-ajustes aparece ante diez veces más gente al mes. Tu stack es más joven y menos estable que un codebase empresarial, así que el churn de dependencias pega más fuerte. Y tu equipo es más chico, así que no hay nadie que absorba un correo de deprecación sin facturarlo.
Para una startup típica de seed a Serie A, el costo anual real de mantenimiento de software en los años uno y dos suele caer entre 40% y 80% del costo original de build, no 15%. Para el año tres, conforme el alcance se asienta, ese número puede caer a 20%–30% si la ingeniería se hizo bien. Si no se hizo bien, el número del segundo año es aún más alto porque todo atajo del build vino a cobrar.
La regla del 15% no es mentira. Es una medición de un sistema distinto, aplicada al tuyo, y es uno de los números prestados más caros del software en etapa inicial. Si un proveedor te cotiza un paquete de mantenimiento al 15% del costo de build, pregúntale cuál de las tres categorías está cubierta. Casi con seguridad te están cotizando solo mantener-las-luces-encendidas.
Las líneas escondidas que nadie te cotiza
Cuando le pides una cotización de mantenimiento a un proveedor, recibes un número que incluye sus horas de ingeniería. Casi nunca recibes el resto de la cuenta.
Dependencias SaaS de terceros. Sentry, Postmark, Datadog, Auth0, Twilio, Segment, Mixpanel, Stripe Billing, Plaid, tu CDN, tu proveedor de email transaccional, tu captcha, tu scheduler. La mayoría tiene un tier gratuito en el que cabes al lanzamiento y un tier real al que creces alrededor del mes cuatro. El burn mensual acumulado para un producto Serie A típico es de USD 400 a USD 2.000, y casi nada aparece en tu cotización original.
Crecimiento del costo de infra. Tu cuenta de AWS o GCP en el día uno es chica porque el tráfico es chico. El crecimiento rara vez es lineal; una query que funcionaba bien en 1.000 filas se vuelve un timeout diario en 100.000. El founder que se salta una revisión trimestral de infra es el founder cuya cuenta de cloud de repente triplicó en octubre.
Cambios de precio de API en tus dependencias. OpenAI sube precios de modelo. Stripe se queda un mayor porcentaje en un método de pago del que dependes. Tu proveedor de geocoding aprieta el rate limit del plan en el que quedaste grandfathered. Nada de esto es negociable en el momento; todo tiene que ser absorbido o esquivado con trabajo de ingeniería.
Cobertura de on-call. Si tu producto necesita estar en el aire a las 2 de la mañana y la única persona que conoce el sistema está durmiendo, no tienes un producto mantenido, tienes un producto frágil. On-call es o una línea explícita (un fractional CTO con ventana de respuesta definida, un proveedor externo de SRE, un contractor con retainer) o un costo implícito que aparece como tu único developer quemándose en silencio.
Respuesta a incidentes de seguridad. La probabilidad anual de un evento de seguridad que requiere trabajo real no es trivial ni siquiera para productos chicos. Una API key expuesta en GitHub. Una filtración de credencial. Una regla de WAF que bloquea a un cliente real. Un DDoS que te cuesta un fin de semana. La respuesta se paga en horas que no existían en tu plan de mantenimiento.
Deprecaciones de terceros. Esto es lo que pescó al founder de arriba. Los cloud providers deprecan runtimes. Los proveedores de pago cambian firma de webhook. Los proveedores de email aprietan DMARC. Los vendors de mobile OS suben el target-SDK floor. Nada de eso es emergencia el día que llega el correo; todo se vuelve emergencia seis meses después cuando nadie le dio seguimiento.
Un presupuesto de mantenimiento que no tiene una línea explícita para cada uno de estos ítems no es un presupuesto. Es una conjetura.
Cinco preguntas para estimar tu costo real de mantenimiento
Antes de firmar cualquier acuerdo de mantenimiento, o antes de decidir cuánta capacidad de ingeniería interna mantener disponible, trabaja honestamente estas cinco preguntas con tu developer o tu proveedor. Toman una tarde. Te van a ahorrar el shock del segundo año.
1. ¿Cuántos servicios en producción corremos, y cuál es la cadencia de patch de cada uno? Dos servicios con actualización semanal de dependencias es una cuenta distinta de un monolito con actualización anual. Cuéntalos, lista la cadencia, y pregunta quién es responsable de cada uno.
2. ¿Cuál es nuestra cuenta mensual combinada de todos los SaaS, infra y APIs de terceros de los que dependemos, y cuáles tienen tiers gratuitos que vamos a desbordar en los próximos seis meses? Saca todo recibo. Lista todo servicio. Marca los que escalan con uso. La lista siempre es más larga de lo que el founder cree.
3. ¿Quién está en on-call, cuál es el compromiso de tiempo de respuesta, y cuánto cuesta? Si la respuesta es “nuestro único developer cuando vea el mensaje”, ya tienes tu respuesta. Después estima cuánto costaría que sea menos frágil.
4. ¿Cuál es nuestra cadencia de release planeada y el roadmap de features de los próximos dos trimestres, y qué proporción de eso es trabajo de evolucionar en superficies existentes vs. producto genuinamente nuevo? Si 60% del roadmap es reescribir el onboarding, el checkout y el admin, tu bucket de evolucionar es enorme y tienes que presupuestarlo como tal.
5. ¿Cuál es nuestro peor escenario en los próximos doce meses, y cuánto costaría recuperar? El único developer se va. Un cliente grande dispara una feature que toca todo. Cloud provider deprecia un runtime con 90 días de aviso. Elige los dos más probables. Estima el costo de recuperación. Suma buffer.
El founder que puede responder esas cinco preguntas tiene un número real de mantenimiento. El founder que no puede tiene un deseo.
Cómo presupuestar mantenimiento desde el año uno: el split 30-50-20
Para cada dólar del presupuesto anual de mantenimiento, asigna 30% a mantener-las-luces-encendidas, 50% a pequeños-ajustes y evolucionar combinados, y 20% a buffer. El buffer no es holgura; es la línea que absorbe las deprecaciones de terceros, el incidente de seguridad y la cuenta de SaaS sorpresa. El founder que no presupuesta buffer lo paga igual, solo que en pánico.
En dólares, para un producto SaaS o marketplace típico de pre-A a Serie A, eso da un presupuesto de mantenimiento del año uno en el rango de USD 30.000 a USD 90.000, encima del costo original de build. El rango refleja dos factores reales: cuánto de tu producto ya está en el aire (más superficie viva, más costo), y qué tan estable es tu modelo de negocio (más cambio, más trabajo de evolucionar). Si tu build fue de USD 80.000 y tu modelo se mueve cada trimestre, espera el extremo alto. Si fue de USD 200.000 y el modelo está asentado, puedes estar en el extremo bajo como fracción.
Ese es un número de partida para contrastar con el diagnóstico de arriba, no una respuesta final. El diagnóstico es el que da la respuesta final.
Cómo negociar mantenimiento en el contrato de desarrollo de software
El momento correcto de negociar mantenimiento es antes de firmar el contrato de build, no después de que el primer correo de deprecación llegó. Escribimos sobre estructura de contrato en nuestro texto sobre fixed price vs time and materials; la cláusula de mantenimiento es la parte que la mayoría de los founders se salta en la primera lectura.
Tres cosas en las que tienes que insistir antes de firmar.
Un alcance de mantenimiento nombrado, con las tres categorías separadas. No “soporte continuo”. Mantener-las-luces-encendidas como una línea con ventana de respuesta definida, pequeños-ajustes como una segunda línea con pool de horas mensuales, evolucionar como tercera línea con tarifa por hora aparte. Si el proveedor no las separa, estás comprando un balde y recibiendo la categoría que él quiera servir ese mes.
Código fuente a tu nombre desde el día uno, y acceso a todo servicio de tercero en tus cuentas, no en las de él. Esto no es negociable. El mantenimiento es imposible de cambiar de proveedor si el código vive en el GitHub de él y la cuenta de AWS está en su tarjeta corporativa. Nuestro texto sobre software house cubre la postura más amplia sobre rendición de cuentas del proveedor.
Cláusula de transición de 30 días. Si decides llevar el mantenimiento adentro de la casa o a otro proveedor, tienes 30 días de handover pago con documentación, transferencia de credenciales y un sprint final de actualización de dependencias. Sin esa cláusula, cambiar de proveedor te cuesta un rewrite forzado.
Para la pregunta más amplia de quién es responsable de la supervisión del mantenimiento cuando no tienes un CTO, nuestro texto sobre fractional CTO nombra las cuatro alternativas. Para la decisión in-house vs outsourcing específicamente en mantenimiento, nuestro texto sobre in-house vs outsourcing da el framework de tres ejes. Versión corta para mantenimiento: tercerizar mantener-las-luces-encendidas casi siempre es la decisión correcta en etapa inicial; traer pequeños-ajustes adentro empieza a tener sentido cuando hay volumen para justificar una persona dedicada; evolucionar es la última categoría que se internaliza, porque ahí es donde se acumula el conocimiento de negocio. El texto completo sobre cuánto cuesta desarrollar una app es el complemento por el lado del costo de build; leer los dos junto da el cuadro completo de los dos primeros años.
FAQ
¿Cuánto cuesta mantener un software?
Para un producto SaaS o marketplace típico de pre-A a Serie A, el mantenimiento anual cae entre USD 30.000 y USD 90.000 en los años uno y dos, encima del costo original de build. Ese número se rompe en tres categorías: mantener-las-luces-encendidas, pequeños-ajustes y evolucionar. La regla del 15 a 20% del build que aparece en la mayoría de las páginas de agencia viene del software empresarial y subestima consistentemente el costo real para startups con alcance en movimiento.
¿Cómo estimar el costo de mantenimiento de software?
Responde cinco preguntas honestamente con tu developer o proveedor: cuántos servicios en producción corres y su cadencia de patch; la cuenta mensual combinada de todo SaaS, infra y API de terceros del que dependes; quién está en on-call y a qué costo; tu cadencia de release y la división entre trabajo de evolucionar y producto genuinamente nuevo; y tu peor escenario en los próximos doce meses. Suma las cinco respuestas, suma 20% de buffer. Quien te cotice un número de mantenimiento sin trabajar esos cinco insumos te está cotizando una conjetura.
¿Cuál es el porcentaje típico de costo de mantenimiento?
La regla del 15 a 20% viene de software empresarial con alcance estable. Para startups en etapa inicial, el mantenimiento anual real en los años uno y dos típicamente queda entre 40% y 80% del costo original de build, cayendo a 20%–30% para el año tres si la ingeniería se hizo bien. El enmarcado por porcentaje es menos útil que el de categorías; pregunta qué estás pagando, no qué fracción del build equivale.
¿Por qué el mantenimiento de software es caro?
Tres razones. El mundo alrededor de tu software no se detiene (cloud provider, procesador de pagos, vendor de mobile OS y APIs de terceros fuerzan cambios que tienes que absorber). Tus usuarios sacan a la luz bugs y edge cases que ninguna cantidad de testing interno encuentra. Y tu negocio cambia más rápido que tu código, así que el software tiene que ser reconfigurado para caber en el negocio. La combinación de los tres es lo que hace el mantenimiento más caro de lo que el founder espera, y lo que hace que la regla del 15% sea consistentemente baja.
Un producto vivo no es un producto terminado. El costo de operarlo con honestidad es su propia línea, y los founders que lo planean en el mes uno son los founders cuyo correo del mes nueve es sobre un cliente nuevo, no sobre una factura de USD 14.000.