Un proyecto de Figma a WordPress tarda entre 2 y 4 semanas con alcance de landing, de 4 a 8 semanas en un sitio corporativo con motion, y de 8 a 12 semanas cuando entra e-commerce o lógica a medida. Son rangos orientativos de nuestro proceso: lo que más mueve el calendario no es el número de pantallas, sino el contenido que llega tarde y las iteraciones de diseño después del arranque.
Fases del proyecto y rangos orientativos
Trabajamos en seis fases encadenadas. Si una se retrasa, las siguientes arrastran el retraso; por eso cerramos cada fase con un entregable visible antes de abrir la siguiente.
| Fase | Rango orientativo | Qué la retrasa |
|---|---|---|
| Descubrimiento y estructura | 3 a 5 días | Brief a medias o decisiones de negocio todavía pendientes. |
| Adaptación de Figma al sistema | 4 a 7 días | Archivo sin variables, estados ni breakpoints claros. |
| Desarrollo WordPress a medida | 1 a 3 semanas | Funcionalidad especial o integraciones con terceros. |
| Motion con GSAP | 3 a 7 días | Animaciones sin brief ni prioridad clara desde el inicio. |
| Carga de contenido y QA | 1 a 2 semanas | Textos, fotos y revisión final que llegan tarde. |
| Lanzamiento y estabilización | 2 a 4 días | DNS, accesos, redacciones y pruebas en el último tramo. |
Qué mueve los plazos de verdad
El factor que más atrasa un proyecto no es el código: es el contenido. Cuando textos e imágenes llegan en la última semana, el layout se reajusta tarde y el QA se repite. El segundo factor son las rondas de revisión sin criterio: cada iteración que reabre decisiones ya aprobadas cuesta días completos, porque el cambio no es local; se propaga a componentes, breakpoints y animaciones.
El tercer factor es el alcance técnico. Una landing con secciones estáticas construye rápido; un catálogo con filtros, miembros o pagos se mueve en otro rango. Lo mismo aplica al motion: una transición de página bien definida entra en el plan; una idea de animación que aparece a mitad de desarrollo obliga a rehacer tiempos. Por eso revisamos el proceso completo de Figma a WordPress contigo antes de comprometer fechas, no después.
También pesa cómo se organiza el trabajo entre agencia y desarrollo. Cuando operamos como extensión de tu equipo con desarrollo web white label, las decisiones de diseño y de código se toman en la misma cadencia y los cuellos de botella se resuelven el mismo día, no en la reunión de la semana siguiente.
Cómo evitamos que el calendario se inflle
Cerramos el alcance por fases, no por pantalla suelta: cada fase tiene entregable, responsable y criterio de aceptación. El contenido se pide por etapas —estructura primero, copy final después— para que desarrollo y redacción corran en paralelo. El motion se define en el mismo documento que el diseño, con prioridad clara de animaciones: primero lo esencial, luego los detalles. Y cada semana entregamos un avance navegable: tú ves el avance real, no un porcentaje en un correo.
Lo importante
- El rango depende del alcance: landing 2-4 semanas, sitio corporativo 4-8, e-commerce o lógica a medida 8-12.
- El contenido tardío y las revisiones sin criterio alargan el plazo más que la cantidad de pantallas.
- Las fechas se comprometen después de revisar el archivo de Figma y el motion brief, nunca a ciegas.
Preguntas frecuentes
¿El plazo cambia si ya tenemos el diseño aprobado en Figma?
Sí, a favor. Un archivo con el sistema completo —variables, estados, breakpoints— ahorra la fase de reconstrucción y puede recortar una semana. Un diseño “listo” pero sin sistema obliga a derivar decisiones durante el desarrollo, y eso se nota en el calendario.
¿Cuántas rondas de revisión incluyen los plazos?
Planificamos rondas por fase, con comentarios consolidados en un solo envío. Comentarios dispersos día a día no suman iteraciones: suman retraso, porque cada cambio pequeño interrumpe el trabajo en curso y rompe la secuencia de entregas.
¿El motion web alarga el proyecto?
Añade de tres a siete días cuando las animaciones están anotadas en el diseño. Si el motion se define después de construir, hay que reabrir componentes y volver a probar. La guía de motion web con GSAP explica cómo lo integramos sin castigar el rendimiento.
¿Qué necesitan entregarnos para que el plazo se cumpla?
Accesos, contenido en las fechas acordadas y una sola persona con capacidad de decidir. Tres voces con criterios distintos en la misma revisión cuestan más días que cualquier error técnico, porque el desarrollo espera mientras se alinean opiniones.
¿Pueden trabajar contra una fecha de campaña?
Sí, si la fecha se define al inicio y el alcance se ajusta a ella. Preferimos recortar funcionalidad por fases antes que prometer todo y entregar tarde. En proyectos con fecha dura, separamos el lanzamiento mínimo de las mejoras posteriores.