Web SaaS Startup: MVP en 4 Semanas

Por qué un MVP funcional gana siempre al prototipo Figma

Un prototipo Figma es una ilusión. Funciona perfecto porque está diseñado para funcionar perfecto: no hay errores de red, no hay estados vacíos, no hay usuarios que hacen clic donde no deben. Lo que validas con Figma es si tu idea parece buena, no si alguien la usa de verdad.

Un MVP funcional te da señales de comportamiento real: ¿el usuario completa el onboarding? ¿Vuelve al día siguiente? ¿Introduce datos falsos o datos suyos? ¿Abandona en el formulario de pago o después?

La diferencia no es estética. Es que con código real puedes cobrar. Y el momento en que alguien introduce su tarjeta de crédito — aunque sea 9€/mes — valida más que cien entrevistas de usuario.

Además, un MVP bien construido no es código desechable. Si eliges el stack adecuado (ver sección siguiente), el 60-70% de lo que construyes en las primeras 4 semanas sobrevive al producto en producción. No estás tirando trabajo, estás comprando información de forma eficiente.

• Figma: feedback sobre UI, no sobre comportamiento
• MVP funcional: datos reales de activación, retención y conversión a pago
• No-code (Bubble, Webflow): rápido pero con techo bajo — lo detallamos más adelante

El stack SaaS 2026: Next.js + TypeScript + Supabase + Stripe + Vercel

Este no es el stack de moda. Es el stack que ha demostrado en los últimos tres años que lleva MVPs a producción sin reescrituras masivas. Si no tienes claro aún qué es exactamente un SaaS, lee primero nuestra guía completa sobre SaaS. Cada pieza tiene un motivo concreto:

Next.js 15 + TypeScript

Full-stack en un solo repositorio. App Router con React Server Components reduce el JavaScript que llega al cliente. TypeScript elimina una categoría entera de bugs en producción — los de tipo — que en un MVP te pueden costar una semana de debugging justo cuando necesitas iterar rápido.

Supabase

Postgres gestionado + Auth + Storage + Realtime en uno. No tienes que montar infraestructura de base de datos, gestionar certificados SSL ni configurar roles. La autenticación (email, Google, GitHub, magic link) sale en un día. Los Row-Level Security policies te dan multitenancy seguro desde el primer sprint. Y si el día de mañana necesitas migrar a otro Postgres, tienes SQL estándar — nada propietario.

Stripe

No hay alternativa seria para cobros SaaS. Subscriptions, usage-based billing, trials, upgrades, downgrades, webhooks para activar/desactivar features según plan. El dashboard de Stripe es además tu primer CRM de ingresos: MRR, churn, LTV por cohorte.

Vercel

Deploy en 30 segundos, preview URLs por branch, edge functions globales, analytics integrados. Para un MVP en validación, que cada PR genere una URL de preview que puedes enviar a un beta user no tiene precio.

Este stack lo usan internamente equipos de software B2B que facturan millones. No es sobredimensionado para un MVP: es el suelo mínimo que te permite escalar sin reescribir.

Las 4 semanas: qué construimos cada sprint

Un MVP SaaS tiene cuatro bloques indivisibles. Si falta uno, el producto no puede validarse con usuarios reales que paguen. Este es el desglose sprint a sprint:

Semana 1 — Auth + DB + esqueleto

Registro, login, recuperación de contraseña. Modelo de datos inicial en Supabase (usuarios, organizaciones si es B2B, la entidad core del producto). Dashboard vacío funcional. Row-Level Security configurado desde el día 1, no como refactor posterior. Dominio apuntado, SSL, variables de entorno en Vercel. Al final de la semana tienes algo que un usuario puede tocar sin que explote.

Semana 2 — Features core

La feature principal que justifica el producto. Solo una, completa y usable. No tres a medias. Aquí se concentra el 50% del esfuerzo total del MVP. CRUD completo de la entidad principal, lógica de negocio, estados vacíos, errores controlados. También: onboarding de 2-3 pasos para que el usuario entienda qué hacer al entrar.

