Traspaso del MVP antes de escalar: qué debería recibir el comprador
Un sprint de MVP no debería terminar con una demo vaga y una lista de ideas. Debería dejar al comprador software funcionando y contexto suficiente para decidir qué pasa después.
Eso importa aún más cuando el MVP incluye comportamiento de IA, APIs o lógica interna de flujo de trabajo. Sin un traspaso real, un MVP se convierte en una situación de rehén: las únicas personas que pueden ejecutar, cambiar o ampliar el software son las que lo construyeron. Un comprador que depende de ese arreglo está pagando por acceso, no por software.
El traspaso es parte del producto
Un buen traspaso ayuda al comprador a entender qué se construyó, qué sigue siendo un supuesto y qué riesgos quedan. También facilita el arranque del siguiente proveedor, del equipo interno o de la fase de bolsa mensual.
Un paquete de traspaso práctico debería incluir:
Términos de traspaso del repositorio o del código fuente
Notas de configuración y despliegue
Supuestos sobre datos y APIs
Limitaciones conocidas
Guion de la demo
Estado de los criterios de aceptación
Hoja de ruta recomendada con los siguientes pasos
Un checklist más completo que aguanta una auditoría:
Código e infraestructura
Repositorio Git con el historial completo, transferido a la organización del comprador o replicado el día de la aceptación.
Un `README.md` que cubra los requisitos previos, la instalación, las variables de entorno y el arranque local con un solo comando.
Un `.env.example` que nombre cada secreto necesario sin revelar valores.
Infraestructura como código o notas de despliegue paso a paso para el entorno de destino (Vercel, Fly, AWS, GCP, Azure u on-prem).
Un `CHANGELOG.md` que cubra los cambios destacables del sprint.
Datos e integraciones
Una lista de cada sistema externo que toca la app, con el método de autenticación, los scopes y la cuenta o service principal utilizados.
Un diccionario de datos breve para las tablas principales y los esquemas de entrada/salida de la IA.
Fixtures de ejemplo utilizables para el desarrollo local sin datos de producción.
Un plan de migración para cualquier script puntual o backfill de datos.
Operaciones
Un runbook para incidentes comunes: caída del modelo, fallo de integración, acumulación en la cola, rotación de secretos.
Los nombres y endpoints de los destinos de monitorización o logging.
Una lista de las programaciones cron, los topics de colas y los workers en segundo plano.
Un plan de "primeros 30 días" para el equipo de operaciones del comprador.
Gobernanza
Un checklist de criterios de aceptación con estado, pruebas y revisor.
Los riesgos pendientes y el responsable recomendado para cada uno.
Las versiones de modelo y prompt en uso, con una nota sobre cómo actualizarlas de forma segura.
La IA necesita claridad extra
Para las funcionalidades de IA, el traspaso también debería describir los supuestos del modelo, las fuentes de datos, los pasos de revisión, el comportamiento ante baja confianza y las vías de respaldo.
Una sección específica de traspaso de IA que merece la pena incluir:
Model card. Proveedor, nombre del modelo, versión del modelo fijada en producción, modelo de respaldo, coste esperado en tokens por llamada, latencia P50/P95.
Registro de prompts. Cada prompt versionado con un hash y un changelog legible. El traspaso documenta cómo actualizar un prompt sin cambiar el despliegue.
Conjunto de evaluación. 50-200 ejemplos etiquetados con las métricas que el equipo usa para juzgar regresiones. Sin un conjunto de evaluación, el siguiente cambio en el prompt o en el modelo es una apuesta a ciegas.
Política de confianza. Los umbrales en producción, quién los aprobó y cómo deberían revisarse.
Modos de fallo. Qué hace el sistema ante: timeout, JSON inválido, rechazo del modelo, baja confianza, fallo de validación. Cada uno con una ruta de código que el equipo del comprador pueda encontrar.
Sin esa claridad, puede que al comprador le guste la demo pero le cueste aprobar el uso en producción. La revisión de seguridad y cumplimiento se bloqueará con preguntas que el traspaso debería haber respondido de antemano.
La decisión después del MVP
El comprador debería poder decidir si robustecer, integrar, pausar o ampliar. Esa decisión es el verdadero resultado de un sprint de MVP enfocado.
Un documento de decisión útil al final del sprint, de una página:
Qué se construyó. Un párrafo, sin jerga.
Estado de los criterios de aceptación. Cumplido / parcial / no cumplido, con pruebas.
Qué funcionó mejor de lo esperado. Dos o tres puntos.
Qué sigue siendo incierto. Dos o tres puntos, cada uno con una mitigación propuesta.
Siguiente paso recomendado. Uno de {robustecer, integrar, pausar, ampliar}, con un alcance aproximado y un rango de precio.
Riesgos de no hacer nada. Específicos y honestos.
El software funcionando es solo la mitad del valor. La otra mitad es un camino claro hacia la siguiente inversión. El comprador debería salir de la demo final pudiendo decir, con sus propias palabras, qué hace el sistema, cuánto cuesta operarlo, qué podría salir mal y qué entregaría el siguiente sprint recomendado. Si no puede hacer las cuatro cosas, el traspaso está incompleto por bueno que sea el software.