La respuesta corta

El mantenimiento de una app no es una sola cosa, y ahí empiezan casi todos los malentendidos contractuales. Hay tres modelos y no sirven para lo mismo:

  1. Bolsa de horas. Compras un número de horas y se van consumiendo.
  2. Persona o personas dedicadas. Un equipo asignado, con dedicación conocida.
  3. Mantenimiento por presupuesto. Cada trabajo se define y se presupuesta aparte.

No hay uno mejor. Hay uno que encaja con tu producto, tu ritmo de cambio y tu forma de decidir. Elegir el equivocado es lo que produce la sensación de «pago mantenimiento y no avanza nada» — o la contraria, «pagamos un equipo entero para tres correcciones al mes».

(Los importes dependen del perfil y de la dedicación, así que aquí no van números: lo que cambia la decisión es el modelo, no la tarifa.)

Modelo 1 · Bolsa de horas

Cómo funciona. Se contrata un volumen de horas y se consume contra peticiones. Suele tener vigencia temporal y un compromiso de respuesta.

Cuándo encaja. Producto estable, con cambios pequeños y esporádicos. Cuando no sabes cuánto vas a necesitar y prefieres no comprometerte a una dedicación fija.

Lo bueno. Flexibilidad y control del gasto. Pagas por lo que usas.

Lo que hay que vigilar:

  • La caducidad. Si las horas expiran sin consumirse, es dinero perdido y genera prisas artificiales al final del periodo.
  • La priorización. Sin un responsable claro del lado del cliente, la bolsa se consume en peticiones sueltas y nunca en lo importante.
  • La disponibilidad. Una bolsa no reserva a nadie: si el equipo está en otro proyecto, tu petición espera. Conviene pactar el tiempo de respuesta por escrito.
  • La erosión. Las horas se van en cosas menores y llega el año siguiente sin haber tocado la deuda técnica ni las actualizaciones de plataforma.

Modelo 2 · Persona o personas dedicadas

Cómo funciona. Una o varias personas con dedicación conocida —completa o parcial— asignadas al producto durante un periodo.

Cuándo encaja. Producto vivo, con hoja de ruta, cambios continuos y necesidad de que alguien conozca el sistema de verdad. También cuando hay compromisos de servicio que exigen disponibilidad.

Lo bueno. Continuidad y contexto. La persona que arregla el fallo del martes es la que construyó eso, y eso se nota en el tiempo de resolución. Además permite planificar: hay capacidad conocida por sprint.

Lo que hay que vigilar:

  • Que haya trabajo que justifique la dedicación. Un equipo dedicado sin cola de trabajo es caro y desmotivador.
  • La sustitución. Qué pasa cuando esa persona se va o cambia de proyecto, y cuánto solapamiento se garantiza.
  • La tentación de usarlo para todo. Si el equipo dedicado acaba haciendo soporte de primer nivel, no está haciendo producto.
  • La medición. Con dedicación fija, el indicador no son las horas: es lo entregado. Hay que acordar cómo se ve el avance.

Modelo 3 · Mantenimiento por presupuesto

Cómo funciona. Cada trabajo se define, se estima y se aprueba antes de hacerse. Lo más parecido a un proyecto pequeño repetido.

Cuándo encaja. Organizaciones con procesos de compra formales, donde cada gasto necesita su aprobación. Y productos con cambios grandes y espaciados, más que un goteo continuo.

Lo bueno. Visibilidad total del coste antes de empezar y trazabilidad de qué se pagó por qué. En sector público y en corporaciones con control de gasto, a veces es el único modelo viable.

Lo que hay que vigilar:

  • La latencia. Entre que se detecta algo y se aprueba el presupuesto pasa tiempo. No sirve para incidencias urgentes: eso necesita otro mecanismo.
  • El coste de definir. Estimar cada cambio pequeño consume esfuerzo de las dos partes. Por debajo de cierto tamaño, definir cuesta más que hacer.
  • Los correctivos. Un fallo del propio desarrollo no debería presupuestarse como si fuera nuevo trabajo. Eso se pacta antes, con su garantía.

Lo que va en cualquiera de los tres

Independientemente del modelo, hay trabajo que no es opcional y que conviene tener explícitamente cubierto:

  • Mantenimiento de plataforma. Cada año hay requisitos nuevos de las tiendas y versiones mínimas que suben. No añade valor visible y no es negociable — el caso vivo está en auditar el código de una app heredada.
  • Renovación de certificados y cuentas, con responsable y fecha.
  • Dependencias, que envejecen aunque no toques nada.
  • Vigilancia: alguien mira los errores y las métricas, o no hay mantenimiento, hay reacción.
  • Correctivos con garantía, distinguidos de las evoluciones.

Un contrato de mantenimiento que no nombra el mantenimiento de plataforma es un contrato incompleto, y el año siguiente aparece como imprevisto.

Cómo elegir

Tres preguntas, y salen solas:

  1. ¿Cuánto va a cambiar el producto en los próximos doce meses? Mucho y continuo → dedicación. Poco y esporádico → bolsa. Grande y espaciado → presupuesto.
  2. ¿Hay compromisos de disponibilidad? Si hay que responder en horas, la bolsa sin reserva no basta.
  3. ¿Cómo aprueba el gasto tu organización? Si cada euro necesita expediente, el modelo por presupuesto se impone aunque no sea el más ágil.

Y una combinación que funciona mejor de lo que parece: dedicación parcial para lo continuo, más presupuesto aparte para las evoluciones grandes. Lo pequeño fluye, lo grande se decide con calma.

Antes de firmar

  1. ¿Qué entra como correctivo con garantía y qué cuenta como evolutivo?
  2. ¿Qué tiempos de respuesta hay, y para qué severidades? Está desarrollado en SLA de una app móvil.
  3. ¿Quién prioriza del lado del cliente?
  4. ¿Cómo se reporta lo consumido y lo entregado?
  5. ¿El mantenimiento de plataforma está incluido o se factura aparte?

La quinta es la que más discusiones evita al año siguiente.

Los modelos con los que trabajamos y qué incluye cada engagement están en precios.