Semana 3 — Pagos + planes

Integración Stripe Checkout o Stripe Elements. Tabla de precios funcional (Free + al menos un plan de pago). Webhooks que activan/desactivan features según plan. Customer portal para que el usuario gestione su suscripción sin contactarte. Emails transaccionales básicos: bienvenida, confirmación de pago, cancelación.

Semana 4 — Polish + métricas + lanzamiento

Corrección de bugs encontrados en beta interna. Integración de una herramienta de analytics (PostHog o Mixpanel). Landing page de captación si no existía. Performance: Core Web Vitals en verde. SEO básico (meta tags, OG). Deploy en dominio definitivo. Comunicación a primeros beta users.

Lo que no está en estas 4 semanas: internacionalización completa, app móvil, integraciones con terceros, admin panel avanzado, reportes complejos. Eso es la v2, si los números lo justifican.

Landing primero o producto primero: la respuesta honesta

Depende de si ya tienes una hipótesis de demanda o todavía la estás buscando.

Landing primero tiene sentido si puedes describir el problema y la solución en una frase, tienes acceso a un canal (comunidad, newsletter, LinkedIn) donde anunciarlo, y quieres validar si la gente hace clic en «Empezar prueba gratuita» antes de construir nada. El riesgo: la gente hace clic en cosas gratis sin intención de pagar. Un waitlist no es validación de negocio.

Producto primero tiene sentido si ya tienes conversaciones con potenciales usuarios que han dicho explícitamente «pagaría por esto», si el problema es técnicamente no trivial (y la landing no transmite el valor sin ver el producto), o si tu canal de adquisición es product-led (el producto se comparte solo).

Lo que recomendamos en la práctica: construir ambos en paralelo durante la semana 1. La landing es un día de trabajo con el stack correcto. No tiene que ser perfecta; tiene que capturar emails y comunicar la propuesta de valor. El producto tarda más, pero no son excluyentes.

Lo que nunca funciona: la landing ultra-pulida con 12 secciones animadas antes de tener una sola línea de producto. Es procrastinación disfrazada de marketing.

Las 3 métricas que importan en un MVP SaaS

Con usuarios reales sobre el producto, la mayoría de founders mira las métricas equivocadas. Visitas, registros totales y «me han dicho que mola» no son señales de un negocio viable. Estas tres sí lo son:

1. Activación

Porcentaje de usuarios que completan el «momento aha» — la acción que hace que el usuario entienda el valor del producto. En un gestor de facturas, puede ser «crear y enviar la primera factura». En un tool de analytics, «ver los primeros datos propios». Define tu evento de activación antes de lanzar, no después. Benchmark aceptable para MVP: 30-40%. Por encima de 50%, estás haciendo algo muy bien.

2. Retención D7/D30

¿Cuántos usuarios vuelven al día 7 y al día 30? Esta es la señal más fuerte de product-market fit temprano. Si la retención D30 cae por debajo del 10% en un SaaS de uso frecuente, el problema no es marketing — es el producto. No hay presupuesto de adquisición que arregle una retención rota. Benchmark: D7 >25%, D30 >10% para empezar a hablar de escala.

3. Conversión Free → Paid

Si tienes freemium, ¿qué porcentaje convierte a plan de pago? Para SaaS B2B, entre 2-5% es normal con un funnel sin optimizar. Para B2C, 1-3%. Por debajo de eso, o el pricing es alto, o las features del plan gratuito son demasiado generosas, o el producto no genera suficiente urgencia.

PostHog te da las tres métricas desde el primer día con eventos personalizados, sin necesitar un data engineer. Lo configuramos en la semana 4 de cada MVP.

Pricing inicial: free tier, paid y cómo no suicidarte con el freemium

El error más común en startups SaaS: lanzar con «gratis para siempre» sin un plan de pago claro, porque «primero necesitamos tracción». El resultado: usuarios que no pagan, infraestructura que costea el founder, y una conversación de pricing incómoda seis meses después.

