Cómo construir un MVP que siga funcionando en el noveno mes

Para construir un MVP que siga funcionando en el noveno mes, decida cinco cosas antes de la primera pantalla: el modelo de datos, las cuentas y los roles, los pagos, la región de alojamiento y el proceso de publicación. Después recorte la primera versión a un usuario, una tarea y un recorrido, lánzela mediante un proceso automatizado y deje por escrito cada decisión importante a medida que la toma. Todo lo demás, desde los paneles de administración hasta los microservicios, puede esperar.

El motivo es el noveno mes. Para entonces tiene usuarios reales, un segundo ingeniero y una hoja de ruta, y cada atajo del primer mes marca el ritmo del décimo. Esta guía trata las decisiones que son caras de revertir, cómo elegir quién construye, lo básico del RGPD, un plan de cuatro semanas, la definición del alcance y el traspaso.

#Un MVP no es un prototipo

Eric Ries definió el producto mínimo viable como la versión de un producto nuevo que permite a un equipo obtener la máxima cantidad de aprendizaje validado sobre los clientes con el mínimo esfuerzo. Aprender de clientes reales significa cuentas reales, datos reales y, tarde o temprano, dinero real.

Un prototipo responde a «¿podría funcionar esto?» y está pensado para tirarse: un diseño interactivo, una demo para el día del pitch, un script en un portátil. Un MVP responde a «¿lo usará y pagará la gente?», y las personas que responden dejan sus datos en él. Eso no se puede tirar.

El problema empieza cuando un prototipo pasa a producción sin que nadie haya decidido que pase. Las pantallas, las reglas de negocio y las consultas a la base de datos acaban en los mismos archivos, el inicio de sesión y los pagos se añaden tarde y los despliegues se hacen desde el ordenador de una persona. En el segundo mes nada parece ir mal. En el noveno, cada funcionalidad cuesta más de lo que debería.

Martin Fowler describe ese sobrecoste como los intereses de la deuda técnica: el esfuerzo adicional que cuesta añadir nuevas funcionalidades por las deficiencias de calidad interna. Algo de deuda es un intercambio justo a cambio de velocidad. El objetivo de una primera versión es endeudarse a propósito, en lugares donde sea barato pagarla, y nunca en los cimientos.

#Cinco decisiones para la primera semana

La primera semana es para decisiones sobre el papel, no para pantallas. Acertar con cada una de estas cinco es barato antes de la primera línea de código de producto y caro de cambiar cuando los usuarios ya dependen de ella.

1. El modelo de datos

Anote las entidades principales, cómo se relacionan y a quién pertenece cada registro. En la mayoría de los productos B2B la pregunta decisiva es la multitenencia: ¿tiene cada organización cliente su propio espacio, y lleva cada tabla relevante una referencia a la organización desde el primer día? Añadir multitenencia a posteriori a un esquema de un solo cliente afecta a cada consulta que haya escrito. Mantenga el esquema en migraciones versionadas, nunca en cambios manuales sobre la base de datos en producción.

2. Cuentas, roles y permisos

Decida cómo inician sesión las personas, cómo se relacionan los usuarios con las organizaciones y qué roles existen. Para empezar bastan dos o tres roles, pero deben comprobarse en un solo lugar en el servidor, no repartidos por las pantallas como condicionales. Utilice un proveedor o una biblioteca de autenticación consolidados en lugar de programar usted mismo la gestión de contraseñas, y deje espacio para el inicio de sesión único, porque su primer cliente corporativo lo pedirá.

3. Pagos

Aunque no cobre nada en el lanzamiento, decida quién paga (una persona o una organización), por qué paga (puestos, uso o una tarifa plana) y dónde reside el estado de la suscripción. Utilice el pago alojado o integrado de un proveedor de pagos para que los datos de las tarjetas nunca toquen sus servidores. Stripe, por ejemplo, explica que sus integraciones de bajo riesgo envían los datos de pago directamente a Stripe y reducen sus obligaciones PCI DSS.

4. La región de alojamiento

Elija la región de su base de datos, sus copias de seguridad, sus registros y su almacenamiento de archivos, y compruebe la región de cada proveedor que trate datos personales. Para un producto que se vende en Alemania, Austria y Suiza, una región de la UE es la opción razonable por defecto. No elimina sus obligaciones del RGPD, pero quita la cuestión de las transferencias internacionales de la mayoría de los cuestionarios de seguridad de clientes que recibirá.

