Contrato de desarrollo de software en México: qué exigir

Un contrato de desarrollo de software debe hacer visibles las decisiones que evitan disputas: qué se entregará, cómo se aceptará, quién podrá usar y modificar el código, qué soporte existe y cómo recuperarás operación y datos si la relación termina. No basta con una propuesta comercial ni con una lista de pantallas.

Esta guía es una checklist operativa, no asesoría legal. En México, revisa el contrato y sus anexos con un abogado que conozca propiedad intelectual, datos y el tipo de operación de tu empresa. La redacción final depende de las partes, el modelo de contratación y las leyes aplicables.

Empieza por el alcance verificable

El contrato debe referirse a un anexo técnico que describa el problema, flujos incluidos, usuarios, datos, integraciones, exclusiones, hitos y criterios de aceptación. Una frase como desarrollar un sistema administrativo no permite saber cuándo una entrega está completa.

Pide que el anexo incluya escenarios de prueba. Por ejemplo: crear un cliente, aplicar una regla de autorización, corregir un registro y exportar un reporte. Para cada escenario define datos de entrada, resultado esperado y evidencia. Si un requisito cambia, debe quedar un mecanismo claro para evaluar impacto en alcance, tiempo y precio antes de construirlo.

También define lo que queda fuera. Migración histórica, limpieza de datos, compra de licencias, altas con terceros, contenido, infraestructura, capacitación adicional y cambios regulatorios no deben aparecer como supuestos silenciosos. Las exclusiones no son una señal de poca colaboración; permiten que ambas partes planeen el trabajo real.

Propiedad del código: pregunta qué se cede y qué se licencia

El código es del cliente puede significar cosas distintas. Pide precisión sobre código fuente, código objeto, documentación, diseños, scripts de despliegue, configuraciones, pruebas, modelos de datos, automatizaciones y materiales de terceros. Define si se trata de una cesión de derechos patrimoniales, una licencia de uso o una combinación, y en qué momento produce efectos.

La Ley Federal del Derecho de Autor protege programas de cómputo y contempla facultades patrimoniales relacionadas con reproducción, adaptación, distribución y puesta a disposición. Puedes consultar el texto vigente de la Ley Federal del Derecho de Autor de la Cámara de Diputados , especialmente sus disposiciones sobre programas de cómputo. La aplicación concreta debe revisarla un abogado; no basta con copiar una cláusula de internet.

Distingue el trabajo específico de los componentes preexistentes. Un proveedor puede usar herramientas, plantillas, librerías o plataformas que no puede ceder porque pertenecen a terceros o porque se reutilizan en otros proyectos. Eso no es necesariamente un problema si el contrato identifica esos componentes, sus licencias, la forma en que se entregan y el derecho que recibes para operar el sistema.

Entregables que debes poder recibir y usar

No aceptes entrega del sistema como único entregable. Usa esta checklist para acordar qué se entrega en cada hito y al cierre.

• Código fuente y repositorio, con acceso de la empresa o mecanismo de transferencia verificable.
• Instrucciones de instalación, despliegue, variables de configuración y dependencias, sin secretos expuestos.
• Esquema de datos, migraciones y procedimiento para respaldar y restaurar.
• Documentación de APIs, integraciones, cuentas técnicas y responsables de cada tercero.
• Pruebas acordadas, evidencia de aceptación y lista de incidencias pendientes.
• Manual operativo para usuarios y administradores, según el alcance.
• Inventario de componentes de terceros, versión y licencia aplicable.
• Acceso a dominios, cuentas de infraestructura y monitoreo que sean necesarios para continuar la operación.

Si una parte se entrega por etapas, vincula el pago a un hito verificable y a una revisión razonable. Evita que la aceptación quede abierta indefinidamente, pero evita también que se tenga por aceptado algo que no pudo probarse por falta de accesos, datos o ambientes proporcionados por la otra parte.

Soporte, garantía y mantenimiento no son lo mismo

La garantía suele referirse a corrección de defectos respecto de los criterios acordados durante un periodo definido. El soporte atiende dudas, incidentes y operación. El mantenimiento evolutivo agrega o cambia capacidades. Pide que el contrato los distinga: una nueva función no es automáticamente un defecto, y un error que impide el flujo principal no debería confundirse con una mejora opcional.

Define severidades con ejemplos, canal de reporte, horario, tiempos de primera respuesta, tiempos objetivo de resolución, dependencias del cliente y forma de cerrar una incidencia. Si el proceso es crítico, acuerda cómo se comunica una interrupción, quién toma decisiones y qué evidencia se conserva. Un soporte incluido sin estos límites no permite planear continuidad.

Para cambios posteriores, usa una orden de cambio: descripción, motivo, impacto, estimación, aprobación y fecha. Este mecanismo protege tanto al cliente como al proveedor de cambios verbales que se vuelven urgencias sin presupuesto ni pruebas.

Datos, accesos y seguridad

El contrato debe identificar qué datos procesa el sistema, dónde se alojan, quién es responsable de administrar accesos y qué sucede con la información al terminar el servicio. Define mínimo privilegio, cuentas individuales, baja de accesos, registro de acciones relevantes, respaldos y manejo de incidentes.