La estructura que mejor funciona para un MVP en validación:

• Free: funcional pero limitado. Un límite real que el usuario sienta: 5 proyectos, 100 registros, 1 usuario, 30 días de histórico. No features amputadas que hacen el producto inútil — eso genera frustración, no conversión.
• Paid (plan único al inicio): entre 19€ y 79€/mes dependiendo del valor percibido y el segmento. Un solo plan elimina la parálisis de elección. Cuando tengas datos de quién paga más y por qué, introduces tiers.

Regla de oro: el precio inicial es una hipótesis. Ponlo demasiado bajo y la señal que recibes es ruido (la gente paga 5€ por casi cualquier cosa). Ponlo razonable desde el primer día y los que pagan te dan información de calidad.

Para SaaS B2B con decisión de compra en equipo (más de 1 seat): añade un plan Team desde el inicio con billing por usuario o por organización. Stripe lo gestiona con un webhook sencillo.

Lo que no te recomendamos en un MVP: trials de 14 días con tarjeta requerida (aumenta fricción en validación temprana), descuentos anuales agresivos (distorsionan la señal de retención), usage-based pricing complejo (añade ingeniería que no necesitas en semana 3).

Cómo recoger feedback de usuarios que realmente cambia el producto

Los founders que hacen MVPs bien tienen un proceso de feedback sistemático, no ad hoc. Lo que funciona en la práctica con 10-50 usuarios iniciales:

Entrevistas 1:1 en las primeras 2 semanas de beta

No encuestas. Llamadas de 20-30 minutos con usuarios que completaron el onboarding. La pregunta que más información da no es «¿qué mejorarías?» sino «cuéntame la última vez que intentaste resolver este problema sin nuestro producto». Eso te revela el job-to-be-done real y los workarounds que compites contra.

Session recordings con PostHog o FullStory

Ver dónde el cursor se queda quieto, dónde el usuario hace clic en algo que no es clickable, dónde abandona. Vale más que cualquier encuesta. Configúralo en la semana 4 del MVP, antes de abrir a beta.

In-app feedback con contexto

Un widget de feedback (Canny, Upvoty, o simplemente un botón que abre un form de Typeform) anclado al contexto: «Estás en la pantalla de reportes — ¿qué te falta aquí?». Más accionable que un formulario de contacto genérico.

Churn surveys automáticos

Cuando un usuario cancela su plan, Stripe dispara un webhook. Ese webhook envía un email con tres opciones de razón. Saber por qué se van es tan valioso como saber por qué se quedan.

Procesa el feedback en ciclos semanales. No cada vez que llega un mensaje. La dispersión mata el foco en un MVP.

Cuándo escalar la arquitectura (y cuándo no tocar nada)

La peor decisión técnica en una startup es optimizar antes de tener señal de negocio. Hemos visto founders reescribir su arquitectura dos veces antes de tener 50 usuarios de pago. Es un error caro y evitable.

Estos son los umbrales reales donde la arquitectura del MVP empieza a limitar:

• 500+ usuarios activos diarios: Supabase Free Tier empieza a tener latencias. Migra a Supabase Pro (25$/mes) o considera un Postgres dedicado en Railway/Fly.io.
• Queries lentas en tablas >100K filas: Es el momento de añadir índices, no de cambiar de base de datos. Postgres con índices bien puestos aguanta decenas de millones de filas sin drama.
• Jobs en background frecuentes (emails, cálculos, webhooks): Extrae a una queue. Trigger.dev o Inngest se integran en Next.js en un día y son gratuitos hasta volumen considerable.
• Múltiples microservicios por «buenas prácticas»: No antes de 10.000 usuarios activos. Un monolito bien estructurado en Next.js aguanta muchísimo más de lo que la mayoría de founders cree.

La señal para escalar arquitectura no es el número de usuarios — es el dolor concreto que ese número genera: errores en producción, tiempos de respuesta >2s, o features que no puedes implementar por limitaciones del stack actual.

