Suele empezar igual. Han movido la fecha de una campaña. El martes sale un anuncio de financiación. Un competidor ha lanzado algo y alguien de dirección quiere una página de respuesta publicada antes de que acabe la semana. Y lo que existe ahora mismo es un archivo de Figma, o un proyecto de Lovable que alguien montó el fin de semana, y un CMS que no espera ninguna de las dos cosas.
El instinto en ese momento es ponerse a construir de inmediato. Ese instinto es lo que convierte un trabajo de dos días en uno de cinco. Los proyectos urgentes fracasan por el orden mucho más que por el esfuerzo: las horas se gastan, solo que en las cosas equivocadas, en el orden equivocado, y lo que de verdad bloquea el lanzamiento aparece la última tarde.
Esta es la secuencia que funciona, tanto si partes de un archivo de diseño como de código generado.
«Urgente» abarca tres proyectos distintos con tres definiciones distintas de «terminado», y confundirlos es el error más caro de todo el proceso. Antes que nada, nombra en cuál estás.
| Tipo | Qué tiene que ser cierto de verdad | Qué puedes aplazar |
| Pitch o demo | Se ve bien en un tamaño de pantalla, en un ordenador, durante veinte minutos | Editabilidad en el CMS, formularios, SEO, todo lo que quede por debajo de la tercera diapositiva |
| Lanzamiento real | URL pública, funciona en móvil, los formularios captan leads, marketing puede editarla el lunes | Pulido de diseño, animación, la segunda y la tercera plantilla de página |
| Fecha interna | Alguien de dirección ve avance y el equipo deja de estar bloqueado | Casi todo: es la que más se sobreconstruye |
La trampa es tratar un pitch como un lanzamiento. Una demo no necesita CMS en absoluto, y construir uno te cuesta el día que necesitabas para el relato del pitch. La trampa inversa es peor: tratar un lanzamiento como una demo, entregar algo que marketing no puede editar y encargarte tú de cada cambio de texto por correo durante los seis meses siguientes.
Si es un lanzamiento de verdad, el resto de este artículo es para ti. Si es una demo, deja de leer, haz capturas del prototipo de Figma y vete a ensayar.
Antes de convertir un solo componente, anota tres cosas. Lleva una hora, y es la hora que salva el proyecto.
Uno: la lista de páginas, priorizada. No «la web», sino las páginas reales, en el orden en que tienen que existir. La mayoría de lanzamientos urgentes necesitan una página. Un número sorprendente necesita una página y una de agradecimiento. Si tu lista tiene once entradas, el problema no es la fecha, es el alcance.
Dos: quién la edita después del lanzamiento y qué va a cambiar. Esto determina si necesitas módulos de CMS de verdad o si bastaría con HTML fijo. Si la respuesta es «marketing cambiará el titular y las tres tarjetas de funcionalidades cada semana», necesitas componentes editables, y ese requisito tiene que estar visible desde el principio en lugar de añadirse el segundo día.
Tres: la dependencia que no controlas. Todo lanzamiento urgente tiene algo que queda fuera de tu propio teclado: permisos de publicación en el CMS, un cambio de dominio o de DNS, un contenedor de tracking que pertenece a otra persona, una aprobación legal o de marca. Eso tiene colas, y una cola no se acorta trabajando hasta más tarde. Localízala en la primera hora y ponla en marcha esa misma mañana, porque es el único punto de la lista en el que el esfuerzo no ayuda.
Que un archivo de Figma se convierta bien o mal depende casi por completo de decisiones tomadas antes de que tú llegaras. No puedes reestructurar el sistema de diseño de otra persona con una fecha encima, pero sí puedes dedicar cuarenta minutos al puñado de cosas que de verdad determinan la calidad del resultado.
Lovable, Bolt, v0, Claude Code, Figma Make, Google Stitch: el resultado varía en estilo, no en naturaleza. Obtienes un frontend en React que funciona, normalmente atractivo, normalmente adaptable, y estructuralmente ajeno tanto a WordPress como a HubSpot. Esa distancia no es un fallo de la herramienta. Esas herramientas se hicieron para producir una aplicación, y lo que tú necesitas es un tema.
Con una fecha encima, tres cosas concretas del código generado causan casi todo el dolor.
El código generado mete tu titular directamente en el JSX. Eso está bien para un prototipo y es fatal para un CMS, porque cada cadena que vive en el código es una cadena que marketing no puede editar. La conversión tiene que extraer ese texto y convertirlo en un campo, y cuanto más limpia sea la separación entre estructura y texto en el original, mejor sale.
Un acordeón construido como estado de React se convierte, en un tema de CMS, en un pequeño fragmento de JavaScript sin librerías o en un elemento details nativo. Un carrusel pasa a ser la librería de carrusel que el tema ya carga. Nada de esto es difícil, pero si tu página está hecha de una docena de widgets con estado, estás convirtiendo una aplicación, y eso es otro tamaño de trabajo. Con dos días, recorta los extras interactivos antes de empezar, no después.
Las clases de Tailwind, el CSS-in-JS y las librerías de componentes dan por hecho que habrá un bundler en tiempo de ejecución. Un tema de CMS entrega CSS plano. Es el más mecánico de los tres problemas y el que menos debería preocuparte, pero es la razón por la que «pega el código y ya» nunca funciona, y conviene saberlo antes de prometérselo a un cliente.
En la práctica significa una cosa: mete el código en un repositorio. transjt lee desde GitHub, así que la ruta más rápida de un prototipo hecho con vibe code a un tema de CMS es subir el proyecto, conectar el repositorio y dejar que la conversión lea el código real en lugar de una captura de pantalla. Si el repositorio es privado, invita a github.com/transjt o comparte un enlace de solo lectura: ese paso pilla a mucha gente justo en el momento en que no se puede esperar.
Estas son las cuentas honestas. El trabajo entre «tenemos un diseño o un prototipo» y «marketing puede editar esto en HubSpot o WordPress» se divide en unos cuatro bloques:
Los tres primeros son mecánicos y, en una landing típica, son la mayor parte de las horas: se recorren a mano justo cuando no te sobra nadie de desarrollo. Esa es la parte que transjt automatiza: lo apuntas al archivo de Figma o al repositorio y produce un tema nativo, con las páginas, los componentes reutilizables, las plantillas de blog y los formularios ya conectados, en lugar de una carpeta de código que alguien todavía tiene que traducir.
La cifra relevante para un proyecto urgente no es lo lista que sea la conversión, sino que la exportación corre sin supervisión y el tema terminado llega a tu cuenta en unas dos horas. Dos horas caben dentro de una jornada y dejan margen para revisar después, con lo que la conversión deja de ser aquello que hace esperar a la fecha, y la fecha vuelve a tratar de contenidos y aprobaciones, que es de lo que debería tratar.
Lo que no hace es inventarse el cuarto bloque. Alguien sigue revisando el comportamiento adaptable, sigue comprobando que el formulario realmente escribe en el CRM y sigue leyendo la página en un móvil de verdad. Presupuéstalo. Son un par de horas, no un par de días, pero no es cero, y cualquier plan que asuma cero es el plan que se va a torcer.
Supongamos que el encargo llega el jueves por la mañana y la página tiene que estar publicada el viernes por la tarde. Así es una versión que de verdad funciona.
| Cuándo | Qué ocurre |
| Jue, primera hora | Triaje. Lista de páginas, quién la edita, la dependencia que no controlas. Recorte de alcance acordado por escrito. |
| Jue por la mañana | Preparar el origen: repaso de Auto Layout y de nombres en el archivo de Figma, o subir el proyecto de vibe code a GitHub y conectar el repo. |
| Jue, antes de comer | Lanzar la conversión. Corre mientras haces otra cosa: de eso se trata. |
| Jue por la tarde | Poner en marcha la dependencia que no controlas: pedir permisos de publicación, solicitar el cambio de DNS, mandar la página a aprobación. Las colas empiezan ahora, no el viernes. |
| Jue, al final del día | Llega el tema. Primera revisión: ¿está cada sección?, ¿es editable el contenido donde tiene que serlo? |
| Vie por la mañana | Contenido real en lugar de texto de relleno. Esto siempre lleva más de lo que nadie calcula. |
| Vie, primera hora de la tarde | Revisión adaptable en un móvil real, no en una ventana de navegador redimensionada. Arreglar lo que se rompa. |
| Vie, media tarde | Tracking, metadatos, la parte legal. Revisión con los responsables y corte firme para cambios. |
| Vie, última hora | Publicar. Después abre tú mismo la URL en vivo y pulsa la acción principal antes de decirle a nadie que está listo. |
Fíjate en lo que falta a propósito: no hay ningún bloque llamado «construir el tema». Ese es el bloque que antes se comía los dos días, y moverlo a una ventana de dos horas sin supervisión es lo que hace que el resto del calendario sea viable.
Pregunta a cualquiera que se haya saltado un lanzamiento urgente qué salió mal y casi nadie dice la construcción. Dicen que el texto no estaba listo, o que la aprobación volvió a las seis del viernes con tres cambios.
El texto. El texto de relleno esconde el problema hasta el último momento posible. Un titular que funciona en un marco de diseño no es el mismo titular cuando se sitúa sobre un párrafo real, y el texto real nunca tiene la longitud que el diseño dio por supuesta. Mete las palabras de verdad el viernes por la mañana, no por la tarde, y cuenta con pequeños ajustes de maquetación una vez estén ahí: es lo normal, y sale mucho más barato que descubrirlo una hora antes del lanzamiento.
Las aprobaciones. La revisión no es un paso, es una cola con otras personas dentro. Nombra a quien aprueba en la primera hora, dile cuándo estará lista la página y cuándo se cierra su ventana, y mándale algo a lo que reaccionar antes de lo que resulta cómodo. Quien ve la página por primera vez a las cuatro del día del lanzamiento siempre encuentra algo, porque es el único momento que le has dado.
Ambas son cuestiones de contenido, no de construcción, y eso es justamente el argumento para automatizar la construcción. Las horas que liberas son las que necesitan estas dos, y son las dos que deciden si la fecha se sostiene.
Todo proyecto urgente ofrece los mismos desvíos. Cada uno parece ahorrar una tarde; cada uno se cobra una semana más adelante, normalmente de alguien que no estaba en la sala.
Incrustar el prototipo en un iframe. Publicado en diez minutos, e invisible para los buscadores, roto en móvil, imposible de editar. Seguirá ahí dentro de dieciocho meses, porque nadie programa nunca el reemplazo.
Instalar un page builder «solo para esta página». El plugin no se va nunca. Trae su propia capa de renderizado, su propio perfil de rendimiento y su propia renovación de licencia, y cada página construida después hereda la dependencia. Tanto WordPress como HubSpot tienen una capa de contenido nativa; úsala.
Dejar el texto fijo en el código «porque ya lo haremos editable después». El después no llega. Lo que llega es un cambio de titular por correo un domingo.
Abrir una ronda de revisión sin límite. Un «¿alguna idea?» la tarde del lanzamiento invita a las ideas. Fija el corte cuando fijas la fecha (cambios admitidos hasta una hora concreta, lo posterior pasa a la lista de la semana que viene) y ponlo por escrito antes de que nadie se haya formado una opinión.
Un proyecto urgente está terminado cuando otra persona puede seguir con él, no cuando se ve bien. Dos cosas deberían cumplirse antes de cerrar el portátil.
La persona responsable de la página puede cambiar el texto sin ti. Si el tema salió de una conversión, los componentes ya son editables en el propio editor del CMS: enséñale una edición mientras todavía estás delante. Una demostración de cinco minutos evita quince días de correos.
Y los componentes son reutilizables. No por orden: porque el siguiente encargo urgente ya se está formando, y una página hecha de módulos con nombre y reutilizables convierte la campaña siguiente en una tarea de contenido en vez de otra construcción. Ese es el retorno acumulado de hacerlo nativo la primera vez, y es el argumento ante quien paga.
El patrón que hay debajo de todo esto cabe en una línea: en un proyecto urgente el recurso escaso no son las horas, es la atención. Todo lo mecánico que pueda correr sin ti debería estar corriendo sin ti, y las horas que te quedas deberían ir a las decisiones que solo puede tomar una persona: qué dice la página, para quién es y quién tiene que decir que sí antes de publicarla.
Si quieres ver en qué se convierte tu propio archivo o repositorio antes de comprometerte a nada, la conversión se ejecuta primero como vista previa: empieza desde un diseño en Figma a HubSpot o Figma a WordPress, o desde código generado en IA a página.