Skip

00/Startup

MVP en 6 semanas: el cronograma que sí funciona

Qué construir primero, qué dejar para la v2, y por qué la pre-venta importa más que el MVP perfecto. Cronograma semana a semana con datos reales.

Fecha
11 de febrero de 2026
Tiempo de lectura
6 min de lectura
Autor
Por Jafeth Jiménez

La obsesión por el "MVP perfecto" es la razón #1 por la que las startups en Costa Rica no llegan a salir. Pasan 6 meses puliendo features que nadie pidió, mientras un competidor lanza algo más feo pero que ya está cobrando. Este es el cronograma que usamos para llevar una idea a producción en 6 semanas, con la regla dura que mantiene al proyecto enfocado.

💡 ¿Tu idea cabe en 6 semanas? El cotizador interactivo te da el rango USD + duración estimada en 30 segundos.

💰 ¿Qué presupuesto necesita un MVP? Ver la guía completa de pricing en Costa Rica — rangos USD 3 000–5 000 para MVPs, desglose por feature y por vertical.

La regla dura del MVP de 6 semanas

Un MVP de 6 semanas es feo, falla en casos borde, y tiene una sola feature genial — pero está vivo y pagando.

Si tu MVP en la semana 6 no puede cobrar a un cliente real, no terminaste un MVP — terminaste un demo. Y los demos no son negocio.

Cronograma semana a semana

Semanas 1–2: Discovery + Arquitectura

No se escribe código de producción todavía. Se decide qué construir y cómo.

Lo que se hace:

  • Entrevistas con 8–12 prospectos. El equipo del cliente y nosotros. Pregunta: "¿qué problema te cuesta más resolver en X?" — no muestres tu idea.
  • Diseño de la feature principal. Wireframes a baja fidelidad. Solo el flujo crítico.
  • Decisiones de stack. Next.js o Astro, Stripe o LemonSqueezy, Supabase o RDS. (Ver nuestra nota sobre elegir stack.)
  • Setup técnico mínimo. Repo, Vercel preview, dominio, Stripe sandbox, analytics.

Lo que NO se hace: backend en producción, integraciones nice-to-have, diseño pulido.

Salida de la semana 2: un documento de 2 páginas con la feature principal definida + un Figma con el flujo crítico + el repo armado.

Semanas 3–5: Build en sprints semanales

3 sprints de 1 semana. Cada sprint termina con demo al cliente y, si aplica, a 1–2 usuarios beta.

Sprint 3 — Esqueleto:

  • Auth funcionando (Magic link o Google OAuth — no email + password aún).
  • La feature principal en su versión más cruda. No estilizada. Funcional.
  • Stripe en sandbox conectado pero no integrado al flujo aún.

Sprint 4 — Conectar el flujo:

  • La feature principal pulida en sus 2–3 estados principales (loading, éxito, error).
  • Stripe checkout real (pagos en sandbox, pero con flujo completo).
  • Email transaccional vía Resend (welcome, confirmación de pago).

Sprint 5 — Lo que falte para vender:

  • Landing simple (1 página) con propuesta de valor + botón a Stripe.
  • Onboarding básico para que un usuario nuevo pueda llegar a la feature en 60 segundos.
  • Página de cuenta + cancelar suscripción (Stripe Customer Portal).

Lo que NO se hace en estas 3 semanas:

  • Tests automatizados pesados (un set mínimo de E2E es suficiente).
  • Internacionalización (a menos que sea crítico el primer día).
  • Panel admin pulido (los admins usan la base de datos o Retool).
  • Diseño "wow" — diseño limpio basta.

Semana 6: Hardening + Deploy + Primeros usuarios

La semana donde el MVP pasa de ser proyecto a ser producto vivo.

Lunes–martes: bugs críticos y casos borde que aparecieron en demos. Triaje brutal: solo lo que bloquea uso, no lo bonito.

Miércoles: deploy a producción. Stripe en live mode. Dominio definitivo. SSL, analytics (PostHog), Sentry o equivalente para errores.

Jueves–viernes: los primeros 5–10 usuarios reales (los que pre-vendiste en las primeras semanas). Soporte directo por WhatsApp o Slack. Cada bug que reporten se arregla en menos de 24 horas.