5. El proceso de publicación

Desde el primer commit, cada cambio pasa por el control de versiones, las pruebas automatizadas y un despliegue automatizado, primero a staging y después a producción. Nadie despliega desde un portátil. Montar un proceso así es aburrido en la primera semana y muy difícil de introducir en el noveno mes, cuando el equipo se ha acostumbrado a publicar a mano y cada versión se hace conteniendo la respiración.

Qué dejar fuera a propósito

• Microservicios. Una sola aplicación bien estructurada, con capas internas claras (interfaz, reglas de negocio, datos), es más fácil de cambiar y de operar para un equipo pequeño.
• Un panel de administración a medida. Utilice un cliente de base de datos o una herramienta interna sencilla hasta que el trabajo de soporte muestre lo que realmente necesitan los administradores.
• Apps nativas para ambas plataformas, salvo que el producto necesite funciones del dispositivo. Una app web adaptable suele bastar para aprender.
• Más idiomas de los que necesita su primer mercado, aunque conviene guardar textos, fechas y monedas de forma que los permita más adelante.
• Infraestructura propia como su propio sistema de analítica, su servicio de feature flags o su sistema de diseño.
• Casos límite para clientes que aún no tiene.

#Qué decisiones son caras de revertir

En su carta a los accionistas de 2015, Jeff Bezos dividió las decisiones en puertas de un solo sentido y de doble sentido: las trascendentes y casi irreversibles, que merecen cuidado, y las reversibles, que un grupo pequeño debería tomar con rapidez. La mayoría de las decisiones de una startup son puertas de doble sentido. La habilidad consiste en detectar las pocas que no lo son y no dejar que las reversibles se coman la primera semana.

Fíjese en lo que queda del lado caro: los datos, la identidad, el dinero y el lugar donde residen. Esas son las decisiones que hay que acordar por escrito en la primera semana. El resto puede tomarlas quien esté construyendo, en el momento, y cambiarlas cuando sepa más.

#No-code, agencia, freelances o equipo propio

La forma adecuada de construir depende menos del presupuesto que de dos preguntas: quién será dueño del código y lo entenderá en el noveno mes, y qué parte de su producto es el propio software. Si es fundador y busca quién le desarrolle una app (en Alemania, «App entwickeln lassen»), haga esas dos preguntas a cada proveedor antes de comparar ofertas.

Elija lo que elija, el contrato debe establecer que el código, los repositorios, las cuentas en la nube y los dominios pertenecen a su empresa desde el principio, y que la documentación es un entregable, no un favor.

#Lo básico del RGPD desde el primer día

El RGPD exige protección de datos desde el diseño y por defecto (artículo 25). En una primera versión eso se reduce a cuatro cuestiones prácticas. Se trata de información general: si trata datos de salud, financieros o de menores, o algo fuera de lo común, consulte a un abogado especializado en protección de datos antes del lanzamiento.

Región de alojamiento y transferencias internacionales

El RGPD no exige que los datos permanezcan en la UE. Exige una base jurídica conforme al capítulo V para cualquier transferencia fuera del EEE, como una decisión de adecuación o unas cláusulas contractuales tipo. Para proveedores estadounidenses, el Marco de Privacidad de Datos UE-EE. UU. cubre las transferencias a empresas certificadas en él. El Tribunal General confirmó el marco en septiembre de 2025, pero hay un recurso de casación pendiente ante el Tribunal de Justicia (asunto C-703/25 P). Mantener los datos principales en una región de la UE y conocer la base de transferencia de cada proveedor limita su exposición, se resuelva como se resuelva.

Un contrato de encargo con cada encargado

Cada proveedor que trata datos personales por cuenta suya, del alojamiento al envío de correos y el seguimiento de errores, necesita un contrato de encargo del tratamiento conforme al artículo 28. En Alemania se llama Auftragsverarbeitungsvertrag (AVV), y sus clientes B2B también le pedirán uno. Mantenga una lista de proveedores con los datos que recibe cada uno, dónde se almacenan y cuándo firmó el contrato. Esa lista es también el punto de partida de su registro de actividades de tratamiento conforme al artículo 30, cuya exención para organizaciones de menos de 250 personas deja de aplicarse en cuanto el tratamiento no es ocasional.

