Contrato de desarrollo de software: checklist técnico para compradores argentinos

Un contrato de desarrollo de software no debería limitarse a indicar el precio y una fecha estimada. Para el comprador, el riesgo principal suele estar en otra parte: pagar por un producto difícil de aceptar, recibir código que no puede mantener, quedar atado al proveedor o descubrir demasiado tarde que ciertos accesos, datos o componentes no estaban incluidos.

La mejor forma de reducir esos problemas es convertir las expectativas técnicas y comerciales en compromisos verificables. El contrato debería explicar qué se construye, cómo se prueba, quién puede usar y modificar cada componente, qué ocurre con los datos, cómo se despliega el sistema, qué soporte se brinda y cómo puede terminar la relación.

Esta guía propone un checklist práctico para compradores argentinos. No reemplaza la revisión de un abogado ni de un profesional técnico. En proyectos relevantes, ambos deberían participar antes de firmar.

Respuesta corta

Antes de firmar un contrato de desarrollo de software, verificá que incluya como mínimo:

• Un alcance detallado, con funcionalidades, exclusiones y supuestos.
• Entregables concretos y criterios objetivos de aceptación.
• Fechas, dependencias del cliente y procedimiento para cambios.
• Reglas claras sobre código fuente, documentación, licencias y componentes de terceros.
• Accesos administrativos y titularidad de cuentas, dominios, repositorios e infraestructura.
• Responsabilidades sobre datos, credenciales, privacidad y seguridad.
• Proceso de despliegue, mantenimiento, soporte y corrección de errores.
• Plan de salida: exportación de información, entrega de materiales y asistencia de transición.

• Precio, hitos de pago, gastos adicionales y condiciones para suspender el trabajo.

Si uno de estos puntos queda implícito, probablemente aparezca como discusión durante el proyecto.

1. Alcance: qué se compra exactamente

El alcance es la primera sección que conviene revisar con mayor cuidado. Una frase como “desarrollo de una plataforma web” describe una intención, no un producto comprable.

El contrato debería vincular el alcance con documentación concreta: historias de usuario, casos de uso, diseños aprobados, especificaciones funcionales, requisitos de integración y restricciones técnicas. También conviene enumerar expresamente lo que no está incluido.

Por ejemplo, no es lo mismo incluir “un sistema de usuarios” que especificar:

• Registro e inicio de sesión.
• Recuperación de contraseña.
• Roles de administrador y operador.
• Bloqueo de cuentas.
• Registro de actividad.
• Integración con un proveedor externo.

• Diseño responsive para determinados dispositivos.

La precisión no elimina toda ambigüedad, pero mejora la conversación y permite estimar el trabajo adicional.

Checklist de alcance

• [ ] ¿Cada funcionalidad importante tiene una descripción comprensible?
• [ ] ¿Se identifican integraciones, formatos de datos y servicios externos?
• [ ] ¿Se detallan navegadores, dispositivos o entornos compatibles?
• [ ] ¿Se especifican exclusiones y supuestos?
• [ ] ¿Se distinguen tareas de desarrollo, carga de contenido y configuración?
• [ ] ¿Se aclara quién debe proporcionar información, accesos o aprobaciones?

• [ ] ¿Se indica cómo se documentan los cambios de alcance?

Un error común del comprador es asumir que una característica “obvia” está incluida. En software, lo obvio para el negocio puede requerir varias decisiones técnicas.

2. Entregables y aceptación

El contrato debería decir qué recibe el comprador y cuándo puede considerar terminado cada hito. Un entregable no es necesariamente una reunión, una demostración o una pantalla visualmente atractiva. Puede incluir código, pruebas, documentación, configuraciones, migraciones, manuales y acceso a ambientes.

La aceptación debe basarse en criterios observables. En lugar de “la aplicación debe funcionar correctamente”, conviene describir escenarios de prueba. Por ejemplo: “un usuario con rol operador puede crear una orden, adjuntar un archivo permitido, guardar el registro y consultarlo posteriormente”.

También es importante definir el plazo para revisar un entregable y qué sucede si el comprador encuentra observaciones. Una alternativa razonable es permitir el rechazo fundamentado cuando el entregable no cumple los criterios acordados, con un período para corregirlo y volver a presentarlo.

Ejemplo de criterio de aceptación

Funcionalidad: exportación de reportes.

Se considera aceptada cuando:

• Un usuario autorizado puede seleccionar un período.
• El sistema genera un archivo en el formato acordado.
• Los campos definidos en la especificación aparecen completos.
• El archivo puede abrirse sin errores en una herramienta compatible.

• La operación queda registrada en el historial del sistema.

Este nivel de detalle reduce discusiones subjetivas y facilita la gestión de hitos de pago.

3. Precio, hitos y cambios

Un precio fijo no significa automáticamente que todo cambio esté incluido. El contrato debería explicar qué ocurre si el comprador modifica una funcionalidad, agrega una integración o demora una aprobación.

Para cada cambio, conviene exigir una descripción breve con impacto en precio, plazo, riesgos y dependencias. La aprobación debería quedar registrada por un canal acordado. Así se evita que una conversación informal termine interpretándose como una instrucción vinculante.

Revisá también:

• Qué incluye el precio y qué se factura aparte.
• Si hay costos de servicios externos, infraestructura o licencias.
• Cuándo se emiten las facturas y cuándo vencen.
• Qué ocurre ante pagos demorados.
• Si existen topes para gastos reembolsables.

• Qué sucede si una parte suspende el proyecto.

En proyectos por horas o por tiempo y materiales, pedí una estimación de esfuerzo y un mecanismo de seguimiento. En proyectos por hitos, relacioná cada pago con entregables aceptables, no solamente con el paso del calendario.

4. Código fuente, propiedad y licencias

La propiedad del código merece una revisión específica. El contrato debería separar al menos cuatro categorías:

Categoría	Qué conviene aclarar
Código desarrollado para el proyecto	Entrega, uso, modificación y condiciones de transferencia según lo pactado

Material previo del proveedor

Qué componentes ya existían y qué derechos obtiene el comprador

Software de terceros

Licencias, restricciones, renovaciones y obligaciones aplicables

Componentes de código abierto

Licencias, avisos y condiciones de redistribución

No alcanza con escribir “el cliente será dueño del software” si no se define qué materiales integran ese software. Preguntá por repositorios, scripts de despliegue, configuraciones, pruebas automatizadas, documentación técnica y archivos necesarios para compilar o mantener el sistema.

También conviene identificar dependencias críticas. Un proveedor puede utilizar bibliotecas, plantillas, servicios o herramientas que no sean transferibles en los mismos términos que el código creado específicamente para el proyecto.

La forma correcta de estructurar los derechos puede depender del contrato, del tipo de componente y de la jurisdicción aplicable. Por eso, si el software es central para el negocio, pedí revisión legal especializada antes de firmar.

5. Repositorios, cuentas y accesos

Un comprador debería evitar que toda la operación dependa de cuentas personales del proveedor. Siempre que sea posible, los repositorios, dominios, cuentas de nube, tiendas, herramientas de analítica y servicios críticos deberían estar a nombre del comprador o bajo una estructura que permita transferirlos.

Como mínimo, documentá:

• Quién administra cada cuenta.
• Quién es titular de la cuenta.
• Cómo se almacenan y rotan las credenciales.
• Qué usuarios tienen permisos administrativos.
• Qué ocurre cuando una persona deja el proyecto.

• Cómo se revocan accesos al terminar la relación.

Una práctica útil es mantener un inventario de accesos y no compartir contraseñas por correo o chats comunes. El contrato puede exigir que el proveedor entregue la información necesaria para administrar los servicios, sin pedir que se expongan secretos fuera de canales seguros.

6. Datos, privacidad y seguridad

Si el sistema procesa información de clientes, empleados, proveedores o usuarios, el contrato debería asignar responsabilidades concretas. No supongas que la palabra “seguridad” cubre todo.

Acordá, según corresponda:

• Qué datos se procesan y con qué finalidad operativa.
• Quién decide sobre su uso y quién los procesa técnicamente.
• Dónde se alojan los ambientes y las copias.
• Qué medidas mínimas de acceso y autenticación se esperan.
• Cómo se informan incidentes o accesos no autorizados.
• Cómo se eliminan, devuelven o exportan los datos al finalizar.

• Qué proveedores externos intervienen.

No conviene inventar obligaciones regulatorias ni incorporar cláusulas copiadas de otro proyecto sin verificar su pertinencia. Las responsabilidades pueden variar según el tipo de dato, la actividad y los servicios utilizados. Para información sensible o sectores regulados, la revisión profesional es especialmente importante.

7. Despliegue y operación

