Cuando una empresa pregunta cuánto tarda en hacerse una web, la respuesta no depende solo del número de páginas. En una web corporativa sencilla, el volumen de contenidos puede ser el factor principal. En una tienda online con muchas referencias, tarifas específicas o conexión con un ERP, el calendario está condicionado sobre todo por los datos, las integraciones y las decisiones internas.
Por eso, dar un plazo cerrado antes de entender el proyecto suele generar una falsa sensación de seguridad. Un calendario fiable debe construirse a partir del alcance, las dependencias y el proceso de validación, no de una estimación genérica aplicable a cualquier web.
¿Cuánto tarda en hacerse una web a medida?
El plazo de una web a medida puede estimarse con criterio cuando están definidos cuatro aspectos: qué debe hacer la plataforma, qué información debe contener, con qué sistemas debe conectarse y quién validará cada fase.
No es lo mismo adaptar una estructura estándar que crear una arquitectura de contenidos propia, diseñar distintos tipos de ficha, programar funcionalidades específicas y sincronizar la web con herramientas internas. El desarrollo a medida no implica necesariamente construirlo todo desde cero, sino decidir qué partes pueden resolverse con componentes fiables y cuáles requieren una solución específica.
También hay que diferenciar entre diseño y desarrollo. El diseño define la estructura, la navegación, la jerarquía de la información y el comportamiento de las interfaces. El desarrollo convierte esas decisiones en una plataforma funcional, segura y conectada. Si ambas fases avanzan sin una definición compartida, aparecen cambios tardíos que afectan al calendario.
¿Qué hace que un proyecto web se alargue más?
Los contenidos que todavía no están preparados
Los textos, las imágenes y la información comercial no son una tarea que siempre pueda dejarse para el final. Condicionan la longitud de las páginas, la jerarquía visual, los filtros, el SEO e incluso algunas funcionalidades.
En una empresa distribuidora, por ejemplo, hay que decidir cómo se organizan las familias de productos, qué atributos se mostrarán, qué documentación podrá descargarse y qué criterios utilizará un cliente para encontrar una referencia. Antes de decidir si conviene un catálogo digital, un documento descargable o una combinación de ambos, es útil valorar qué tipo de catálogo de productos necesita la empresa.
Un catálogo amplio o con datos irregulares
Importar productos no consiste únicamente en trasladar una hoja de cálculo. Es habitual encontrar categorías duplicadas, descripciones incompletas, unidades distintas, imágenes sin correspondencia o referencias que no siguen un criterio uniforme.
Antes de cargar el catálogo, hay que establecer una estructura de datos y determinar cuál es la fuente correcta. Si este trabajo no se detecta al principio, puede bloquear el desarrollo u obligar a repetir importaciones y revisiones.
Las validaciones sin responsables ni fechas
Un proyecto puede detenerse aunque el diseño y la programación avancen correctamente. Ocurre cuando no está claro quién aprueba la estructura, quién revisa los textos o qué personas deben validar las condiciones comerciales.
Las validaciones funcionan mejor cuando cada fase tiene un responsable, una fecha y un criterio concreto. También conviene centralizar los comentarios. Recibir indicaciones contradictorias a través de canales distintos genera iteraciones que no estaban previstas.
Los cambios de alcance durante el desarrollo
Añadir un idioma, un área privada, tarifas por cliente o un nuevo flujo logístico puede ser razonable, pero no es un ajuste menor. Cada nueva necesidad puede afectar al diseño, la base de datos, los permisos, las pruebas y la integración con otros sistemas.
Esto no significa que el proyecto deba quedar congelado. Significa que los cambios deben valorarse y priorizarse: incorporarlos a la primera versión, sustituir otra funcionalidad o programarlos para una fase posterior.
Si es necesario ordenar contenidos, recorridos de compra y funcionalidades antes de programar, un proceso de diseño web centrado en el usuario y en la estructura real del negocio permite definir una base clara y reducir los cambios tardíos.
¿Cuánto tarda una tienda online con ERP?
Una tienda online con ERP requiere más definición que un comercio electrónico gestionado de forma independiente. La cuestión no es solo si ambos sistemas pueden conectarse, sino qué información debe circular, en qué dirección y con qué frecuencia.
Antes de calcular el plazo, hay que responder preguntas como estas:
- ¿Dónde se crean y actualizan los productos?
- ¿Qué sistema controla el stock, los precios y las tarifas?
- ¿La web debe enviar los pedidos al ERP automáticamente?
- ¿Hay clientes B2B con condiciones comerciales diferentes?
- ¿Cómo se gestionan las incidencias si falla una sincronización?
- ¿El ERP dispone de una API o hay que utilizar otro mecanismo de intercambio?
Una API es una vía para que dos aplicaciones intercambien información de forma estructurada. Que el ERP disponga de una no significa, por sí solo, que la integración sea inmediata: hay que comprobar qué datos ofrece, cómo identifica cada registro y qué limitaciones tiene.
También deben preverse pruebas con datos reales, registros de errores y mecanismos para evitar duplicados. Esta parte suele ser invisible para el comprador, pero es la que permite que la tienda no genere más trabajo administrativo del que ahorra. El desarrollo web con integraciones y funcionalidades a medida debe contemplar estos flujos desde la arquitectura inicial.
¿Cómo se puede fijar un plazo realista antes de contratar?
Un buen presupuesto no debería indicar únicamente una fecha final. También debería explicar las fases del proyecto, qué debe entregarse en cada una y de quién depende que se pueda avanzar.
- Definición funcional: objetivos, públicos, tipos de contenido, funcionalidades y sistemas implicados.
- Arquitectura y diseño: estructura de navegación, prototipos, interfaz y comportamiento en distintos dispositivos.
- Desarrollo: construcción de plantillas, funcionalidades, gestión de contenidos e integraciones.
- Carga o importación: incorporación del catálogo, textos, imágenes, documentos y metadatos.
- Pruebas y publicación: revisión funcional, dispositivos, rendimiento, formularios, compra, analítica y SEO.
También debería dejar claro qué queda fuera del alcance, cuántas rondas de cambios se han previsto y qué ocurre si una validación o una entrega de contenidos se retrasa. Esta transparencia ayuda a comparar proveedores más allá del precio o de una promesa de rapidez.
Si la nueva plataforma sustituye una web existente, el calendario debe incluir un inventario de URL, redirecciones, revisión de metadatos y comprobaciones posteriores. La guía sobre cómo planificar una migración web sin perder posicionamiento ni contactos explica por qué publicar no consiste simplemente en sustituir una web por otra.
¿Qué decisiones ayudan a cumplir el calendario?
La forma más eficaz de acortar los plazos no es empezar a programar antes, sino reducir las incertidumbres antes de hacerlo. Estas decisiones suelen facilitar el proyecto:
- Designar a una persona responsable de coordinar y validar.
- Preparar una muestra representativa del catálogo antes de diseñar las fichas.
- Identificar desde el principio a los responsables del ERP, la logística y los contenidos.
- Separar las funcionalidades imprescindibles de las que pueden incorporarse en una fase posterior.
- Validar la estructura y los prototipos antes de entrar en desarrollo.
- Reservar tiempo para pruebas reales de compra, sincronización y gestión interna.
Para una tienda o empresa distribuidora del Vallès o Barcelona, el plazo realista no es necesariamente el más corto. Es el que contempla el catálogo, las reglas comerciales, las integraciones y el tiempo de decisión de todas las partes. Un proyecto bien planificado evita que la web se publique rápidamente, pero obligue después a duplicar datos, corregir procesos o reconstruir funcionalidades.
La pregunta útil, por tanto, no es solo cuánto tarda una tienda online, sino si el calendario cubre todo lo necesario para que pueda funcionar de forma estable desde el primer día y evolucionar sin tener que rehacer la base.
Nos gusta hablar de estas cuestiones antes de que se conviertan en un proyecto cerrado. Cuéntanos tu caso.