Un generador con IA te da un frontend en React funcionando en una tarde. Un CMS le da a tu equipo algo que puede editar el lunes. La distancia entre ambas cosas costaba antes dos semanas de tiempo de desarrollo, y son esas dos semanas las que hacen que «una web en un día» suene a mentira.
No lo es, pero solo si haces los pasos en el orden correcto y sabes cuáles no se pueden acelerar. Este es el recorrido completo, desde un prompt en blanco hasta una web publicada en WordPress o HubSpot, con las partes que la gente se salta marcadas a medida que aparecen.
El mismo recorrido funciona en los dos extremos del mercado, pero conviene ser preciso sobre qué ahorra, porque la respuesta cambia según en cuál estés.
Para una pequeña o mediana empresa, la construcción era lo que hacía inasumible una web a medida. No el diseño ni los textos: las dos semanas de desarrollo entre tener un diseño y tener algo editable. Quita ese bloque y una web nativa y bien hecha deja de ser una decisión de presupuesto. Después la gestiona el equipo de marketing: cambiar un titular o añadir páginas son tareas de contenido, no tickets, así que el coste no vuelve en forma de mantenimiento.
Para un equipo corporativo, la limitación nunca fue poder pagar a un desarrollador: es que los desarrolladores están ocupados. Las páginas de campaña esperan semanas detrás del trabajo de roadmap, y la fecha de la campaña no se mueve para acomodarse a esa cola. Esto saca la construcción del backlog de ingeniería por completo y, como el resultado es un tema nativo y no una capa de page builder, resuelve de paso las preguntas de gobernanza que harán IT y marca: ningún plugin extra en el stack, ninguna licencia que renovar, ninguna capa de renderizado ajena entre tu contenido y tu CMS.
La lectura honesta en ambos casos: lo que desaparece es el bloque mecánico, reconstruir el marcado en HubL o Gutenberg, conectar cada campo editable, rehacer las plantillas de blog y los formularios. En una web típica eso es la mayor parte de las horas. Desglosamos un proyecto de 300 horas línea a línea por si quieres ver las cuentas. La estrategia, los textos y las aprobaciones siguen llevando exactamente lo mismo que siempre.
La mayoría de las empresas no escriben prompts en un generador con IA, y no hace falta. Lo habitual es que una persona freelance o una agencia de diseño cree el concepto inicial y el resto se termine a partir de ahí. Si esa es tu situación, lo útil no son las herramientas, sino saber quién sostiene qué y dónde apruebas tú.
La persona freelance o la agencia crea la idea inicial en Figma. No la web entera: el concepto. La dirección visual, el sistema de diseño y las pantallas clave suficientes para establecerlo: una home, una página de contenido típica, los componentes que se repiten. Ahí está el pensamiento, y es lo que de verdad estás pagando.
La IA la termina. A partir de ese concepto, un generador con IA lo extiende hasta la web completa: las páginas que faltan, los estados que nadie dibujó, los textos de secciones que solo existían como una caja gris. Sigue el sistema de diseño que se le ha dado, así que la página veinte encaja con la primera. Este es el cambio que importa en lo comercial: encargas un concepto en lugar de veinte diseños de página, y esas son facturas muy distintas.
Si el diseño ya está terminado y prefieres saltarte ese paso, un archivo de Figma acabado entra directamente en transjt sin fase de código intermedia. Ambos caminos terminan en el mismo sitio.
transjt lo convierte en una web real dentro de WordPress o HubSpot: todas las páginas, cada bloque reutilizable, el blog, los formularios. Ni una imagen de una web ni una plantilla cerrada: la cosa de verdad, en el sistema que tu equipo ya usa.
A partir de ahí, tu equipo se encarga. Cambiar un titular, sustituir una foto, añadir la página de campaña del próximo trimestre: eso pasa a ser trabajo de quien escribe los textos, no una petición que entra en una cola de desarrollo.
Hay dos puntos de control en los que conviene insistir: la aprobación del diseño, antes de que se construya nada, y media hora en el CMS después, con la persona que va a mantener la web, confirmando que puede editar lo que se le prometió. Todo lo que hay entre esos dos puntos es mecánica.
Qué CMS. Decídelo ahora, no después de construir. No cambia cómo prototipas, pero sí qué conectas en el paso 5 y quién tiene que darte acceso. Si todavía lo estás valorando, las diferencias prácticas las tratamos aparte: esta guía funciona igual para los dos.
La restricción del stack. Esta es la que arruina días. La mayoría de generadores con IA recurren por defecto a Next.js con server components, y ni WordPress ni HubSpot tienen un runtime de Node esperando para ejecutar una capa de servidor. Dilo en el prompt, antes de generar nada: React con Vite, enrutado en cliente, sin SSR, sin server components. Descubrirlo cuando el diseño ya está aprobado cuesta reconstruirlo.
Lovable, Bolt, v0, Claude Code, Replit, rocket, Figma Make: usa el que prefieras. A la conversión le da igual. Lo que sí importa es qué le pides.
Tres cosas que conviene especificar mientras aún estás prompteando, porque añadirlas después cuesta más que pedirlas:
Reserva la mañana para esto. Es el único paso en el que el pensamiento es tuyo, y el que merece las horas.
transjt lee el proyecto real y no una captura de pantalla, así que el código tiene que estar en un sitio del que se pueda leer. Ese sitio es GitHub: piensa en él como la unidad compartida donde vive el código. La mayoría de generadores con IA lo envían allí con un clic; si el tuyo no puede, tu desarrollador o tu agencia lo hará en un par de minutos.
Si el repositorio es privado, este es el paso que en silencio cuesta una hora: invita a github.com/transjt o comparte un enlace de solo lectura antes de seguir. Son dos minutos que bloquean todo lo demás.
En transjt, añade tu cuenta de GitHub, elige el repositorio y selecciona la rama que acabas de subir. Escoge tu destino, WordPress o HubSpot, y lanza la conversión.
La vista previa se ejecuta antes de que te comprometas a nada, así que este es el momento de comprobar que ha vuelto lo que esperabas: las páginas que construiste, los componentes que nombraste, el contenido que escribiste.
Esta es la parte que antes eran las dos semanas. La exportación corre sin supervisión y el tema terminado llega a tu cuenta en unas dos horas, lo bastante poco como para caber en la jornada y dejar margen para revisar después.
Lo que obtienes no es una carpeta de código que alguien todavía tiene que traducir. Es un tema nativo: módulos HubL o bloques de Gutenberg, las páginas montadas, cada componente reutilizable disponible como módulo editable, las plantillas de blog conectadas y los formularios con sus campos ya puestos.
Lánzala antes de comer y haz otra cosa mientras corre. De eso trata este paso: es el único que no te necesita delante.
El tema tiene que aterrizar en algún sitio, y ese sitio hay que prepararlo antes. En HubSpot, autoriza el portal en el que vas a desplegar y comprueba que de verdad tienes permisos de publicación, porque en la mayoría de empresas los tiene otra persona. En WordPress, instala y activa el plugin de transjt en el sitio de destino y asegúrate de que está en la versión actual; un plugin desactualizado es la causa más habitual de una importación que funciona a medias.
Las peticiones de acceso están en la cola de otras personas, y una cola no se acorta trabajando hasta más tarde. Si haces una sola cosa a primera hora del día, que sea esta.
Ahora abre la web en el propio editor del CMS y léela como lo haría alguien que la visita. Estás comprobando dos cosas distintas a la vez.
¿Está todo? Cada sección, cada página, el listado del blog y al menos una página de detalle. Lo que faltaba en el prototipo también falta aquí.
¿Es editable donde tiene que serlo? Entra en los módulos que tu equipo de marketing va a cambiar de verdad (titular, tarjetas de funcionalidades, filas de precios) y confirma que son campos y no texto fijo. Este es también el momento de añadir páginas que nunca estuvieron en el prototipo, usando los componentes que ya tienes. Ese es el retorno de haberlo hecho nativo: una página nueva es ahora una tarea de contenido.
Un frontend generado no tiene por qué saber nada de tu CRM, de tu analítica ni de tu presencia en buscadores. Seis cosas que conectar, y ninguna lleva mucho:
Prueba en un móvil real, no en una ventana de navegador redimensionada. Más de la mitad del tráfico del día del lanzamiento llega desde ahí, y una ventana de escritorio a 375 px no te dice qué hace un dispositivo real con tu sección hero.
Después recorre la web como lo haría un visitante: pulsa cada elemento de navegación, cada botón, cada tarjeta. Envía el formulario una vez más. Recorre la página con el tabulador para comprobar que nada queda inaccesible. Y mira las imágenes más grandes: un prototipo no tiene por qué haberlas optimizado, y una imagen de hero recién salida de un generador con IA suele pesar varios megabytes.
Publica y después haz las tres cosas que la gente se salta porque el día ya acabó: abre tú mismo la URL en vivo y pulsa la acción principal, envía el sitemap en Search Console y espera a ver llegar un envío real del formulario antes de cerrar el portátil.
Si la web va en un dominio nuevo, el cambio de DNS es lo último que de verdad no depende de ti: ponlo en marcha por la mañana junto con los accesos al CMS, no a las seis de la tarde.
| Cuándo | Qué ocurre |
| Primera hora | Decide el CMS. Pide acceso al portal o instala el plugin. |
| Por la mañana | Construye el frontend en tu generador con IA, con contenido real en cada página y la restricción del stack dicha desde el principio. |
| Antes de comer | Sube a GitHub, da acceso al repositorio, conéctalo en transjt y lanza la conversión. Corre mientras comes. |
| Primera hora de la tarde | Llega el tema. Revísalo en el editor del CMS: cada sección presente, lo correcto editable. |
| Media tarde | Formularios al CRM, tracking, metadatos, favicon, redirecciones. Prueba el formulario de principio a fin. |
| Última hora de la tarde | Prueba en dispositivo real, recorrido completo, revisión del peso de las imágenes. Arregla lo que se rompa. |
| Final del día | Publica. Abre la URL en vivo, envía el sitemap, espera a ver llegar un envío real. |
Decir esto con claridad es lo que sostiene el resto del plan.
Una migración no cabe. Mover una web existente implica mapear redirecciones, auditar contenido y conservar URLs: es otro proyecto con otra forma. Tampoco cabe una web hecha de una docena de widgets con estado: si tu prototipo en realidad es una aplicación, estás convirtiendo una aplicación, y eso es un trabajo mayor. Las aprobaciones tampoco se comprimen: si tienen que firmar tres responsables, el calendario es suyo y no tuyo. Y los textos definitivos casi nunca llegan a tiempo; las palabras reales nunca tienen la longitud que el diseño dio por supuesta, así que cuenta con pequeños ajustes de maquetación en cuanto estén.
Lo que sí cabe en un día es la construcción. Que, hasta hace poco, era justamente la parte por la que esperaba todo lo demás.
Si quieres ver en qué se convierte tu propio repositorio antes de comprometerte a nada, la conversión se ejecuta primero como vista previa: empieza en IA a página. Y si estás leyendo esto porque acaban de mover una fecha, el manual del proyecto urgente cubre el orden cuando no hay margen.