Proyecto final — Desarrollo web
Marc Borrell.
Del sector administrativo a frontend developer — un portfolio propio, decisión a decisión.
Antes de empezar — Metodología
Este proyecto se ha construido con IA, de principio a fin.
No como sustituto de aprender, sino porque, viniendo de administración/contabilidad y sin bagaje previo de programación, me permitió abordar un proyecto de nivel profesional completo — arquitectura, SEO, cumplimiento legal, migración de hosting — en el marco de tiempo del curso. La motivación no era evitar programar, sino poder construir algo real mientras aprendía.
- Sin bagaje previo de programación (fondo en administración/contabilidad)
- Proyecto completo — arquitectura, SEO, legal, migración — en el tiempo del curso
Antes de empezar — El papel de la IA
Decisiones compartidas; código ejecutado con IA.
En diseño, arquitectura y contenido, cada decisión fue compartida: planteaba el problema, valorábamos opciones juntas, y elegía con criterio propio. En el código — sobre todo PHP, fuera del temario del curso — la IA generó gran parte de los ficheros; mi papel fue revisar, depurar y aprender de cada pieza.
- Diseño, arquitectura y contenido: decisión compartida
- Código, sobre todo PHP (fuera de temario): la IA generó, yo revisé y depuré
Fase 01 — Punto de partida
El curso solo pedía un WordPress genérico.
A partir de ahí decidí construir un portfolio propio: filtros por tecnología, fichas con evolución de cada actividad, y esta misma exposición documentando el proceso.
- Requisito real del curso: WordPress genérico (ejemplo dado: panadería)
- Decisión propia: portfolio como proyecto, filtros, fichas, esta exposición
Fase 01 — Cliente y público objetivo
El cliente soy yo; el público, quien contrata.
Cliente: yo mismo, como marca profesional en transición de carrera. Público objetivo: reclutadores técnicos y responsables de contratación — no consumidores finales del sitio.
- Necesidad real: demostrar competencia técnica y criterio propio
- Público objetivo: perfiles de contratación dual-track (administrativo + frontend)
Fase 01 — User personas
Dos perfiles reales evalúan este portfolio, con criterios distintos.
Persona A — responsable de RRHH o administración, sin formación técnica profunda: valora claridad, profesionalidad y ausencia de señales de inestabilidad laboral.
Persona B — technical lead o desarrollador frontend: evalúa código, arquitectura, y si puedo defender cada decisión.
- Persona A — RRHH/administración: claridad y profesionalidad
- Persona B — technical lead: código y criterio técnico defendible
Fase 01 — Benchmarking y referencias
Sin tabla comparativa formal, pero con un criterio claro de referencia.
No se hizo un benchmarking formal. Sí hubo un ejercicio real: evitar activamente los patrones visuales genéricos de portfolios hechos con IA — como el descarte explícito de la paleta terracota, asociada a la identidad de marca de Anthropic.
- Sin benchmarking formal con tabla comparativa
- Referencia real: evitar estética genérica "hecha con IA" (terracota descartado)
Fase 02 — Arquitectura
Las tecnologías se navegan como filtros, no como menú.
El propio ejercicio del curso —este portfolio— no es una actividad más dentro del sitio: es el sitio completo, filtrable como una tecnología más.
- Taxonomía
tecnologiacomo filtro, no ítem de menú - El propio proyecto no es una actividad más — es el sitio entero
- Wireframes y prototipo de alta fidelidad en Figma, antes de escribir código
Fase 02 — Arquitectura · Datos estructurados
El contenido también se organiza para buscadores, no solo para personas.
Schema Person, sameAs con los cuatro perfiles, y llms.txt generado con IA tras investigar el estándar — visibilidad total, sin filtrar.
- Schema Person + sameAs con los cuatro perfiles
llms.txt— visibilidad total, sin filtrar
Fase 03 — Decisiones UX · Color
Burdeos y crema en vez de terracota.
Como no llevar la misma camiseta que el anfitrión de una fiesta: para que nadie confundiera este portfolio con la identidad visual de una IA.
#FAF6F0
#2B2622
#7A2E33
- Paleta final: crema
#FAF6F0/ burdeos#7A2E33 - Terracota descartado por asociarse a identidad de IA
Fase 03 — Decisiones UX · Tipografía
Fraunces aporta personalidad; Inter garantiza legibilidad.
Marc Borrell.
Fraunces — titulares
Un portfolio construido decisión a decisión, con criterio propio.
Inter — cuerpo de texto
Como un traje elegante con una camisa cómoda debajo: cada pieza cumple un papel distinto.
- Fraunces → titulares
- Inter → cuerpo de texto
Fase 03 — Decisiones UX · Jerarquía visual
El h2 baja de 36 a 24px.
En una foto de grupo, si todos gritan a la vez para salir en primer plano, nadie destaca. El hero necesita ser el único protagonista.
- h2 de sección: 24px (antes 36px)
- El h1 del hero queda como único protagonista
Fase 03 — Decisiones UX · Iconografía
Todos los iconos siguen la misma familia — incluso el que tuvo que buscarse a mano.
Como una vajilla a juego: aunque cada plato sea distinto, todos comparten el mismo estilo.
- Bootstrap Icons, estilo outline
- Un icono no disponible en la librería → creado a mano en CodePen
Fase 03 — Decisiones UX · Imágenes
El título va siempre debajo de la imagen — nunca superpuesto.
Como poner los subtítulos en una franja fija en vez de escritos sobre la propia escena: se leen igual de bien sea cual sea la foto de fondo.
- Título en texto oscuro debajo, sin overlay blanco
- Decisión de claridad tipográfica en la ficha de actividad
Fase 04 — Justificación técnica · HTML
Article para lo que se basta solo; aside para lo relacionado.
Decidido antes de escribir una sola línea de CSS — la semántica también es accesibilidad.
<article>para contenido autónomo<aside>para contenido relacionado pero no esencial
Fase 04 — Justificación técnica · CSS
Once variables, no cien valores sueltos.
Como una agenda de contactos: cambiar un color en un solo sitio, en vez de perseguirlo por cada archivo.
- 11 custom properties centralizan color y espaciado
- Cambio en un solo sitio, no archivo por archivo
Fase 04 — Justificación técnica · JavaScript
El filtro pide datos sin recargar la página.
AJAX: el navegador pide datos al servidor de fondo, sin bloquear ni recargar mientras espera la respuesta.
- AJAX: petición al servidor sin recargar (
preventDefault()) - Filtro por
tecnologia+ paginación "Cargar más"
Fase 04 — Justificación técnica · PHP
Un token de un solo uso protege el filtro contra peticiones falsas.
Como una pulsera de festival con la fecha impresa: caduca ese mismo día y no sirve para colársela a otra persona.
- Nonce = token de un solo uso, verificado en el servidor (
check_ajax_referer()) - Protege contra peticiones automatizadas externas, no contra inspección manual
Fase 04 — Gestión de contenidos
Añadir una actividad nueva no requiere tocar código.
Custom post type "actividad" + metaboxes propias ("Evolución y versiones", "Ficha de conceptos clave") permiten gestionar todo el contenido desde el panel de WordPress, sin editar ficheros.
- CPT
actividad+ taxonomíatecnologia - Metaboxes propias: contenido gestionable sin tocar código
Fase 05 — Retos
Un error 404 hasta cambiar una sola palabra.
has_archive en false por defecto — WordPress ni siquiera generaba la URL que debía usar el archivo.
has_archiveenfalsepor defecto- Corregido a
'actividades'+ reguardar permalinks
Fase 05 — Retos
Un archivo de una versión anterior que yo mismo olvidé borrar.
Detectado revisando mis propios comentarios de código, con ayuda de la IA para rastrear qué seguía en uso. Limpiado antes de la entrega final.
- Archivo de versión anterior, sin borrar tras sustituirlo
- Detectado revisando comentarios del propio código, con ayuda de IA para rastrear qué seguía en uso
Fase 05 — Retos
Migrar un WordPress vivo a otro hosting, sin experiencia previa en servidores.
117 URLs reemplazadas, base de datos migrada a mano vía phpMyAdmin y FileZilla — con la IA guiando cada paso mientras yo ejecutaba los cambios reales sobre el servidor.
- 117 URLs reemplazadas (Better Search Replace)
- Migración manual: phpMyAdmin + FileZilla
Fase 06 — Resultados obtenidos
El resultado final coincide con la propuesta gráfica de Figma.
Mismos tokens de color y tipografía, misma estructura en los tres breakpoints. Navegación y legibilidad revisadas de forma continua durante el propio proceso de simplificación del contenido técnico.
- Alta similitud con la propuesta gráfica en Figma
- Navegación y legibilidad revisadas y simplificadas
Fase 06 — Resultados obtenidos
Fácil de ampliar; con margen claro de mejora.
Gestión de contenidos sencilla para quien administra el sitio, sin tocar código. Pendiente: revisión estructural de fases, spot-check mobile completo, benchmarking formal.
- Gestión de contenidos: sencilla, sin tocar código
- Pendiente: revisión estructural, spot-check mobile, benchmarking formal
Fase 06 — Resultado y aprendizajes
Lo más difícil fue PHP y WordPress — nunca dados en clase.
PHP y WordPress fueron lo más difícil, al no formar parte del temario. Y no bastaba con tomar buenas decisiones: había que ser capaz de explicar por qué cada una era la correcta.
- PHP y WordPress: lo más difícil, no dado en clase
- Verbalizar el porqué de cada decisión, no solo tomarla