La respuesta corta
Una landing page lleva de una a dos semanas. Una web corporativa de varias páginas, de tres a seis. Una tienda online, de cinco a ocho. Una plataforma web con cuentas de usuario e integraciones, de ocho semanas en adelante. Son plazos de trabajo real con un diseño ya aprobado, no sprints en el mejor de los casos. Lo que más varía no es el desarrollo, sino el tiempo que el proyecto pasa esperándote.
Plazos realistas por tipo de web
- Landing page: 1-2 semanas. Una plantilla, un recorrido, un formulario. Suma una semana si el diseño se hace desde cero
- Web corporativa de 5-8 páginas: 3-4 semanas con el diseño ya hecho, 5-6 semanas con diseño incluido
- Web corporativa con blog, varios idiomas y animaciones: 5-7 semanas. El segundo idioma y el trabajo de animación suman, cada uno, más o menos una semana
- Tienda online: 5-8 semanas. La estructura del catálogo, los filtros, los pagos, las reglas de envío y los pedidos de prueba llevan tiempo de verdad
- Plataforma o aplicación web: 8-16 semanas, y se entrega por fases, no en un único lanzamiento
- Rediseño de una web existente: suma 1-2 semanas a lo que costaría hacerla nueva, por la migración de contenido y las redirecciones
En qué se va realmente el tiempo
En una web corporativa típica, el reparto es más o menos este. Fíjate en lo poco que ocupa la parte que la mayoría imagina cuando piensa en hacer una web.
- Brief, estructura y planificación de los tipos de página: alrededor del 10%. Barato de hacer, caro de saltarse
- Diseño: alrededor del 30%, y la fase con más idas y venidas
- Maquetación y desarrollo: alrededor del 35%. La parte predecible; es la que rara vez sorprende a nadie
- Integración con el CMS y carga de contenido: alrededor del 15%, y es la fase que más a menudo se olvida en el presupuesto
- Pruebas, rendimiento, SEO básico y lanzamiento: alrededor del 10%. Recortar aquí es como una web sale rota en móvil
El tiempo de desarrollo es predecible. El tiempo de decisión no lo es, y es el tiempo de decisión lo que retrasa los proyectos.
Lo que de verdad retrasa los proyectos
En ocho años y unos cuantos cientos de proyectos entregados, puedo contar con los dedos de una mano las veces que el cuello de botella fue escribir código. Casi siempre es una de estas cosas.
- Contenido que todavía no existe. Los textos, las fotos y los datos de producto suelen prometerse para la primera semana y llegan en la quinta
- Correcciones por comité. Cuatro personas revisando por separado generan notas contradictorias y una segunda ronda que nadie había previsto
- Alcance añadido a mitad del trabajo. Cada «ya que estamos» es un cambio real en estructura, diseño y pruebas
- Terceros: pasarelas de pago, proveedores de CRM, acceso al hosting o al dominio. Su tiempo de respuesta se convierte en tu calendario
- Decisiones sin responsable. Si nadie puede aprobar la portada, la portada no se aprueba
Cómo acortarlo de verdad
- Ten el contenido listo antes de que empiece el diseño. Solo esto puede quitarle dos semanas a un proyecto
- Nombra a una sola persona que decida. Alguien que reúna las correcciones y diga que sí
- Acordad los tipos de página desde el principio y congeladlos. Un tipo de página nuevo a mitad de proyecto es un proyecto nuevo
- Da los accesos pronto: dominio, hosting, analítica y cualquier cuenta que vayamos a necesitar el día del lanzamiento
- Lanza por fases. Una web en marcha con cinco páginas vale más que una perfecta dentro de tres meses; el resto puede llegar después
- Revisa por lotes, en un solo documento, una vez por fase, en lugar de en mensajes sueltos a lo largo de la semana
Sobre el «te la hacemos en tres días»
Suele ser verdad y suele no servir de nada. Tres días te dan una plantilla con tu texto dentro: sin trabajo de estructura, sin ajuste de rendimiento, sin base de SEO y sin más pruebas que las del portátil del propio desarrollador. Es una buena opción si necesitas algo provisional antes de un evento. Es una mala opción si la web tiene que traerte clientes durante los próximos tres años, porque todo lo que se salta en esos tres días vuelve más adelante en forma de rehacerla.
Conclusión
Pide un calendario con fases y dependencias, no una sola fecha. Un plan que dice «diseño para el día 14, siempre que los textos lleguen antes del 7» te cuenta la verdad sobre quién tiene qué en la mano. Si tienes una fecha límite fija (un lanzamiento, una temporada, una feria), dilo desde el principio. Los plazos se pueden construir alrededor de una fecha fija dividiendo el lanzamiento en fases, pero solo si la fecha se conoce antes de hacer el plan, no después.