Una landing tarda unas 2 a 4 semanas, un sitio de varias páginas de 4 a 8, y un MVP SaaS unas 6 a 10 semanas — cuando el alcance es claro y el feedback es rápido. La mayoría de los plazos se atrasan por lo mismo: contenido no listo, decisiones lentas y alcance agregado a mitad del build. El número realista no es solo el build; es el build más tu tiempo de respuesta. Planea ambos y una fecha de lanzamiento deja de ser ficción.
¿Cuánto tardan los proyectos comunes?
Rangos honestos y aproximados: una landing enfocada, 2 a 4 semanas; un sitio de negocio de varias páginas, 4 a 8 semanas; un MVP SaaS, unas 6 a 10 semanas. Asumen alcance claro y feedback pronto. Cubren diseño, construcción y una pasada real de QA — no un apurado "compila, lánzalo". La cantidad de páginas y de funciones mueve el número, pero también qué tan rápido se toman las decisiones de tu lado. Ambos son de verdad parte del plazo. Algo que esos rangos esconden: son tiempo de calendario para un build enfocado con una persona o un equipo ajustado, no una cola detrás de otros diez clientes. Si una cotización promete una app compleja en unos días, eso es una advertencia, no una ganga — el software real tiene un piso que apurarse no puede vencer sin recortar las partes que no se ven.
¿Cuáles son las fases dentro de un plazo?
La mayoría de los builds siguen el mismo arco: alcance y preparación de contenido, diseño, construcción, luego QA y lanzamiento. Alcance y preparación de contenido es la que la gente se salta y la que decide todo — el diseño necesita copy real, no relleno. La construcción es la parte visible pero rara vez el verdadero cuello de botella. QA y lanzamiento es donde pasan los chequeos previos. Cuando un proyecto se siente lento, suele estar atascado en preparación o feedback, no en el código. Una división aproximada de un build típico: la preparación y el diseño toman el primer tercio, la construcción el medio, y QA y lanzamiento el tramo final — pero el tercio de preparación es el que decide si el resto va a tiempo. El contenido y las decisiones reunidos antes de que empiece el diseño son lo que evita que construcción y QA absorban el atraso después.
¿Qué estira más un plazo?
Tres cosas, siempre: contenido que no está listo, feedback que tarda una semana por ronda, y alcance agregado después de fijar el plan. Ninguna es problema de código. Un solo ciclo de revisión lento puede sumar semanas en un proyecto, y una función a mitad del build empuja la fecha más de lo que parece. Las marco al inicio, porque el plazo honesto depende tanto de tu velocidad de respuesta como de mi velocidad de construcción. Ambos lados fijan la fecha. La silenciosa es "solo una cosa más" después de fijar el plan: cada adición parece pequeña, pero reabre diseño, construcción y QA a la vez, así que una función a mitad del build cuesta más que la misma función acotada desde el inicio. Por eso aparto ideas nuevas para un seguimiento rápido en vez de dejar que estiren el lanzamiento — cubierto en qué significa "terminado" en una v1.
¿Por qué las estimaciones de software fallan tan seguido?
Porque la mayoría de las estimaciones cotizan la construcción y olvidan todo lo demás. El código es la parte visible, pero un plazo real también incluye preparación de contenido, decisiones de diseño, ciclos de revisión, QA, casos borde y lanzamiento — y esas son justo las partes que se desestiman en una cotización optimista. La otra razón son las incógnitas: todo build choca con algunas sorpresas, y una estimación sin holgura asume una corrida perfecta que rara vez ocurre. Un plazo honesto nombra las fases, incorpora tu tiempo de respuesta y deja espacio para lo inesperado. Un número sin nada de eso no es un plan; es una esperanza, y es por qué tantos proyectos "de repente" se atrasan.
¿Cómo fijas una fecha que de verdad puedas cumplir?
Trabaja hacia atrás desde una v1 acotada, no hacia adelante desde un deseo. Empieza fijando exactamente qué sale en la primera versión, suma rangos realistas por cada fase, incorpora tu tiempo de revisión, y deja algo de holgura para las incógnitas que todo proyecto encuentra. Una fecha fijada así es una que puedes defender; una fecha elegida porque suena bien — "en vivo en dos semanas" sin alcance detrás — es solo presión que se paga en esquinas recortadas o un atraso. Si una fecha fija es inamovible, entonces el alcance es la palanca: lanza una v1 más pequeña y afilada para la fecha y haz seguimiento rápido con el resto. Elige la fecha y el alcance juntos, porque no puedes fijar ambos por separado.
¿Cómo mantengo un proyecto en pista?
Acoto las fases, preparo el contenido por adelantado, fijo la cadencia de feedback y cierro la lista de funciones de la v1 antes del diseño — luego aparto ideas nuevas para un seguimiento rápido en vez de dejar que muevan el lanzamiento. Es la misma disciplina en mis servicios, sea un sitio o un MVP. Un plazo realista no es una adivinanza; es un plan con tus decisiones incorporadas. Llega preparado y la fecha aguanta.
Guías de estrategia relacionadas
Mira cuánto tarda construir un sitio web, cuánto tarda construir un MVP y qué significa "terminado" en una v1.
¿Necesitas un plazo real para tu proyecto? Cuéntame qué estás construyendo — lo mapeo fase por fase hasta una fecha de lanzamiento.
