La mayoría de "casos de éxito" que se publican son storytelling con cifras maquilladas. Este artículo no va por ahí. Vamos a contar un caso real de un fundador sevillano, con las decisiones que tomamos, los errores que cometimos y las métricas que salieron.

Por confidencialidad cambiamos nombre y sector concreto, pero todo lo demás (decisiones, plazos, cifras, conversaciones) es real. Si estás pensando en lanzar algo desde Andalucía, este caso te va a sonar.

El punto de partida

El fundador — al que llamaremos Javier — vino a vernos en enero. Llevaba 8 meses dándole vueltas a una idea: una herramienta SaaS para profesionales de un sector regulado en España. El problema que detectaba era claro, lo había vivido como cliente, y tenía tres validaciones cualitativas con potenciales usuarios.

Lo que tenía:

  • Una idea clara y un sector que conocía bien.
  • 3 entrevistas con potenciales clientes (conversaciones de 1 hora cada una).
  • Un presupuesto de 8.000 € para construir el MVP.
  • Cero código escrito y sin equipo técnico propio.

Lo que no tenía:

  • Diseño UX, ni siquiera bocetos.
  • Lista de espera ni señales cuantitativas de demanda.
  • Un modelo de precio cerrado.
  • Tiempo: quería lanzar antes de un evento sectorial en abril.

Discovery: la decisión más importante del proyecto

Hicimos dos sesiones de Discovery (4 horas en total) en febrero. El objetivo era recortar la idea original hasta el núcleo mínimo que validara la hipótesis principal: "los profesionales de este sector pagarían 49 €/mes por automatizar este flujo concreto".

La idea inicial tenía 11 módulos. La recortamos a 3:

  • Onboarding + autenticación.
  • El flujo principal (lo único que validaba la hipótesis).
  • Suscripción con Stripe (con plan único, sin gradación).

Decisiones que tomamos en Discovery:

  • Sin app móvil. El uso real iba a ser desde ordenador. Móvil podía esperar.
  • Sin panel de administración complejo. Para los primeros 20 clientes, el fundador iba a gestionar desde la base de datos directamente.
  • Sin integraciones de terceros. Las dos integraciones que Javier creía imprescindibles podían ser manuales durante los primeros meses.

Esto fue lo más difícil de aceptar para Javier. Recortar duele. Pero estas decisiones nos permitieron entregar en 6 semanas en lugar de 14, y con un presupuesto que cabía en lo que tenía.

Stack elegido

Stack estándar, sin sorpresas:

  • Frontend: Next.js + Tailwind.
  • Backend: NestJS + PostgreSQL.
  • Auth: Clerk (porque ahorraba 1 semana de implementación).
  • Pagos: Stripe Checkout (no Billing — más simple, suficiente para v1).
  • Hosting: Vercel (front) + Railway (back).
  • Email: Resend.

Por qué este stack: cada elemento era una decisión sin sorpresas. Cero riesgo técnico. Cuando lanzas en 6 semanas con presupuesto ajustado, lo último que necesitas es debuggear una librería poco madura.

Las 6 semanas de desarrollo

Semana 1: cimientos

Setup del proyecto, autenticación con Clerk, modelo de datos en PostgreSQL, estructura básica del frontend. Al final de la semana, Javier podía registrarse y entrar en una pantalla vacía. No parece gran cosa, pero es la base de todo.

Semana 2: el flujo principal (la mitad)

Empezamos a construir lo que valida la hipótesis. Demo el viernes. Primer feedback de Javier: una pantalla intermedia era confusa. La reorganizamos.

Semana 3: el flujo principal (completado)

Terminamos el flujo de usuario completo. Javier lo probó durante el fin de semana e hizo una lista de 12 cosas a ajustar. 8 las aceptamos (eran mejoras reales). 4 las descartamos (eran scope creep). Esta conversación es donde se pierden o se ganan los MVPs.

Semana 4: pagos e integración con Stripe

Integración con Stripe Checkout, página de planes, webhooks para gestionar el estado de la suscripción. Esta semana siempre lleva más de lo que parece: hay que manejar bien los casos raros (cancelación, fallo de cobro, reanudación).

