Cómo construiría un MVP - y cómo elijo de verdad la stack

Si mañana me pidieran construir un MVP, no abriría una tabla de 40 frameworks. No dibujaría un mapa de microservicios. No «blindaría el futuro» de un producto que nunca ha visto a un usuario de pago. Escribiría una frase: para quién es, qué trabajo hace, y qué mediremos en cuatro semanas. La stack llega después de esa frase - no antes.

La mayoría de los MVP fallidos no son demasiado pequeños. Son falsamente grandes: una «plataforma» a medias con auth, paneles, notificaciones y tres entornos - y nadie ha completado aún el único trabajo que probaría la idea. La tecnología suele ser la coartada. Este artículo es cómo lo entregaría de verdad.

1. Qué es un MVP - y qué me niego a llamar así

Un MVP no es «la versión 1 con menos pantallas». Es el experimento más barato que puede matar o reforzar la hipótesis más arriesgada. Si la hipótesis es «la gente pagará por reservar este servicio online», el MVP es un flujo de reserva más el pago más un humano al otro lado - no un CRM, no un programa de fidelidad, no una app nativa.

• Viable significa: un usuario real puede terminar un trabajo real. Un prototipo Figma clicable es investigación, no un MVP.
• Minimum significa: todo lo que no sirve a ese trabajo es un ticket para después - aunque parezca «fácil de añadir».
• Product significa: la semana que viene puede repetirlo sin heroicidad. Un Google Form más una hoja de cálculo puede ser un MVP. Reescribir la arquitectura de Netflix, no.

2. Cinco preguntas antes de que exista un repositorio

Los debates de stack son baratos. Las preguntas de producto sin respuesta son caras. No elijo Postgres frente a Mongo hasta poder responderlo en voz alta - con el fundador, no con un artículo.

• Quiénes son los diez primeros usuarios, con nombre si es posible - no «todo el mundo con un teléfono».
• ¿Cuál es el único trabajo para el que «contratan» el producto este mes? Uno. No una plataforma.
• ¿De dónde sale el dinero o la señal - cargo en tarjeta, contrato firmado, hueco reservado, lead cualificado?
• ¿Qué restricción es real: cuatro semanas, un desarrollador, un dominio regulado, un CRM existente, una audiencia de Telegram?
• ¿Qué nos haría parar? Si no podemos nombrar un criterio de corte, estamos construyendo un hobby, no un experimento.

3. Cinco filtros para elegir la tecnología

No elijo las herramientas porque estén de moda. Las elijo porque sobreviven al contacto con un desarrollador solo, un presupuesto pequeño y el primer usuario enfadado. Cada tecnología pasa estos filtros.

• Tiempo hasta el primer usuario de verdad. Si la stack añade una semana antes del primer clic, es la stack equivocada para un MVP. Las herramientas aburridas que ya entrego en producción ganan a una de moda que aprendería bajo deadline.
• Operable por una persona. Debo poder desplegar, leer logs, restaurar una copia y rotar una clave sin un equipo de plataforma. Kubernetes suspende este test para casi todos los productos tempranos.
• Contratable y reemplazable. TypeScript, Postgres y React no son excitantes. Son los lenguajes que otras personas buenas ya hablan. Un MVP que solo yo puedo extender es un rehén, no un activo.
• Dónde pesan los datos. La fuente de verdad va a una base de verdad con migraciones desde el día uno si hay usuarios y dinero. Las hojas de cálculo están bien para el experimento al lado del producto - no dentro del checkout.
• Salida de emergencia. Usaré un auth gestionado, un Postgres alojado, un proveedor de pagos. No firmaré un lock-in de cinco años cuyo export duela. Un proveedor está bien. Una trampa, no.

4. La stack web por defecto con la que empezaría en 2026

Para un MVP B2B o de servicio típico - reserva, captura de leads, un portal de cliente pequeño, una calculadora que se convierte en presupuesto - empezaría aquí. No porque esté de moda. Porque puedo entregar, hacer SEO, y aún contratar a alguien más en seis meses.

• Next.js + TypeScript + Tailwind: una app para páginas de marketing (SEO, render de servidor) y la UI de producto. Menos repos, un deploy, tipos compartidos. App Router vale si el equipo ya lo conoce; no reescribiré una app Pages que funciona «por pureza».
• Postgres (a menudo vía Supabase, Neon o un VPS pequeño): datos relacionales, transacciones, y SQL que puedo leer a las 2 de la madrugada. Cojo un almacén de documentos solo si la forma es de verdad documental - no porque «NoSQL es más rápido».
• Auth: un proveedor gestionado (Clerk, Auth.js + un IdP conocido, o Supabase Auth), salvo si el producto es el auth. Sesiones propias en la semana uno es cómo se filtran tokens y se frena la función de verdad.
• Pagos: Stripe (o el equivalente local que los primeros usuarios usan de verdad). Sin motor de facturación casero. Las facturas pueden esperar; un cargo que funcione, no.
• Hosting: Vercel para la app Next.js si el tráfico es «web» y el equipo quiere previews; Hetzner/VPS + Docker Compose si hace falta un worker largo, un coste previsible o residencia de datos. Ese equilibrio lo he escrito en otro sitio. Regla MVP: un entorno que entiende, copias de noche, HTTPS, un dominio.
• Email y archivos: Resend o una API transaccional similar; almacenamiento compatible S3. No «vamos a construir un módulo de adjuntos».

