Así construí mi sitio web profesional con Claude en 2 horas

Este sitio lo construyó Claude Code en unas dos horas: 17 pantallas y estados, la lista de testers con doble confirmación, correos, imágenes para compartir y la infraestructura lista para desplegar. Hoy corre en Cloudflare. Suena a magia, pero no lo es. Funcionó porque el día anterior pasé 12 horas diseñándolo con Claude, y cuando empezó el código ya no quedaba nada por adivinar.

Aquí está todo lo que necesitas para hacer tu propia versión: las herramientas, los prompts completos (en versión corta y lista para copiar), los diseños feos incluidos y los errores.

Lo que vas a necesitar

• Claude en el navegador (claude.ai) para diseñar. Usé Opus 5.5 con artifacts: Claude dibuja cada pantalla en un lienzo que puedes abrir, comentar y compartir.
• Claude Code (documentación) para escribir el código.
• Tu material. Tu historia en pocas frases, qué quieres que haga la gente en tu sitio, tus fotos o videos, y ejemplos de tu contenido. Ningún skill inventa esto por ti, y es lo que hace que el diseño se sienta tuyo.
• Dos skills de diseño, que son los que evitan que todo salga con cara de plantilla.

taste-skill: dirección de arte

Para instalarlo en Claude Code:

/plugin marketplace add Leonxlnx/taste-skill/plugin install taste-skill@taste-skill

awesome-design-md: referencias de sitios reales

Sirve para decir «quiero el rigor de Linear» y que la IA sepa exactamente qué significa.

En mi chat estaba instalada como el skill design-md-references. Si no la tienes como skill, funciona igual: descarga los DESIGN.md que te interesen y pásaselos a Claude.

Paso 1: el brief

El brief es el documento más importante de todo el proceso. El mío tenía unas 1 300 palabras. Esta es su estructura, resumida y lista para que la llenes con lo tuyo:

Tres partes hacen la mayor diferencia. «Lo que NO quiero» le cierra el paso a lo genérico. El objetivo le da un criterio para decidir qué va arriba y qué sobra. Y pedir que explique qué toma de cada referencia te deja ver si entendió o solo está decorando.

Paso 2: iterar sin miedo a descartar

Antes del detalle, el mapa completo de las 12 horas de diseño:

Ahora, paso por paso. Claude cargó los dos skills, eligió referencias de la biblioteca y me propuso tres direcciones. Una era una placa de circuito tomada de Warp, IBM Carbon y Wired. Otra, una hoja de datos inspirada en Cursor y PostHog. La tercera, un banco de pruebas con la rejilla de IBM y el contraste de Vercel. Elegí la tercera, pero se lo dije claro: «se ven muy genéricas». Claude desarrolló el inicio completo de esa dirección:

Después cometí un error. Le pasé el sistema de diseño de mis reels para que el sitio tuviera «una sola identidad». Lo siguió al pie de la letra:

No estaba mal hecho, pero no era yo. Lo que funciona en un reel de 30 segundos no funciona en un sitio donde alguien decide si confía en ti. Le respondí con todo lo que no me gustaba:

Llegaron 4 opciones nuevas. No me gustó ninguna, nada:

Se veían como afiches, no como el sitio de un ingeniero serio. Los skills ya estaban cargados desde el principio, así que el problema no era ese. Faltaba que Claude viera sitios reales que se sienten como yo quería:

Claude revisó en el navegador cinco productos para desarrolladores, tres sitios personales de ingenieros conocidos y uno en español. Estos son, con lo que vale la pena mirar en cada uno:

Su conclusión fue que lo que los hace verse profesionales es justo lo contrario de lo que me había mostrado:

• Titulares moderados, no gigantes.
• Ancho de lectura contenido y centrado.
• Grises bien escalonados en vez de campos de color saturado.
• Líneas finas para ordenar las listas.
• El producto real como imagen principal, no ilustraciones.
• Mucho aire.

Esa lista vale más que cualquier skill. Guárdala y úsala para revisar tus propios diseños. Con ella salieron estas cuatro propuestas:

Producto tenía lo que buscaba: se ve como una herramienta, y la terminal deja claro en un segundo que aquí se programa de verdad. A partir de ahí trabajé una pantalla a la vez. Primero fijé la dirección y las reglas:

Después repetí este ciclo unas 10 veces, una por pantalla:

Y después de cada pantalla, casi siempre, la misma revisión:

Así salieron las 12 pantallas con todos sus estados, en claro y oscuro, a 1440 y 390 píxeles. También los 4 correos, las imágenes para compartir y el logo.

Paso 3: el handoff, una sola fuente de verdad

Le pregunté a Claude si Claude Code podía leer el chat de diseño. No puede. Puede abrir un artifact, pero solo saca un resumen, no las 76 vistas con sus estados. La solución es un paquete de handoff dentro del repo: archivos que Claude Code lee completos en cada sesión.

Esto es lo que entregó, y lo que Claude Code recibió el día siguiente:

1CLAUDE.md               reglas del repo y cómo verificar2design/3├── README.md           mapa y orden de autoridad4├── DESIGN.md           principios, tipografía, layout, color, movimiento5├── tokens.css          variables CSS (claro, oscuro, código siempre oscuro)6├── componentes.md      cada componente: anatomía, estados, accesibilidad7├── pantallas/          una ficha por pantalla (01-inicio.md … 12-404.md)8├── flujos.md           registro con doble confirmación, baja, 404 (Mermaid)9├── implementacion.md   rutas, datos, endpoints, SEO, analítica10├── pendientes.md       lo que falta definir y las decisiones tomadas11├── contenido/          textos y contenido de ejemplo en JSON12├── correos/            4 plantillas HTML13├── fuentes/  marca/  imagenes/14└── referencia/15    ├── capturas/       cada pantalla y estado, por tramos16    └── html/           el HTML interactivo de cada pantalla

El README dice qué manda cuando dos archivos no coinciden: primero DESIGN.md y los tokens, después las fichas, después las capturas. Sin esa regla, la IA elige por su cuenta. Este es un pedazo del CLAUDE.md:

1## El diseño es la fuente única de verdad2 3Antes de construir o cambiar cualquier pantalla, lee:41. design/README.md: mapa de la carpeta y orden de autoridad.52. design/DESIGN.md y design/tokens.css: reglas y valores.63. La ficha de la pantalla en design/pantallas/.74. Sus capturas en design/referencia/capturas/<pantalla>/.8 9No inventes medidas, colores, textos ni comportamientos: están en design/.10Si algo no está, revisa design/pendientes.md; si sigue sin estar, pregunta antes de decidir.11 12## Reglas que no se negocian13 14- Código, terminal y prompts siempre oscuros, también en el tema claro.15- Escala de espacio única: 8, 12, 16, 24, 32, 48, 64 px.16- Accesibilidad AA: contraste ≥ 4.5:1, foco visible, un h1 por página.17- El sitio no favorece a ninguna IA.18 19## Cómo verificar cada pantalla20 211. Captura a 1440 y 390 px, en claro y oscuro.222. Compárala con design/referencia/capturas/<pantalla>/.233. axe-core sin violaciones.244. Sin desplazamiento horizontal a 320 px.

Paso 4: dos horas de código con Claude Code

Abrí Claude Code en una carpeta con el paquete adentro y empecé por el plan, sin código:

Su primera propuesta fue Astro con Cloudflare. Como conozco Next.js y AWS, la cambiamos por Next.js con Amplify, DynamoDB para la lista y SES para los correos. Vale la pena discutirlo: es la decisión más cara de cambiar después.

Y lo comprobé: al final lo desplegué en Cloudflare, con Next.js en Workers, D1 para la lista y Email Service para los correos. El cambio me tomó otra sesión completa con Claude Code.

Antes de la primera pantalla, le pedí la herramienta que más hizo por la calidad:

Por dentro usa dos herramientas de código abierto:

