Un estudio, freelancer o empresa de desarrollo no vende solamente horas de programación. Puede vender una aplicación a la medida, una integración, capacidad mensual, mantenimiento o una auditoría técnica. Cada forma de trabajo necesita una respuesta distinta a la misma pregunta incómoda: ¿cuándo puede decir el cliente que falta entregar y cuándo puede decir el equipo que el encargo ya terminó?
El contrato de desarrollo de software debe describir la relación comercial. El alcance técnico debe describir el trabajo. Si ambos intentan resolverlo todo en un solo bloque, el documento envejece en cuanto cambia el backlog. Si ninguno fija responsables, pruebas y consecuencias, cada demo abre una negociación nueva.
Antes de cotizar, decide qué estás vendiendo
Un proyecto con alcance definido tiene una entrega reconocible. Puede dividirse en etapas, pero las partes esperan llegar a un resultado acordado. Una bolsa mensual compra capacidad durante un periodo: correcciones, evolutivos o sprints que se priorizan conforme avanza el producto. Una auditoría termina con hallazgos y recomendaciones, no con la obligación implícita de corregir todo lo observado.
Esta diferencia cambia la estimación, el pago, la aceptación y la salida. También cambia la conversación con el cliente. Si contrata capacidad recurrente, un backlog abierto puede ser razonable. Si compra un módulo por precio fijo, ese mismo backlog puede esconder trabajo que nadie presupuestó.
En México, la clasificación económica oficial incluye dentro de los servicios de diseño de sistemas de cómputo actividades como planeación, diseño, programación, integración e instalación de software. Ese universo es más amplio que "hacer una app". Por eso conviene nombrar la unidad de venta en lugar de dejar "servicios de tecnología" como objeto del contrato.
Antes de redactar, el proveedor puede escribir una frase que empiece con "el cliente compra". Si la frase requiere varios "y", probablemente hay más de un alcance. Desarrollo a la medida, integraciones, soporte y auditoría pueden convivir bajo una relación, pero no terminan de la misma manera.
El backlog no reemplaza el alcance
Un backlog sirve para ordenar trabajo. No siempre prueba qué compró el cliente, qué precio aceptó o quién puede agregar una historia. Tampoco distingue por sí solo una corrección de una función nueva.
Un alcance utilizable conecta cinco piezas que el equipo ya usa:
1. resultado o función que se va a construir; 2. insumos que debe entregar el cliente, como accesos, reglas de negocio o contenido; 3. dependencias que el proveedor no controla, incluidas APIs y servicios de terceros; 4. evidencia con la que se revisará la entrega; 5. responsable y plazo para aceptar, rechazar con observaciones o pedir un cambio.
La lista no obliga a congelar el proyecto. Obliga a registrar el movimiento. Si una historia nueva modifica precio o calendario, las partes necesitan una orden de cambio, un correo de aprobación o el mecanismo que hayan elegido. El punto es conservar quién pidió el cambio, qué impacto se estimó y quién lo autorizó antes de programarlo.
En un flujo ágil, el contrato puede mantener las reglas estables y dejar que los alcances, sprints u órdenes de cambio documenten el trabajo variable. "Trabajamos con Scrum" no contesta por sí mismo si el precio compra un resultado o capacidad, ni cuánto tiempo tiene el cliente para revisar una entrega.
Una demo no equivale a aceptación
Imagina que el equipo despliega el módulo de pagos en un ambiente de pruebas. El cliente responde que lo revisará con operaciones. Dos semanas después pide una regla distinta para reembolsos y sostiene que la entrega original sigue pendiente.
El problema no se resuelve escribiendo "a satisfacción del cliente". Esa frase deja la medida en manos de una parte. Conviene acordar qué se prueba, contra qué criterio, en qué ambiente, con qué datos y quién concentra observaciones. También hay que separar un defecto, una configuración incompleta, una dependencia externa y una nueva regla de negocio.
El equipo puede preparar una matriz breve por entrega:
| Entrega | Evidencia | Revisa | Respuesta esperada | Si hay observaciones |
|---|---|---|---|---|
| Integración de pago | Casos de prueba acordados | Responsable de producto | Acepta o identifica el caso fallido | El equipo reproduce y clasifica el hallazgo |
| Panel administrativo | Funciones del alcance en ambiente de pruebas | Usuario designado | Confirma o devuelve observaciones consolidadas | Se corrige defecto o se estima cambio |
| Repositorio y documentación | Acceso, versión y archivos enumerados | Responsable técnico | Confirma recepción | Se completa el faltante identificado |
Los criterios de aceptación no necesitan predecir cada error. Necesitan permitir que dos personas observen el mismo resultado y puedan clasificar lo que ven.
"Entregar el código" contiene varias decisiones
La Ley Federal del Derecho de Autor protege los programas de computación en código fuente y código objeto. La ley también regula facultades como reproducción, adaptación y distribución. Por eso acceso al repositorio, entrega de una copia y titularidad de derechos no son sinónimos.
Antes de prometer una cesión total o asumir que todo se conserva, conviene separar:
- código creado específicamente para el encargo;
- herramientas, librerías o componentes que el proveedor ya tenía;
- componentes de terceros y sus licencias;
- infraestructura, cuentas y credenciales;
- documentación necesaria para operar o continuar el proyecto;
- derecho del proveedor a reutilizar conocimiento general sin copiar información confidencial ni entregables cedidos.
Las licencias open source no tienen una sola consecuencia. La Open Source Initiative mantiene una definición y un catálogo de licencias aprobadas, pero cada licencia conserva condiciones propias sobre uso, modificación y distribución. El inventario de dependencias y sus licencias debe llegar a la revisión técnica y jurídica cuando el cliente exige exclusividad, redistribuirá el producto o impone restricciones sobre código abierto.
Hay un detonante que no conviene resolver con una frase copiada: propiedad compartida, pago con equity o escrow de código. En esos casos, el abogado necesita saber quién aporta qué, qué evento libera derechos o código, quién puede continuar el producto y qué documentación existe. La persona técnica debe llevar el mapa de repositorios, componentes previos, dependencias y accesos. Sin ese mapa, la redacción jurídica tendrá que adivinar la arquitectura.
La salida se diseña antes del último pago
Muchos proyectos mezclan en una sola promesa corrección de defectos, garantía, soporte y mantenimiento evolutivo. Esa mezcla deja una deuda sin límite. Un defecto puede significar que la entrega no cumple un criterio acordado. El soporte atiende incidencias bajo canales y prioridades. El mantenimiento evolutivo agrega o modifica capacidades. Cada trabajo necesita periodo, disponibilidad y forma de cobro.
La salida también debe asignar tareas. Al terminar, alguien entrega o transfiere repositorios, ambientes, llaves, cuentas, respaldos y documentación. Alguien revoca accesos. Las partes deciden qué soporte de transición está incluido y qué se cotiza aparte. Si el cliente depende de un servicio de terceros, el contrato no debe prometer que el proveedor controla su continuidad.
Los datos y accesos merecen un alcance propio cuando el equipo entra a producción, procesa información personal o administra credenciales. El responsable técnico puede aclarar ambientes, permisos, respaldos, registros y devolución. El abogado puede determinar qué obligaciones corresponden a cada parte y qué documento adicional requiere el tratamiento. Esa revisión necesita el diagrama real del flujo de datos, no sólo la palabra "privacidad".
Lleva el proyecto real a la conversación legal
We Law organiza esta contratación a partir de dos opciones visibles: proyecto con alcance definido por $7,900 MXN antes de IVA, o desarrollo recurrente y bolsa mensual por $9,900 MXN antes de IVA. La base incluye el contrato principal, un alcance técnico y reglas de código. Cada alcance adicional cuesta $1,500 MXN antes de IVA. Hay módulos para NDA previo, colaboradores, garantía/mantenimiento/SLA y datos, ambientes y accesos.
El configurador también detiene el precio automático cuando aparecen situaciones que necesitan diagnóstico, entre ellas equity, propiedad compartida, escrow, actividad regulada, datos sensibles, equipos internacionales, success fee, contrato impuesto por el cliente o restricciones críticas de open source. Una persona confirma la selección y el precio antes del pago; un abogado revisa las decisiones jurídicas.
Puedes llegar a esa revisión con cuatro materiales: la propuesta aceptada, el backlog o alcance vigente, un mapa de repositorios y dependencias, y la lista de personas que aprueban. No necesitas redactar cláusulas antes de entrar. Sí necesitas explicar qué construyes, cómo lo pruebas, qué cambia el precio y qué debe ocurrir cuando termina la relación.
Configura la forma de contratación y el alcance de tu proyecto de software.
Fuentes consultadas
- Ley Federal del Derecho de Autor, texto vigente, Cámara de Diputados.
- Código Civil Federal, texto vigente, Cámara de Diputados.
- Servicios de diseño de sistemas de cómputo y servicios relacionados, Data México, Secretaría de Economía.
- The Open Source Definition, Open Source Initiative.
Este artículo explica criterios para preparar una contratación. La aplicación de una norma, la titularidad del código, el tratamiento de datos o una estructura de coinversión dependen de los hechos y documentos del proyecto.