5. Cuándo dejo el valor por defecto

Un valor por defecto es una apuesta de salida, no una religión. Lo cambio cuando la restricción es el producto.

• El público ya vive en Telegram: un bot o una Mini App puede ser todo el MVP. Un sitio que no abrirán no es «más profesional». Es una segunda habitación vacía.
• El trabajo está en el campo con mala señal: miro local-first o una PWA, no una reescritura nativa en la semana uno. Native es una decisión de distribución, no una medalla.
• El núcleo es el lenguaje (soporte, presupuestos, extracción de documentos): añado una API LLM detrás de un esquema estricto y un paso de revisión humana. No envuelvo un widget de chat y lo llamo producto.
• El fundador es el operador y el contenido es el producto: un sitio rápido más un CMS que realmente usarán puede ganar a un admin a medida. WordPress sigue permitido si el trabajo es publicar, no construir una aplicación.
• Marketplace a dos caras: igual entrego un lado primero. Oferta o demanda - lo más difícil de conseguir. Una «plataforma» con sillas vacías a ambos lados es una landing con tablas de más.

6. Lo que me niego a añadir antes de los primeros usuarios

La forma más rápida de fallar el experimento es construir la empresa alrededor del experimento. Esta lista se queda al lado del backlog.

• Microservicios, bus de mensajes y Kubernetes. Un proceso, una base, un deploy. Se parte cuando aparece un cuello de botella de verdad o una frontera de equipo de verdad - no cuando un diagrama parece senior.
• Un design system con 80 tokens y cero pantallas. Entregar las tres pantallas que recogen el dinero. Extraer componentes cuando el tercer copy-paste duele.
• Roles, permisos, registros de auditoría y SSO - salvo si un comprador B2B de pago bloqueó el trato en ello. Entonces son el MVP, no una misión secundaria.
• Una segunda app móvil. La web responsive o una Mini App cubre los cien primeros usuarios en la mayoría de negocios de servicio que veo.
• Cobertura de tests perfecta del código pegamento. Quiero tests sobre el dinero, el auth y el trabajo central. No una semana de mocks para un formulario de landing.

7. Cómo se verían de verdad las primeras cuatro semanas

Trato el calendario como una decisión de producto. Si no podemos describir las semanas, no tenemos un plan - tenemos un deseo.

• Semana 0 (dos días, no dos semanas): la página única. Usuario, trabajo, criterio de corte, lo que no se hace. Esbozar las tres pantallas. Acordar qué es «hecho»: un desconocido puede terminar el trabajo sin nuestro Zoom.
• Semana 1: corte vertical. Dominio, deploy, base, layout vacío, un camino feliz en producción (aunque feo). Si no podemos desplegar el día tres, la stack ya miente.
• Semana 2: el trabajo. Reserva, presupuesto, subida, pago - lo que nombramos en la semana 0. Las operaciones manuales detrás de la UI están permitidas: un ping de Telegram al dueño es una función si cierra el ciclo.
• Semana 3: los bordes feos. Estados vacíos, errores, móvil, emails, analytics básicas (dónde se caen). No un almacén de datos. Un embudo que se pueda leer.
• Semana 4: ponerlo delante de las diez personas con nombre. Mirar. No añadir una función durante las llamadas. Anotar lo que hicieron, no lo que decían querer.

8. Después del lanzamiento: guardar, extraer o reescribir

Un buen MVP tiene derecho a ser un poco incómodo. No tiene derecho a ser una trampa. La stack de arriba es aburrida a propósito: se puede crecer dentro. Rara vez hay que salir de ella el primer año.

• Guardar: el lenguaje, la base, los nombres de dominio en el código. Barato de convivir, caro de tirar.
• Extraer: un worker, un segundo servicio, una cola de verdad - cuando una tarea es lenta, peligrosa o pertenece a otro equipo. No antes.
• Reescribir solo la parte que aprendió la lección equivocada. Checkout mal - reescribir el checkout. Toda la app es un laberinto vibe-coded: primero es un problema de personas. Alguien tiene que poder explicarlo a las 2 de la madrugada.

Conclusión: elija la stack que sobrevive al primer no

Construiría un MVP sin glamour: un trabajo, una base, un deploy, herramientas que puedo operar sola, y una fecha en la que decidimos seguir o parar. La «mejor» tecnología es la que no nos distrae de esa decisión. Next.js, TypeScript, Postgres, un auth gestionado y un proveedor de pagos no son una personalidad. Son una forma de gastar las semanas escasas en el producto, no en la plataforma.

Si tiene una idea, un plazo y el miedo de elegir la «stack equivocada» - escriba por la sección de contactos. Podemos acotar el único trabajo, nombrar lo que no se hace, y entregar un corte que pueda poner delante de gente de verdad sin construir primero una plataforma falsa.