Qué entregables debes exigir al construir tu MVP

La mayoría de contratos de desarrollo de MVP describen qué se va a construir y casi ninguno describe qué vas a recibir. Suena a matiz y no lo es: determina si el día que cambies de proveedor puedes seguir adelante o tienes que empezar de nuevo.

Esta es la lista de entregables que debe figurar por escrito antes de firmar, y por qué cada uno importa.

1. El código, en un repositorio que sea tuyo

No basta con que te lo entreguen al final comprimido en un archivo. El repositorio debe estar desde el primer día a nombre de tu empresa, con tu equipo como administrador y el proveedor como colaborador.

La diferencia es enorme: si la relación se rompe a mitad del proyecto, en el primer caso tienes el trabajo hecho hasta ese punto y su historial; en el segundo tienes una negociación incómoda.

Exige también el historial de commits. Dice mucho sobre cómo se trabajó y permite entender decisiones cuando entre otro equipo.

2. Cesión expresa de propiedad intelectual

Es el punto que más problemas causa después. Por defecto, en muchos ordenamientos el autor de una obra conserva derechos salvo cesión expresa. Si no lo has firmado, el código puede no ser de tu empresa aunque lo hayas pagado.

Debe cubrir a todos los que hayan tocado el proyecto, incluidos subcontratados y freelances del propio proveedor. Es exactamente lo que se revisa en una due diligence, y donde más operaciones se complican.

3. Todos los accesos, a tu nombre

Haz inventario y comprueba que la titularidad es tuya, no del proveedor:

• Dominio y DNS.
• Servidores e infraestructura en la nube.
• Base de datos.
• Cuentas de servicios de terceros: pagos, correo transaccional, almacenamiento, analítica.
• Tiendas de aplicaciones, si hay app móvil.
• Herramientas no-code utilizadas, con la cuenta a nombre de la empresa.

El patrón problemático es que el proveedor cree todo con sus cuentas «para agilizar». Agiliza al principio y te ata después: la factura del proveedor de infraestructura le llega a él, y tú no puedes ni entrar.

4. Documentación técnica mínima

No hace falta un manual de cien páginas. Sí hacen falta cuatro cosas:

• Cómo levantar el proyecto en un ordenador nuevo, paso a paso.
• Descripción de la arquitectura: qué piezas hay y cómo se comunican.
• Variables de entorno y secretos, gestionados de forma segura y documentados.
• Decisiones técnicas relevantes y por qué se tomaron.

Prueba objetiva de que la documentación sirve: que un desarrollador externo pueda poner el proyecto en marcha sin preguntar nada. Si no puede, no está terminada.

5. El modelo de datos

Esquema de la base de datos con las entidades, sus relaciones y qué significa cada campo. Es lo primero que necesita cualquiera que entre después, y lo que más se omite.

6. Procedimiento de despliegue

Cómo se sube una versión nueva a producción. Si solo lo sabe una persona del proveedor, tu producto depende de su disponibilidad. Debe estar escrito y, preferiblemente, automatizado.

7. Copias de seguridad y recuperación

Qué se respalda, con qué frecuencia, dónde se guarda y —lo que casi nadie comprueba— cómo se restaura. Una copia de seguridad que nunca se ha probado es una suposición, no una copia.

8. Plan de traspaso

Qué ocurre el último día: sesión de traspaso con tu equipo o con el siguiente proveedor, periodo de soporte posterior y forma de resolver dudas durante unas semanas.

Negocia esto al principio, cuando tienes capacidad de negociación, no al final.

Cómo redactarlo en el contrato

Una cláusula de entregables útil especifica, para cada punto: qué se entrega, en qué formato, en qué momento y qué criterio determina que está completo.

«Documentación técnica» no es un entregable. «Documento que permita a un tercero levantar el entorno de desarrollo sin asistencia» sí lo es, porque se puede verificar.

Señales de alarma al negociar

• Resistencia a poner el repositorio a tu nombre desde el principio.
• «La documentación la hacemos al final si queda tiempo.» No queda nunca.
• Accesos creados con cuentas del proveedor por defecto.
• Negativa a incluir cesión de propiedad intelectual de subcontratados.
• No se menciona qué pasa si el proyecto se interrumpe.

Ninguna de estas señales implica mala fe necesariamente. Muchos proveedores pequeños trabajan así por costumbre. Pero el coste de esa costumbre lo acabas pagando tú.

Qué comprobar antes de dar por cerrado el proyecto

Una prueba de aceptación sencilla y muy eficaz: pide a alguien ajeno al proyecto que, solo con lo entregado, levante el entorno y despliegue un cambio mínimo. Si lo consigue, los entregables están completos. Si no, falta algo, aunque el producto funcione perfectamente en producción.

Preguntas frecuentes

¿Esto encarece el presupuesto? Algo, normalmente poco. Y menos que reconstruir el proyecto porque nadie entiende cómo funciona.

¿Aplica igual con no-code? Sí, adaptado: cuentas a tu nombre, exportación de datos documentada y descripción de las automatizaciones configuradas.

¿Y si ya firmé sin esto? Se puede negociar después, sobre todo si hay trabajo futuro de por medio. Empieza por los accesos y la cesión de propiedad intelectual, que son los dos puntos críticos.

Conclusión

Un MVP no es solo el producto que funciona: es todo lo que necesitas para seguir adelante sin quien lo construyó. Si al terminar no puedes cambiar de proveedor sin empezar de cero, el proyecto está incompleto aunque la aplicación funcione.

Negocia los entregables antes de firmar. Después son un favor; antes son una cláusula.

¿Quieres revisar tu contrato de desarrollo antes de firmar? El diagnóstico inicial es gratuito y sin compromiso. Pedir diagnóstico gratis.