Semana 5: pulido y emails

Emails transaccionales (bienvenida, recordatorio, factura), revisión de copys, ajustes de diseño, edge cases. La semana menos visible pero la que diferencia un MVP funcional de uno profesional.

Semana 6: deploy y traspaso

Deploy en producción, configuración del dominio, documentación técnica, sesión de formación con Javier para que entendiera cómo gestionar el día a día. Entrega oficial el viernes.

Lo que salió mal

No todo fue limpio. Tres cosas que retrasaron el proyecto:

  1. Cambio de estrategia de pricing en la semana 4. Javier decidió cambiar el plan único por dos planes. Negociamos: lo añadimos a cambio de quitar dos emails transaccionales. Sumó 2 días.
  2. Una integración que Javier insistió en mantener. Discutimos en Discovery, pero al final aceptamos. Resultó complicada de implementar y consumió 4 días que no había. Tuvimos que comer un día de festivo para llegar al plazo.
  3. El review de Stripe. La cuenta de Stripe de Javier tardó 4 días en activarse para producción por una verificación adicional. No pudimos lanzar pagos hasta que se resolvió.

Total: el proyecto terminó 3 días tarde sobre el plazo original. Aceptable dentro del margen que dejamos en el calendario.

Cifras reales tras el lanzamiento

Métricas de los primeros 4 meses tras el lanzamiento (todo orgánico, sin pagar publicidad):

  • Visitas totales a la landing: ~3.200.
  • Registros (trial): 87.
  • Conversión visita → trial: 2,7%.
  • Conversión trial → cliente de pago: 14%.
  • Clientes de pago al final del mes 4: 12.
  • MRR (ingresos recurrentes mensuales): 588 €.
  • Churn mensual: 8% (alto, normal en MVP — Javier sigue ajustando onboarding).

No es Stripe. No es Notion. Pero son métricas reales que validan que hay gente dispuesta a pagar. Y eso es exactamente lo que un MVP debe demostrar.

Decisiones que han sido clave después del MVP

  • No construir nada más durante 2 meses. Javier dedicó ese tiempo a hablar con cada cliente, entender por qué se quedaban y por qué se iban. Ese aprendizaje vale más que cualquier feature.
  • Aumentar precio. En el mes 3 subió de 49 a 69 €/mes para clientes nuevos. No bajó la conversión. El precio estaba mal puesto al principio.
  • Una integración real, basada en datos. En el mes 4 desarrollamos la integración que más pedían los clientes (no la que parecía obvia en Discovery). Conversión a pago subió 4 puntos.

Aprendizajes para otros fundadores

  1. Recortar duele pero salva proyectos. Las 11 funcionalidades originales habrían costado 25.000 € y no habrían validado más que las 3 que construimos.
  2. El MVP es solo el principio. Lo que pasa después del lanzamiento define el éxito, no el lanzamiento en sí.
  3. La velocidad de feedback importa más que el código. Demos semanales con decisiones rápidas. Sin eso, el proyecto se hubiera ido a 12 semanas.
  4. No subestimes el coste de cosas externas. Stripe, App Store, Google Play, integraciones con APIs. Reserva margen para esto.
  5. Las primeras métricas son barro. Hay que tener paciencia y datos de varios meses antes de extraer conclusiones de verdad.

Lección principal: El MVP de Javier no fue exitoso porque tuviera la mejor tecnología o el mejor diseño. Fue exitoso porque resolvió un problema real para un perfil concreto, con el alcance justo para validar y nada más.

Conclusión

Pasar de idea a MVP funcional con tracción real es posible en 6 semanas si las decisiones son las correctas. La parte técnica es lo más fácil. Lo difícil es decidir qué no construir, y mantener esa disciplina cuando aparece la tentación de añadir "una sola cosita más".

Si tienes una idea y estás en un punto parecido al de Javier en enero, cuéntanosla. Hacemos Discovery contigo y te decimos si tiene sentido como MVP y qué costaría construirlo.