Cuánto tarda una página web: plazos reales y por qué se retrasan

¿Cuánto tarda una página web? Una web corporativa bien planteada, con contenidos ya preparados, suele estar lista en dos o cuatro semanas. Con funcionalidades a medida, el plazo sube a varias semanas más. Y si hablamos de una tienda online con integraciones o una aplicación a medida, se mide en meses, no en semanas. Pero hay un detalle que casi nadie te cuenta: la parte de programar rara vez es lo que más plazo consume.

En los proyectos que vemos, el tiempo se gasta sobre todo en lo que ocurre antes y alrededor del código: cerrar el alcance, decidir el diseño y reunir los contenidos. Cuando un proyecto se retrasa, la causa casi nunca es que el programador sea lento. Es que alguna de esas tres piezas llegó tarde, incompleta o cambió cuando ya había trabajo montado encima.

Las cuatro fases que consumen el plazo

Cada proyecto serio pasa por cuatro fases, y solo una de ellas es programación.

Descubrimiento. Una conversación corta pero intensa: qué objetivo real tiene la web, cómo trabaja hoy tu negocio, qué procesos tiene que soportar y qué es imprescindible para el primer lanzamiento. Si esta fase se hace bien, dura días. Si se hace mal o se salta, cobra su precio en la fase de desarrollo, con intereses.

Diseño. Traducir el alcance a pantallas concretas: estructura, contenido visual, versión móvil. El diseño no es decoración: cada pantalla acordada aquí es una decisión que no se discute después. Cuantas más decisiones se dejen para más tarde, más se alarga el proyecto.

Contenidos. Los textos, las fotos, los datos de producto, los precios. Es la fase que más sorprende a los clientes, porque casi siempre está pendiente cuando el desarrollo ya puede empezar. Una web con diseño aprobado y textos sin escribir está, en la práctica, parada.

Desarrollo y salida a producción. Programar, probar en dispositivos reales, revisar y publicar. Con el alcance cerrado y los contenidos listos, esta fase es la más predecible de todas. Sin ellos, es donde se esconden las eternidades.

Plazos orientativos según el tipo de proyecto

Los números concretos dependen del alcance, pero hay órdenes de magnitud estables.

Una web corporativa con contenidos preparados: dos a cuatro semanas. Es el escenario más limpio porque el alcance es conocido y las decisiones son pocas. Si añade funcionalidades a medida (reservas, área privada, catálogo con filtros), suma semanas de desarrollo y, sobre todo, de pruebas.

Una tienda online: con un catálogo simple y prisa por lanzar, semanas. Cuando entran pasarelas de pago con requisitos concretos, logística, sincronización de stock o conexión con un ERP, el plazo se mide en meses. No es pesadez del proveedor: cada integración tiene que probarse con casos reales, y ahí no hay atajos honestos.

Una aplicación a medida: una primera versión demostrable suele estar lista en semanas, aunque el alcance total del proyecto sea mayor. Como referencia, tres proyectos reales del historial de nuestra fundadora duraron 3, 6 y 8 meses: la campaña de premios de una cadena de tiendas, el motor de fidelización de esa misma cadena y la integración completa con el ERP. La diferencia entre ellos no fue el tamaño del equipo, fue cuántos sistemas ajenos había que conectar y estabilizar.

Si quieres cruzar plazo con dinero, la matriz de precios por partida te da el rango orientativo de cada tipo de proyecto, y la calculadora de presupuesto web te lo calcula en dos minutos con el desglose por partidas.

Los cuatro retrasos que se repiten en casi todos los proyectos

Detrás de cada proyecto eterno hay, casi siempre, alguno de estos cuatro patrones.

Alcance abierto. El proyecto empieza sin decidir qué es imprescindible y qué puede esperar. Cada idea nueva durante el desarrollo reabre trabajo terminado, y una reapertura no cuesta un día: cuesta el día nuevo más la revisión de lo que ya estaba hecho. Es la diferencia entre un precio cerrado y una factura que crece sola, algo que contamos en detalle al explicar cómo comparar presupuestos web.

Contenidos a mitad de camino. El cliente promete los textos "en cuanto esté el diseño". El diseño llega, los textos no. El desarrollador maqueta con texto de relleno, llega un texto real que no cabe, y toca rehacer media página. Es el retraso más absurdo de todos, porque no depende del proveedor.

Decisiones de diseño atomizadas. Reuniones de quince minutos repartidas durante semanas en las que se aprueba "el logo un poco más grande" o "un tono de azul más serio". Cada decisión aislada no parece importante; diez de ellas seguidas son un mes.

Pruebas sin calendario. La revisión final "para cuando puedas" no existe en ningún calendario, así que se convierte en la última fase y la más lenta. Sin una ventana acordada con los dos equipos, el 95% terminado se estanca durante semanas en el último 5%.

Qué puedes hacer tú para que el plazo se cumpla

La buena noticia es que la mayoría del plazo depende de cosas que controlas antes de firmar.

Pide una fase de descubrimiento corta y explícita: objetivo del negocio, proceso actual y prioridades por escrito. Un proveedor que cotiza sin entender tu proceso está adivinando, y adivinar sale caro después. Ese documento, además, es el que convierte un presupuesto en un compromiso verificable: precio fijo sobre alcance cerrado.

Bloquea en tu calendario, desde el día uno, ventanas de revisión por hito. No hace falta que sean largas: hace falta que existan y que quien decide esté. Los proyectos que se entregan en plazo no son los que tenían menos revisión, son los que la tenían ordenada.

Y prepara los contenidos en paralelo, no como una sorpresa de la semana tres. Textos, fotos, datos de producto, precios. Si necesitas un punto de partida, la plantilla de brief que enlazamos al final reúne las preguntas que hay que responder antes de la primera reunión.

Hay un caso donde el plazo no es el problema: cuando la web que ya tienes funciona y el problema es que nadie la encuentra o no convierte. Ahí, antes de empezar de cero, merece la pena medir. Puedes auditar tu web gratis en 30 segundos y comprobar si lo que necesitas es una web nueva o un arreglo concreto de la que ya tienes.

Si el diagnóstico dice que toca proyecto nuevo, empieza por el alcance, sigue por los contenidos y deja que el código sea lo más rápido del proceso. El plazo te lo agradecerá.