«Cuánto tardas en tener algo funcionando?» es la pregunta que más me hacen los clientes en la primera llamada. Mi respuesta desde hace un tiempo es la misma: cuatro semanas para pasar de una idea a una web app en producción, con alcance bien definido.
No es magia ni plantilla mágica, es un proceso que he ido puliendo proyecto tras proyecto. Aquí lo comparto tal cual lo uso.
Semana 1: Descubrimiento y arquitectura
Nada de código todavía. Esta semana se define el alcance real: qué problema resuelve la app, quién la usa, qué flujos son críticos y cuáles pueden esperar a una v2. Salgo de aquí con un documento corto (nunca más de 2-3 páginas) con el modelo de datos, la arquitectura técnica y una lista priorizada de features. El objetivo es tener menos ambigüedad posible antes de escribir la primera línea.
Semana 2: MVP funcional
Construyo el esqueleto completo: auth, base de datos, rutas principales y el flujo crítico de punta a punta, aunque sea feo. Prefiero tener algo clicable y funcional antes que una interfaz pulida sin lógica detrás.
Es la semana donde suelen aparecer los problemas reales de diseño de datos, y es mucho más barato resolverlos ahora que en la semana 4.
Semana 3: Pulido y contenido
Con la lógica funcionando, toca UI seria, estados de carga y error, validaciones, responsive, y cargar contenido real (no lorem ipsum). Es también cuando el cliente empieza a probar la app de verdad, no una demo, y ahí salen los ajustes de UX que no se ven en una llamada.
Semana 4: QA, deploy y entrega
Testing manual de los flujos críticos, revisión de seguridad básica (RLS, variables de entorno, permisos), deploy a producción y documentación mínima para que el cliente pueda operar la app sin depender de mí para todo. Cierro con una llamada de entrega y un backlog priorizado para la v2.
El stack que uso
- Next.js + TypeScript para el frontend y las rutas API.
- Tailwind para no perder tiempo peleando con CSS.
- Supabase para auth, base de datos y storage sin montar infraestructura desde cero, así vamos más rápido.
- Vercel para deploy continuo desde el primer commit, no solo al final.
Lecciones aprendidas
- El scope creep es el que mata los timelines, no la complejidad técnica. Cualquier feature nueva que aparece a mitad de proyecto va a la lista de v2, sin excepciones.
- Desplegar desde el día 1, aunque no haya nada que ver todavía, evita sorpresas de última hora con el entorno de producción.
- Enseñar el MVP feo en la semana 2 genera mejor feedback que enseñar algo bonito en la semana 4, porque el cliente reacciona a la función, no a los colores.
- Un documento de alcance corto pero firmado vale más que cien reuniones. Reduce las conversaciones de «pero yo pensaba que esto iba incluido» a casi cero.
Si tienes una idea y quieres saber si encaja en un proceso de cuatro semanas, escríbeme y lo vemos juntos.