Mantenimiento de software a medida: qué incluir al contratar

Antes de comparar cuotas mensuales, pedí que cada proveedor ubique el trabajo en estas tres categorías. Es una forma de comparar alcances que proponemos en Duotach: no es una definición legal de garantía ni reemplaza las condiciones del contrato.

La garantía debe remitir al comportamiento y a las condiciones de aceptación acordados. La operación cubre las tareas recurrentes expresamente contratadas. La evolución agrega o cambia capacidades. Un mismo proveedor puede atender las tres, pero cada solicitud necesita una categoría y una regla de aprobación.

Un acuerdo de nivel de servicio, o SLA, necesita describir cuándo empieza el reloj y qué resultado compromete. Separá primera respuesta, diagnóstico, medida temporal para recuperar una función y resolución definitiva. Que alguien conteste el ticket no demuestra que la operación haya vuelto.

Como referencia de esa distinción, AWS publica tiempos de respuesta humana según plan y severidad. Sus condiciones no son el SLA de tu aplicación ni una promesa de resolverla en ese mismo intervalo. Documentación consultada el 2 de noviembre de 2026.

Pedí horario y zona horaria, feriados aplicables, canal para urgencias y responsable de escalamiento. Definí la severidad con impacto operativo: una función crítica detenida sin alternativa merece un tratamiento distinto de un cambio visual. Si necesitás atención fuera de horario, debe quedar contratada; una alerta automática por sí sola no prueba que haya una persona de guardia.

Incluí qué pasa cuando la causa está en un proveedor externo: quién abre el caso, quién informa, qué alternativa se puede usar y quién autoriza su activación. El soporte de infraestructura y el soporte de la aplicación necesitan responsables identificados.

Pedí una fila por componente relevante, aunque algunos los opere tu equipo IT. El objetivo es identificar los límites entre aplicación, infraestructura e integraciones. La siguiente matriz es una propuesta de evaluación; no significa que toda tarea esté incluida en cualquier abono.

Asigná quién revisa las actualizaciones y con qué evidencia se aprueban. Dependabot abre propuestas de actualización que se gestionan como otras pull requests. Tener el aviso o la propuesta no demuestra que el cambio sea compatible con tu proceso.

Pedí que el alcance indique entorno de prueba, responsable de aprobación, ventana de cambio y procedimiento de vuelta atrás. Elegí recorridos que representen el uso acordado: inicio de sesión, permisos, una operación principal y la integración que dependa del componente actualizado. El proveedor debe registrar la versión y el resultado, además de decir que actualizó una librería.

Si el sistema usa un modelo de IA o una API externa, incluí su comportamiento en esas pruebas cuando afecte la función. Cambiar código y cambiar datos necesitan procedimientos distintos: volver a una versión anterior no debe darse por equivalente a recuperar información o deshacer acciones externas.

La palabra backup necesita un alcance. Pedí fuentes incluidas, frecuencia, retención, acceso a las copias, responsables y procedimiento de recuperación. Acordá la pérdida de información y el tiempo fuera de servicio que el negocio puede tolerar; el proveedor debe contrastar esos objetivos con el diseño y las pruebas.

Supabase documenta que sus backups de base de datos no incluyen los objetos guardados mediante Storage API. También advierte que una restauración puede dejar el proyecto inaccesible. Es un límite de ese producto, consultado el 2 de noviembre de 2026; otros servicios requieren su propia revisión.

En un ejemplo ficticio, un portal guarda solicitudes en una base y adjuntos en almacenamiento de archivos. Recuperar las filas sin poder abrir los adjuntos no cumple una prueba de recuperación del proceso completo. Pedí una prueba autorizada en un entorno aislado, con el resultado, las dependencias pendientes y quién acepta la recuperación. Este ejemplo no corresponde a un cliente ni a un resultado medido.

El reporte mensual debe permitir comprobar el alcance pagado: controles ejecutados, incidentes y su estado, cambios aplicados, pruebas realizadas y riesgos pendientes con responsable. Si el mes compró operación, la ausencia de funciones nuevas no implica que faltó trabajo. Si compró evolución, el reporte debe mostrar avance contra las prioridades acordadas.

Pedí que se distingan compromisos, avance y trabajo terminado. Una tarea iniciada no está aceptada por aparecer en el tablero. Si un incidente desplaza una mejora, debe quedar registrado qué cambió de prioridad y qué decisión tomó tu equipo.

Compará el costo del desarrollo, el servicio recurrente y el consumo de terceros por separado. El alcance cambia según criticidad, componentes, horario y capacidad de evolución. Un porcentaje del precio inicial no describe por sí solo qué atención estás comprando.

Antes de firmar, acordá también cuándo empieza cada cobertura y cómo se evita cobrar dos veces la misma corrección. Si termina el acompañamiento, deben quedar responsables para las tareas que continúan, accesos de la empresa y tratamiento de pendientes. Para comprobar código, cuentas y documentación, usá la guía de entrega de software a medida.

Duotach desarrolla software a medida para empresas y contempla mantenimiento y nuevas funcionalidades dentro de un acompañamiento con alcance acordado. Al conversar sobre un desarrollo o una ampliación, describí el proceso, los sistemas que intervienen, quién lo operará y qué atención necesitás después de la entrega.

La propuesta debe separar construcción, garantía, operación y evolución. No prometemos con esta guía un horario de guardia, una tarifa universal ni tomar cualquier sistema existente sin evaluación. El relevamiento técnico, la revisión del código y las pruebas específicas pertenecen al trabajo pago que se acuerde.

El formulario abre una consulta sobre el proyecto. No necesitás adjuntar credenciales ni datos personales de usuarios para explicar el problema.