Muchos contratos describen el desarrollo y olvidan el momento en que el sistema debe operar. Definí qué significa ponerlo en producción.

El despliegue puede incluir configuración de infraestructura, variables de entorno, dominios, certificados, migración de datos, monitoreo, copias de respaldo, permisos y capacitación. También puede requerir una ventana de mantenimiento y un plan de reversión si la publicación falla.

Preguntas prácticas:

• ¿Quién paga y administra la infraestructura?
• ¿Hay ambientes separados para desarrollo, prueba y producción?
• ¿Quién aprueba una publicación?
• ¿Cómo se realizan las migraciones?
• ¿Qué respaldos se generan y cómo se verifica su recuperación?
• ¿Qué documentación recibe el equipo interno?

• ¿Quién responde durante la salida a producción?

Si el proveedor propone administrar todo, preguntá cómo se preserva la continuidad si el contrato termina o si cambia el equipo asignado.

8. Soporte, garantía y mantenimiento

“Se incluye soporte” es demasiado amplio. El contrato debería diferenciar la corrección de defectos del desarrollo de nuevas funcionalidades.

Definí categorías de incidentes, canales de atención, horarios, tiempos objetivo de respuesta y condiciones de escalamiento. Usá lenguaje prudente: un tiempo de respuesta no necesariamente equivale a un tiempo de resolución.

También aclarar:

• Cuánto dura el período de corrección de errores.
• Qué se considera defecto y qué se considera cambio.
• Si el soporte se factura por separado.
• Cómo se actualizan dependencias y componentes.
• Qué pasa con vulnerabilidades o fallas de servicios externos.

• Si existe un mínimo mensual o una bolsa de horas.

Un ejemplo: si un botón debe guardar una operación y no lo hace, probablemente sea un defecto del alcance aceptado. Si después se pide que ese botón dispare una nueva integración, probablemente sea un cambio. El contrato debería ofrecer el criterio para distinguirlos.

9. Terminación y plan de salida

La salida no debe pensarse solamente cuando la relación ya está deteriorada. Incluso un proyecto exitoso puede terminar porque la empresa cambia de estrategia, internaliza el equipo o contrata otro proveedor.

El plan de salida debería indicar qué materiales se entregan, en qué formato y dentro de qué plazo. Puede incluir código fuente actualizado, documentación, bases exportadas, configuraciones, inventario de servicios, historial de incidencias y transferencia de conocimientos.

También conviene revisar:

• Causas y procedimiento de terminación.
• Pagos pendientes y entregables en curso.
• Acceso a cuentas y revocación de permisos.
• Exportación o devolución de datos.
• Asistencia de transición y su precio.
• Tratamiento de licencias y servicios que continúan vigentes.

• Obligaciones que sobreviven a la terminación, según corresponda.

Un proyecto verdaderamente comprable no es solamente el que puede comenzar. Es el que también puede mantenerse, transferirse o cerrarse de manera ordenada.

10. Señales de alerta para el comprador

Prestá atención si el contrato:

• Usa un alcance genérico sin anexos ni criterios de aceptación.
• Permite cambios de precio o plazo sin procedimiento claro.
• No menciona código fuente, repositorios o documentación.
• Deja todas las cuentas críticas bajo control personal del proveedor.
• Promete “seguridad total” sin medidas verificables.
• Confunde soporte con desarrollo ilimitado.
• No explica cómo se exportan datos ni cómo termina la relación.

• Exige aceptar entregables por silencio sin un proceso razonable de revisión.

Una cláusula llamativa no necesariamente es inválida, suficiente o conveniente para tu caso. Si existe una asimetría importante entre las partes, una dependencia técnica alta o información sensible involucrada, buscá asesoramiento legal y técnico independiente.

Conclusión

El checklist de un contrato de desarrollo de software en Argentina debería conectar negocio, tecnología y operación. Alcance, aceptación, código, accesos, datos, despliegue, soporte y salida forman un sistema: si uno queda indefinido, aumenta el riesgo de conflicto en los demás.

Antes de firmar, reuní al responsable del negocio, a una persona técnica y a un profesional legal. Pediles que revisen el mismo documento desde sus perspectivas y que conviertan las ambigüedades en decisiones escritas.

Si todavía estás comparando proveedores, consultá el directorio de empresas de software en Argentina. También podés explorar nuestras guías para ordenar la compra y contactarnos desde la página de contacto si necesitás orientación sobre el próximo paso.