Cuando intervienen proveedores de nube, mensajería, pagos o IA, identifica qué cuenta contrata cada parte, quién paga, quién es dueño administrativo y cómo se entregan los accesos. No compartas contraseñas por correo ni dejes una cuenta personal como única llave de una operación empresarial.

Si el software procesa datos personales, la evaluación legal y de privacidad requiere atención específica. El contrato técnico puede describir medidas y responsabilidades operativas, pero no sustituye avisos de privacidad, bases de tratamiento ni obligaciones jurídicas aplicables.

Salida y continuidad: la cláusula que se revisa demasiado tarde

Una salida bien definida no presume conflicto; permite cambiar de proveedor, internalizar operación o cerrar un proyecto sin retener datos ni conocimiento. Pide un proceso de transición: qué se entrega, en qué formato, en cuánto tiempo, con qué colaboración, quién paga el soporte de transferencia y qué accesos se revocan después.

Incluye exportación de datos y archivos en formatos razonables, documentación actualizada, transferencia o sustitución de cuentas, entrega de repositorios y confirmación de respaldos. Si dependes de una plataforma de terceros, no prometas una portabilidad imposible: especifica sus límites, sus contratos y cómo se conserva la información necesaria.

El INDAUTOR señala que los programas de cómputo pueden registrarse y que los actos, convenios o contratos relativos a derechos patrimoniales forman parte de los trámites que pueden inscribirse; consulta su información general de registro y recibe orientación jurídica para decidir si aplica a tu caso. Registro y contrato son decisiones distintas; no des por hecho que una sustituye al otro.

Pagos, dependencia y responsabilidades

Vincula pagos a entregables, no sólo al paso del calendario. Para cada hito define qué debe entregarse, quién revisa, cuánto dura la revisión y qué ocurre si hay observaciones. Si el cliente debe proporcionar datos, accesos, decisiones o usuarios de prueba, deja esas dependencias por escrito; de otro modo, los retrasos se discutirán cuando ya afecten el proyecto.

Aclara responsabilidades sobre servicios de terceros. Una integración puede depender de que un banco, un ERP, un proveedor de mensajería o una autoridad mantenga una interfaz disponible. El desarrollador debe comprometer lo que controla y reportar riesgos, pero el contrato no debe prometer el comportamiento permanente de un tercero.

Cuando el sistema emite CFDI, define quién valida reglas fiscales y quién autoriza cambios normativos. El SAT publica requisitos y catálogos oficiales para CFDI 4.0; consulta la información oficial del SAT y revisa cualquier interpretación con el área fiscal o un especialista.

Señales de alerta antes de firmar

• No hay anexo de alcance ni criterios de aceptación.
• El contrato no dice quién puede acceder al repositorio, datos y cuentas.
• La propiedad o licencia del código se resume en una frase ambigua.
• No se identifican componentes de terceros ni sus condiciones.
• Todo cambio se considera incluido sin procedimiento.
• El soporte no tiene horario, severidad, canal ni límites.
• No existe plan de transferencia al terminar.

Estas señales no prueban mala fe, pero sí justifican una revisión antes de iniciar. Corregir una ambigüedad en el contrato cuesta menos que descubrirla tras una entrega incompleta.

Cuando NO conviene firmar un precio cerrado

No conviene si el alcance depende de una integración no validada, si los datos todavía no están inventariados o si las reglas de negocio cambian cada semana. En ese caso considera una fase inicial con entregables de descubrimiento y una propuesta posterior para construcción.

Tampoco conviene aceptar una cesión amplia sin identificar qué materiales puede ceder legítimamente el proveedor y qué partes están sujetas a licencia de terceros. Es mejor separar el trabajo específico, los componentes preexistentes y las plataformas externas desde el inicio.

FAQ

¿El cliente siempre debe ser dueño de todo el código?

Depende del modelo y del tipo de componente. Lo esencial es que el contrato diga con precisión qué se cede, qué se licencia, qué es de terceros y qué necesitas para operar, modificar o transferir la solución.

¿Qué debe incluir la garantía?

Defectos respecto de criterios de aceptación definidos, periodo, exclusiones, canal, prioridad y forma de corrección. Las mejoras y cambios de alcance deben manejarse por separado.

¿Debo recibir acceso al repositorio desde el inicio?

Si el modelo acordado contempla entrega de código, acceso o un mecanismo verificable de transferencia por hitos reduce el riesgo de depender de una sola persona al final. Define el método en el contrato.

¿Qué pasa con licencias de terceros?

Identifícalas, determina quién las compra y administra, conserva sus términos y confirma qué ocurre si se cancela o cambia el proveedor. No asumas que son transferibles.

¿Este artículo reemplaza la revisión de un abogado?

No. Es una guía de preguntas técnicas y operativas. Para contrato, propiedad intelectual, datos y obligaciones en México, solicita revisión jurídica profesional.

Siguiente paso

SNAPGAD Technology puede ayudarte a convertir el alcance técnico en entregables y criterios de aceptación antes de cotizar. Agenda un diagnóstico sin costo de 30 minutos por WhatsApp al 221 407 8660 o en solicitar cotización. Revisa servicios de software, arquitectura de software a medida y automatización.