Vendes campañas, contenido y estrategia a empresas grandes. Cada cliente tuyo tiene su sitio web. Tú no. En la reunión el portafolio en PDF hace el trabajo, y lo hace bien. El problema llega después, cuando alguien te escribe «¿me pasas un link?» y no hay nada que mandar.
Así llegó una agencia creativa con clientes corporativos. Había mirado varios dominios y ninguno existía todavía. Sin hosting, sin gestor de contenidos, sin un solo texto escrito para la web. Lo que sí tenía era el PDF de credenciales y una carpeta con fotos y videos de campañas. Con eso alcanzó.
Lo único que había era el PDF
La primera decisión no fue de diseño ni de tecnología. Fue de contenido. Todo lo que apareciera en el sitio saldría del portafolio en PDF: los textos, las cifras, los logos de clientes, las fotos de proyectos. Nada inventado. Si el PDF no lo decía, el sitio tampoco.
Suena a camisa de fuerza. Nada más lejos de la realidad. Piensa en la objeción natural de una agencia de diseño cuando le encarga un sitio a otro equipo: «el diseño lo podemos hacer nosotros». Claro que pueden. Por eso el texto, la marca y la selección de proyectos se quedaron en manos del cliente. Lo que quedaba por vender era la estructura, el movimiento y la ingeniería, y ahí nadie discutió.
Tres direcciones en una semana
En una semana el cliente tenía tres versiones navegables del mismo sitio:
- Una página única, sobria, con las secciones del PDF en el mismo orden: quiénes somos, método, servicios, trabajo, resultados, clientes, contacto.
- Una versión experimental que tomaba la idea detrás del nombre de la marca y la volvía la forma de recorrer la página.
- Una versión de alto impacto, con desplazamiento suave, un carrusel de proyectos anclado que cambia de color con cada proyecto y un manifiesto que aparece línea por línea.
El cliente descartó la primera intro por básica, y eso fue una buena señal, porque le importaba el oficio. La tercera fue la que se publicó.
¿Cómo salen tres direcciones en siete días? Por una decisión técnica que suena aburrida: páginas estáticas, sin framework y sin proceso de construcción. Cada ajuste al movimiento se hacía a mano y se veía al instante en el navegador.
Sobre la referencia visual: el cliente admiraba el sitio de una agencia europea. Tomamos su mecánica de desplazamiento y nunca su paleta. Un conteo de colores del sitio original nos corrigió una versión que había subido un tono secundario a superficies completas.
Cada efecto salió con su plan B. En pantallas táctiles el carrusel anclado se vuelve desplazamiento normal con flechas. Si el visitante tiene activado «menos movimiento» en su sistema, las animaciones se apagan y el texto se lee igual. Y sin JavaScript, el contenido sigue ahí.
Por qué no empezamos con un gestor de contenidos
La pregunta llegó con la propuesta y volvió después: ¿y WordPress? La respuesta fue «todavía no». Con el diseño en movimiento, un gestor habría hecho más lento cada cambio. Y había otra razón más simple: no sabíamos qué iba a querer editar el cliente. Cualquier panel armado en ese momento habría sido una adivinanza.
En su lugar, el sitio estático se publicó en el dominio del cliente y se dejó vivir un tiempo.
Meses después: el editor llegó con los cambios
Los primeros pedidos de mantenimiento llegaron como llegan siempre: cuatro mensajes de WhatsApp de una línea cada uno. Los convertimos en cuatro tareas, cada una con su causa y su evidencia. Un ejemplo. El menú no navegaba a las secciones porque la capa del menú detenía el desplazamiento suave y, al cerrarse, cancelaba el salto. Se arregló cerrando el menú antes de desplazar, y se probó en el celular y en la computadora.
Con esos pedidos, y con los que siguieron, quedó claro qué cambiaba de verdad: textos, fotos, proyectos, datos de contacto. Ese fue el momento de pasar a un gestor de contenidos.
Pusimos una condición estricta para el traspaso: el sitio nuevo tenía que verse idéntico al estático. El tema de WordPress envuelve el marcado original tal cual, sin reinterpretarlo, y un complemento propio maneja la lógica. La prueba de aceptación fue una comparación de píxeles entre los dos sitios, en computadora y en celular. Tenía que salir sin diferencias, y salió.
¿Y el editor de bloques? ¿Y un constructor de páginas? Los miramos y los descartamos: cualquiera de los dos habría peleado con la coreografía de desplazamiento que se ajustó a mano.
| Momento | Qué había | Por qué |
|---|---|---|
| Semana 1 | Tres direcciones estáticas | Iterar el diseño y el movimiento sin fricción |
| Lanzamiento | Sitio estático en el dominio del cliente | El contenido del PDF no cambiaba todavía |
| Meses después | Gestor de contenidos con panel propio | Había pedidos reales de edición que justificaban el panel |
| Después | Segundo idioma y blog | El cliente lo pidió al notar etiquetas sin traducir |
El cliente edita contenido, nunca estructura
El panel tiene dos pantallas. Una es una lista larga de textos, en el mismo orden en que aparecen en el sitio. La otra es una grilla de proyectos que se reordena arrastrando. No hay constructor de páginas. Nada de lo que el cliente pueda tocar rompe el marcado.
Cada texto editable arranca con el contenido que ya estaba publicado. Una verificación automática comprueba que esos valores por defecto coinciden letra por letra con el sitio, así que el sitio está correcto aunque nadie abra el panel jamás.
Al agregar el segundo idioma, el cliente notó en cuestión de horas seis etiquetas de sección que seguían en español dentro de la versión en inglés. Buen ojo. Una auditoría encontró más de cincuenta textos fijos en el código. La decisión fue que el panel no le pusiera límite a lo que se puede editar: se rediseñó con secciones plegables y buscador de campos, y hoy expone más de cien campos en dos idiomas, incluidos títulos de documento, etiquetas de accesibilidad y textos alternativos de imágenes.
El panel de edición se diseñó alrededor de los cambios que el cliente ya había pedido.
Qué quedó
- Un sitio en el dominio de la agencia, en español y en inglés, con el diseño de alto impacto que se aprobó en la primera semana.
- Un traspaso de estático a gestor sin diferencias visuales, medido con comparación de píxeles.
- Un panel donde el equipo de la agencia edita todo el contenido sin poder alterar la estructura.
- Un blog, cuyos primeros artículos los escribió la propia agencia.
Si tu agencia está en la misma situación, la guía sobre cómo trabajar con un partner de desarrollo explica cómo repartir el trabajo, y en nuestros proyectos hay más ejemplos de lo que construimos con agencias.
Preguntas frecuentes.
¿Se puede hacer un sitio web en una semana?
Una primera versión sí, siempre que el contenido ya exista y no haya un gestor de contenidos de por medio. Aquí el material era un portafolio en PDF y el sitio se construyó como páginas estáticas. Lo que más demora un sitio es el contenido, no el código.
¿Por qué no empezar con WordPress desde el inicio?
Porque el diseño todavía se estaba decidiendo y el movimiento se ajustaba a mano. Un gestor desde el día uno habría hecho más lenta cada iteración. Se agregó cuando el cliente pidió cambios reales y ya se sabía qué necesitaba editar.
¿El cliente puede romper el diseño desde el panel de edición?
No. El panel expone textos, imágenes y proyectos, pero no la estructura. Cada texto arranca con el contenido publicado, así que el sitio se ve igual aunque nadie toque el panel.