Con eso, cada pantalla tenía una definición objetiva de «terminada», y Claude podía mirar sus propias capturas y corregir sin que yo revisara cada detalle:

$ pnpm verify /sobre-mi 06-sobre-miclaro  escritorio ✓ axe · alto 2894 vs ref 2895claro  celular    ✓ axe · alto 5137 vs ref 5137oscuro escritorio ✓ axe · alto 2894 vs ref 2895oscuro celular    ✓ axe · alto 5137 vs ref 5137✓ sin desplazamiento horizontal a 320 px

Después le di permiso para avanzar solo. Este prompt es la razón de que fueran dos horas y no un día de ida y vuelta:

La lista de supuestos al final es clave. Sin ella, la IA se detiene a preguntar cada cosa, o peor, decide sin decirte. Con ella terminé con unas 20 decisiones pequeñas anotadas en un solo lugar, para revisarlas de una vez.

Al final, una auditoría de todo el sitio con sesiones reales:

Lo que salió mal

No fue perfecto, y estos errores son la parte que más enseña:

• El tema parpadeaba. La librería de temas que usó ponía el tema equivocado antes de cargar la página. Lo detectó una prueba de accesibilidad y la reemplazó por un script propio de 20 líneas.
• Las imágenes para compartir no leían las fuentes. La herramienta que las genera no acepta el formato de fuente del sitio. Tuvo que usar otra versión de las mismas fuentes.
• Una verificación que mentía. Una página se marcaba como correcta, pero en realidad redirigía a otra y medía esa. Al encontrarlo, hizo que la verificación falle cuando una página redirige.
• El rendimiento quedó en 92–94, no en el 95 que pedía el diseño. Bajarlo más significaba cambiar cómo se ven los titulares, y preferí no hacerlo.

Resultados

Lo que aprendí

1. El diseño es la parte lenta, y está bien. Las 12 horas de diseño son lo que hizo posibles las 2 de código. Si saltas el diseño, la IA lo inventa, y casi siempre sale genérico.
2. Los skills no reemplazan tu criterio. Ayudan, pero el cambio real llegó cuando dije qué no me gustaba y pedí referencias reales.
3. Dale una forma de comprobar su trabajo. El script que compara cada pantalla con el diseño hizo más por la calidad que cualquier prompt.
4. Deja que anote supuestos en vez de preguntar. Avanza sin detenerse y tú decides al final, con todo a la vista.
5. Revisa tú lo que importa. El error del encabezado lo encontré usando el sitio, no leyendo el código.

Hazlo tú: la lista completa

1. Instala taste-skill y ten a mano awesome-design-md.
2. Escribe tu brief con la plantilla del paso 1. Dedícale una hora: es lo que más rinde.
3. En Claude, pide 2 o 3 direcciones y descarta sin culpa. Si nada te convence, pide que estudie sitios reales y te diga qué los hace verse profesionales.
4. Diseña el inicio hasta que te encante. Después, una pantalla a la vez, siempre «bajo la misma línea».
5. Pide el paquete de handoff con el prompt del paso 3.
6. En Claude Code: plan sin código, script de verificación, y luego etapa por etapa con la lista de supuestos.
7. Usa tu sitio como lo usaría tu visitante. Ahí aparece lo que ninguna prueba busca.

Esto es lo mínimo que debe traer tu handoff antes de pasarlo a código:

1# Handoff de [tu proyecto]2 3## Sistema4- Colores (claro y oscuro), tipografía, escala de espacio, radios.5- Reglas que no se negocian (accesibilidad, qué nunca hacer).6 7## Pantallas (una ficha por pantalla)8- Ruta, propósito, secciones en orden.9- Estados: vacío, cargando, error, éxito.10- Textos finales, copiados tal cual.11- Capturas a 1440 y 390 px, en claro y oscuro.12 13## Para la IA (CLAUDE.md)14- Dónde está el diseño y qué manda si dos fuentes no coinciden.15- Cómo verificar cada pantalla antes de darla por terminada.16- Qué hacer si algo no está definido: preguntar, no inventar.