Salida de la semana 6: producto en producción, pagando con tarjeta real, con 5+ usuarios activos. Un Loom de 2 minutos con la demo grabada para enviar a inversores o más prospectos.

Por qué la pre-venta es más importante que el MVP perfecto

La mayoría de founders quieren "construir primero, vender después". Es exactamente al revés. El plan correcto:

  1. Semana 0 (antes de las 6 semanas): pre-venta. Hablas con 10 prospectos. Vendes el problema, no el producto. Pides compromiso (depósito, carta de intención, lista de espera con tarjeta).
  2. Si nadie pre-paga: el problema no es suficiente. No construyas el MVP. Vuelve a iterar la propuesta.
  3. Si 3+ pre-pagan: tienes señal. Empieza el cronograma de 6 semanas.

Esto cambia todo:

  • El presupuesto del MVP queda parcialmente cubierto antes de empezar.
  • Tienes 3 usuarios garantizados el día del lanzamiento.
  • El feedback de semana 6 es de gente con piel en el juego.
  • El equipo construye con confianza sabiendo que el mercado validó.

Stack pragmático para un MVP

Necesidad Solución recomendada Por qué
Framework web Next.js 16 Stack más documentado, deploy invisible
Hosting + DB Vercel + Supabase Cero ops, escala hasta 50k usuarios
Auth Supabase Auth Magic link + OAuth, listo en 1 hora
Pagos Stripe Checkout y Customer Portal listos
Email transaccional Resend API limpia, dominio rápido de verificar
Analytics PostHog Funnel + cohorts + replay incluidos
Soporte WhatsApp Business Cero fricción para usuario LatAm

Total de costo de stack en producción para 100 usuarios: USD 0–20/mes. Sí, cero. Las versiones free de Vercel, Supabase, Resend y PostHog cubren el primer mes fácil.

Errores que matan el cronograma de 6 semanas

  1. "Mientras estamos, agreguemos X feature". No. La feature X va a la v2. Cualquier desvío rompe el ritmo.
  2. Diseñar antes de validar. Si no pre-vendiste, lo que estás diseñando es probablemente la solución equivocada.
  3. Stack ambicioso. Microservicios, Kubernetes, mensajería async — no para un MVP. PostgreSQL + Next.js + 1 servicio externo es suficiente.
  4. No deployar la semana 1. El deploy debe estar funcionando desde el día 5. Si esperas a la semana 6, vas a descubrir 20 problemas el último día.
  5. Equipo de 5+ personas. Equipo de 2–3 personas máximo para un MVP. Más equipo = más coordinación = menos velocidad.

En resumen

Semana Objetivo Output
1–2 Discovery + arquitectura Doc + Figma + repo
3 Esqueleto Auth + feature cruda + Stripe sandbox
4 Conectar el flujo Stripe real + emails
5 Lo que falte para vender Landing + onboarding + cuenta
6 Hardening + Deploy + primeros usuarios Producto vivo cobrando

Si tienes una idea y quieres saber si cabe en 6 semanas, conversémoslo. No cobramos esa conversación. En 30 minutos te decimos si vale la pena empezar o si todavía falta pre-venta.

Jafeth Jiménez

Por

Jafeth Jiménez

Fundador · SEO y desarrollador

Co-fundador y dueño de Sirius. Lidera la estrategia de SEO de la agencia y participa en el desarrollo de cada proyecto que enviamos a producción. Atiende clientes en Costa Rica y la región.

03/Paso a paso

Cómo lanzar un MVP de software en 6 semanas