El consentimiento, y cuándo no lo necesita

Muchas primeras versiones recogen consentimientos que no necesitan y se olvidan de los que sí. Los datos que necesita para prestar el servicio conforme a su contrato no requieren consentimiento. Las cookies no esenciales y accesos similares al dispositivo del usuario sí: en Alemania, el § 25 TDDDG exige consentimiento salvo que el acceso sea estrictamente necesario para un servicio que el usuario ha solicitado. Cuando se base en el consentimiento, registre qué se aceptó y cuándo, porque el artículo 7 le obliga a demostrarlo y exige que retirarlo sea tan fácil como darlo.

Una supresión que de verdad suprime

El artículo 17 reconoce a las personas el derecho de supresión, y el artículo 19 le obliga a comunicarlo a los destinatarios con los que compartió sus datos. Diseñe la supresión en la primera semana: qué registros se suprimen, cuáles se anonimizan o se conservan porque la ley le obliga a guardarlos (las facturas, por ejemplo), cómo llega la supresión a los encargados y a las copias de seguridad, y quién puede activarla. Un indicador de borrado lógico en la tabla de usuarios no es un proceso de supresión.

#Un plan semana a semana para las cuatro primeras semanas

Este plan supone un producto de alcance muy acotado y un equipo sénior pequeño. Un alcance mayor lleva más tiempo, pero el orden es el mismo: decisiones, después el esqueleto y después la primera versión.

A partir de ahí, publique a un ritmo fijo, semanal es una buena opción por defecto, con una revisión breve que decide qué sale a continuación. Un ritmo constante importa más que el tamaño de cada versión.

#Cómo definir el alcance de la primera versión

Defina la primera versión en torno a un usuario, una tarea y un recorrido. Escríbala en una sola frase: «La responsable de una clínica puede invitar a su equipo y ver las citas de esta semana en un solo lugar». Todo lo que no sirva a esa frase va a la lista de recortes. Guarde la lista, porque se convierte en su hoja de ruta.

1. Nombre con precisión al primer usuario: su rol, el tipo de empresa y lo que utiliza hoy.
2. Enumere los pasos de esa tarea desde la primera visita hasta el resultado, y elimine cada paso que no sea imprescindible.
3. Marque los pasos que tocan las decisiones caras (datos, roles, dinero). Constrúyalos bien; el resto puede ser sencillo.
4. Elija una o dos señales que le indiquen que ha funcionado, como la activación o una acción repetida, y mida solo esas.
5. Fije una fecha y recorte el alcance para cumplirla, en lugar de mover la fecha.

Una buena primera versión le parece pequeña al fundador y completa al primer usuario. Si su lista de imprescindibles ocupa una página, está describiendo la versión tres.

#Cómo es un traspaso como es debido

La prueba de un traspaso es sencilla: ¿puede un ingeniero que no estuvo en la sala desplegar, depurar y ampliar el producto sin llamar a quien lo construyó?

Los registros de decisiones son la parte más infravalorada. El formato de registro de decisiones de arquitectura de Michael Nygard recoge cada decisión importante en un archivo breve con su contexto, la decisión, su estado y sus consecuencias. En el noveno mes, cuando el segundo ingeniero pregunte por qué la multitenencia funciona como funciona, la respuesta está en el repositorio y no en la memoria de alguien.

Las cuentas son la otra trampa, y algunas llevan tiempo. Apple exige que una organización se inscriba como persona jurídica con un número D-U-N-S, y Google Play no crea una cuenta de desarrollador de organización sin él; la solicitud gratuita puede tardar hasta 30 días. Empiece pronto, a nombre de la empresa, nunca al de un freelance o una agencia.

#Cómo podemos ayudarle

Bespoke IT construye primeras versiones para startups de Alemania, Austria y Suiza con el calendario descrito aquí: arquitectura en la primera semana, un producto funcional en la tercera y un traspaso que su primer ingeniero contratado puede gestionar sin nosotros. Si está planificando una primera versión, o ya tiene una que parece estar en su noveno mes, vea cómo trabajamos con startups.