Si todavía no tienes product-market fit, el tiempo que gastas en arquitectura es tiempo que no gastas en hablar con usuarios. La arquitectura perfecta de un producto que nadie usa vale cero.

Casos reales: MVPs SaaS que validaron (y los que no)

Sin nombres de clientes por NDA, pero los patrones son los mismos en todos los MVPs que hemos entregado:

Caso A — Tool de onboarding B2B (4 semanas, 2.800€)

Founder con experiencia en HR tech quería automatizar el onboarding de nuevos empleados. MVP con auth, template editor básico, envío de tasks por email y dashboard de progreso. Lanzó a 8 empresas conocidas. Resultado semana 6: 3 de 8 pagaban 49€/mes, D30 retention del 38%, NPS +52. Señal suficiente para levantar una ronda pre-seed. La arquitectura del MVP sobrevivió hasta los primeros 200 clientes.

Caso B — Marketplace de servicios freelance (6 semanas, 4.200€)

Dos founders querían un Fiverr vertical para un nicho concreto. MVP con registro doble (cliente/proveedor), listado de servicios, chat básico y Stripe Connect para pagos. Resultado: bajo GMV, retención D7 del 8%. El feedback revelaba que el problema real no era la plataforma sino la confianza entre partes. Pivotaron a un modelo de agencia curada — sin reescribir el MVP, solo cambiando el modelo de negocio. La infraestructura aguantó el pivote.

Caso C — SaaS de gestión de contratos para PYMEs

Aquí el MVP nunca llegó a validarse porque el founder insistió en añadir firma digital nativa, integración con DocuSign y un generador de contratos con IA antes de lanzar. Tres meses de desarrollo, 8.000€, y al lanzar descubrió que sus clientes objetivo usaban contratos en PDF por WhatsApp y no veían el valor en digitalizar. La lección: cuanto más tardas en llegar al mercado, más cara es la hipótesis equivocada.

El patrón común en los MVPs que avanzan: el founder había hablado con al menos 10 clientes potenciales antes de escribir la primera línea de código, tenía una métrica de éxito clara antes de lanzar, y resistió la tentación de añadir features durante el desarrollo inicial.

¿No-code (Bubble, Webflow, Glide) o código real? La respuesta depende de tu techo

El no-code es una herramienta válida para validar hipótesis muy rápido — en días, no semanas. Si tu MVP puede construirse en Bubble en 3 días y necesitas señal en 2 semanas, tiene sentido. El problema no es el inicio, es el techo.

Bubble y plataformas similares tienen limitaciones estructurales que se vuelven críticas en cuanto el producto escala:

• Performance: Bubble genera queries ineficientes que se vuelven lentas con >10K registros. No tienes control sobre los índices.
• Vendor lock-in total: Tu base de datos, tu lógica de negocio y tu UI viven en la plataforma de un tercero. Si Bubble sube precios o cierra, tienes un problema existencial.
• Integraciones complejas: Webhooks bidireccionales, lógica condicional compleja en background jobs, integraciones con APIs que no tienen plugin oficial — todo se vuelve un workaround.
• Costes a escala: Bubble Pro cuesta 349$/mes. Con el stack que usamos nosotros, ese budget cubre infraestructura para decenas de miles de usuarios.

Nuestra recomendación: si tu equipo técnico no existe todavía y necesitas validar en menos de 2 semanas, empieza en no-code. Pero planifica la reescritura desde el día 1, no como sorpresa. Si tienes 4 semanas y presupuesto desde 2.500€, el MVP en código real es la opción que te deja escalar sin techo y con propiedad total del producto.

Para webs de captación (landing page, waitlist) sin lógica de producto — Webflow es perfectamente válido. El problema llega cuando intentas construir producto con herramientas diseñadas para marketing.

Más sobre nuestro enfoque de desarrollo SaaS en Barcelona y software B2B a medida.