Cronograma semana a semana con entregables concretos. La regla dura: el MVP es feo, falla en casos borde y tiene una sola feature genial — pero está vivo y cobrando.

  1. Paso 01

    Pre-venta (semana 0, antes del cronograma)

    Habla con 10 prospectos. Vende el problema, no el producto. Pide compromiso de pago: depósito, carta de intención o lista de espera con tarjeta. Si nadie pre-paga, el problema no es suficiente.

  2. Paso 02

    Semanas 1–2: Discovery + Arquitectura

    Entrevistas con 8–12 prospectos, diseño de la feature principal en wireframes a baja fidelidad, decisión de stack (Next.js / Stripe / Supabase) y setup técnico mínimo (repo, Vercel preview, dominio, sandbox).

  3. Paso 03

    Sprint 3: Esqueleto

    Auth funcionando (Magic link o Google OAuth), feature principal en su versión más cruda y funcional, Stripe en sandbox conectado pero todavía no integrado al flujo.

  4. Paso 04

    Sprint 4: Conectar el flujo

    Feature principal pulida en sus 2–3 estados (loading, éxito, error). Stripe checkout real con flujo completo. Email transaccional vía Resend (welcome, confirmación de pago).

  5. Paso 05

    Sprint 5: Lo que falte para vender

    Landing simple de una página con propuesta de valor + botón a Stripe. Onboarding básico (60 segundos del registro a la feature). Página de cuenta + cancelar suscripción vía Stripe Customer Portal.

  6. Paso 06

    Semana 6: Hardening + Deploy + Primeros usuarios

    Triaje brutal de bugs críticos, deploy a producción en Stripe live mode con dominio definitivo, SSL, analytics y Sentry. Soporte directo por WhatsApp para los primeros 5–10 usuarios reales.

04/Preguntas frecuentes

Lo que la gente nos pregunta sobre esto.

¿Qué es exactamente un MVP?

Un MVP (Minimum Viable Product) es la versión más pequeña del producto que **resuelve UN problema concreto y se puede cobrar**. Tres condiciones: (1) tiene una feature principal funcionando bien, (2) tiene auth y billing si vas a cobrar, (3) está deployado y accesible. Lo demás (UX pulida, casos borde, integraciones nice-to-have) puede ir después.

¿Por qué exactamente 6 semanas y no 3 meses?

Porque 6 semanas es el plazo donde aún hay urgencia productiva. A los 3 meses el equipo se relaja y aparecen scope creep, refactors innecesarios, y debates de framework. 6 semanas es suficiente para construir una feature principal bien y zero más. Si la idea necesita más, parte el MVP en dos lanzamientos de 6 semanas.

¿Qué cuesta un MVP de 6 semanas en Costa Rica?

USD 3 000 – 8 000 dependiendo de complejidad. MVP simple (auth + 1 feature + Stripe): USD 3 000–5 000. MVP con varios roles, integración a sistemas externos o IA: USD 5 000–8 000. La cotización inicial es gratis y por escrito.

¿Qué pasa si la primera versión del MVP no funciona con usuarios?

Es la situación normal, no la excepción. El 60–70% de los MVPs requieren cambio de rumbo después del primer mes en producción. Por eso la inversión inicial debe ser baja — no quieres haber gastado USD 50k antes de descubrir que la idea necesita pivote.

¿Debo conseguir clientes ANTES de tener el MVP listo?

Sí. La pre-venta es la mejor validación. Habla con 10 prospectos antes de construir, vende el problema (no el producto) y pide compromiso de pago: depósito, carta de intención, o lista de espera con tarjeta. Si nadie pre-paga, el problema no es lo suficientemente grande para construir el MVP.

¿Qué tecnologías recomiendan para un MVP?

Stack pragmático: Next.js + Supabase (o Vercel + Postgres) + Stripe + Resend + PostHog. Es suficiente para 1 000 usuarios sin tocar arquitectura. Después de eso, si el negocio crece, se rehace la pieza que toque. No optimices para escala que aún no tienes.

¿Cómo contacto a Sirius para construir mi MVP?

WhatsApp +506 8433 7752 o admin@siriusx.net. La primera reunión es de 30 minutos: nos cuentas la idea, te decimos si cabe en 6 semanas y con qué presupuesto. Cotización escrita en 48 horas. Empezamos típicamente 1–2 semanas después del SI.

05/Contacto directo

Hablar con Sirius sobre esto.

Somos una agencia de software en Costa Rica. Si lo que leíste te aplica y quieres avanzar, escríbenos por cualquiera de estas vías:

Horario
Lun a Vie 8 am – 5 pm · Sáb 8 am – 12 md
Ubicación
Pozos de Santa Ana, Santa Ana, San José, CR

02/Cuéntanos

¿Te aplica algo de esto? .

Si la nota te sonó familiar y tienes un proyecto en mente, lo conversamos directo en WhatsApp. Sin formularios.