Construyo el producto entero. Y lo despliego yo.

1. ene. 2026 — Actualidad

   Senior Product & Experience Engineer

   SABAU STRAPPING · Canarias, en remoto

   Propiedad completa de servicios de producto y de IA, del modelo de datos al despliegue en Kubernetes, más el frontend de la plataforma. Ese es el título formal del puesto; el trabajo es fullstack de extremo a extremo, y así es como me presento.

   • Diseño y opero un servicio de RAG sobre las conversaciones de operaciones: contextos semánticos agrupados por tema en lugar de por tiempo, búsqueda híbrida de vectores y palabras clave sobre PostgreSQL con pgvector, y enrutado de la consulta según su amplitud.
   • Construyo la capa de agentes con LangGraph y LangChain 1.0: cliente MCP multiservidor con carga tolerante a fallos, registro de herramientas acotado por ámbito, streaming de respuestas por SSE y trazabilidad con LangSmith.
   • Levanté un servicio de memoria con tres almacenes especializados bajo un único gateway, con invalidación marcada por evidencia en lugar de sobrescritura, para poder reconstruir qué se sabía en cada momento.
   • Escribo servidores MCP propios con FastMCP sobre HTTP transmisible: autenticación por clave de API, imagen de Docker, chart de Helm con volumen persistente e Ingress restringido por lista blanca de IPs, desplegados por mí sobre el clúster de producción.
   • Mantengo el frontend en Next.js 16 y React 19 con internacionalización por etiquetas BCP 47 en nueve regiones, y pruebas en tres capas con Vitest, Testing Library y Cypress con cypress-axe.

   • Python3.12
   • FastAPI
   • LangGraph1.0
   • MCP
   • PostgreSQL + pgvector
   • Neo4j
   • NATS
   • Next.js16
   • React19
   • Kubernetes
   • Helm3
   • Docker

2. ago. 2022 —ene. 2026

   Desarrollador fullstack, con liderazgo técnico del frontend

   Talentus · Gran Canaria, España

   Plataforma de formación en línea, gestión comercial y justificación ante la administración pública: 3.784 commits míos, sexto contribuidor de unos treinta y cinco autores.

   • Dirigí la modernización integral de la interfaz: sustituí una plantilla comercial por una arquitectura propia, definí los estándares técnicos y la guía de estilo del equipo y creé una biblioteca de componentes reutilizables.
   • Mentoricé a otros desarrolladores con revisiones de código sistemáticas y coordiné el trabajo entre frontend, backend y los stakeholders en ceremonias ágiles.
   • Gestioné una migración de proveedor de infraestructura y la coordinación de varios proyectos de microservicios en paralelo.
   • Tomé propiedad de dominios enteros en Django: campañas publicitarias, automatización de redes sociales, portal público con SEO técnico y capa de gráficas estadísticas. En 2025 pasé a integraciones, con un motor de flujos con autenticación entre servicios y reintentos.
   • Optimicé consultas en producción con caminos rápido y lento e invalidación de caché, y trabajé sobre 205 ficheros de escenarios de Behave en un pipeline de GitLab CI con runners propios.

   • Django4.2
   • Django REST Framework
   • Celery
   • Django Channels
   • PostgreSQL
   • React17
   • TypeScript
   • Material UI5
   • Redux
   • Auth0
   • Behave
   • GitLab CI

05 Docencia ↓

El trabajo de empresa se cuenta por competencias y decisiones de arquitectura. Sin nombres internos, sin clientes y sin cifras de negocio.

1. 01 · IA y agentes

   Una capa de agentes completa, de cero a contenedor en un día

   El problema

   Los agentes necesitaban usar los sistemas de negocio como herramientas gobernadas, nunca con acceso directo a sus bases de datos. Hacía falta un servicio nuevo con autenticación, permisos por ámbito y streaming de respuestas, y hacía falta ya.

   El enfoque

   Lo ordené en siete pull requests numeradas: andamiaje del proyecto, configuración por entorno, autenticación, registro de herramientas acotado por ámbito, cliente MCP capaz de hablar con varios servidores a la vez con carga tolerante a fallos, streaming de respuestas por SSE y panel en React con Vite. Detrás, Nginx como proxy que guarda la clave de API en el servidor, pruebas, imagen de Docker, CI y documentación.

   El resultado

   El servicio quedó con el patrón entero puesto, no como un prototipo, y entró después en producción. Sobre esa base montamos un agente de resolución canónica de entidades con reglas de confianza y riesgo, que deriva a validación humana lo que no resuelve solo. La velocidad no vino de recortar: vino de tener el patrón de arquitectura interiorizado.

   pull requests numeradas en una jornada

   7

   del andamiaje al contenedor y la CI

   1 día

   • Python 3.12
   • FastAPI
   • LangChain 1.0
   • LangGraph
   • langchain-mcp-adapters
   • LangSmith
   • +4

2. 02 · Seguridad aplicada

   Inicio de sesión federado con OIDC, cerrado en una jornada

   El problema

   Un gestor de secretos autoalojado tenía que entrar bajo inicio de sesión único obligatorio, sin puerta trasera de usuario y contraseña. La autenticación es lo último que se puede dejar a medias.

   El enfoque

   Cliente OIDC con validación de firmas contra JWKS, endpoints de entrada y de retorno con registro de auditoría, y migración de esquema para los usuarios existentes. Añadí dos cosas que casi nadie hace: un modelo de amenazas escrito antes de tocar código y un test automatizado del ataque de confusión de algoritmo. Para no depender del proveedor real en local, monté un proveedor de identidad simulado y probé el flujo de extremo a extremo.

   El resultado

   Inicio de sesión único obligatorio en producción, con Prometheus y Grafana vigilando el servicio, scripts de copia de seguridad, restauración y diagnóstico pasados por ShellCheck, y TruffleHog en el pipeline para que no se cuele un secreto en un commit.

   del modelo de amenazas al flujo en producción

   1 día

   confusión de algoritmo cubierta por test automático

   alg=none

   • OIDC
   • OAuth2
   • JWKS
   • Vaultwarden
   • PostgreSQL 16
   • Nginx
   • +5

3. 03 · Evaluación con datos

   Tres arquitecturas de memoria para agentes, medidas antes de elegir

   El problema

   Los agentes necesitaban una memoria que no inventara y que se pudiera auditar. El mercado ofrece alternativas gestionadas de los tres proveedores grandes, y elegir por intuición se paga cada mes en la factura y cada semana en respuestas mal fundadas.

   El enfoque

   Monté un benchmark común con verdad de referencia, esquema de salida esperada y rúbrica de puntuación, más un guardián de coste en tiempo real con límite duro para que ninguna evaluación se desbocara. Sobre esa base diseñé tres almacenes especializados bajo un único gateway que enruta al escribir e integra al leer: Neo4j 5 con Graphiti para relaciones con validez temporal, Mem0 para memoria de experiencias y PostgreSQL con pgvector para hechos canónicos. Los hechos se invalidan con marca de evidencia, nunca se sobrescriben.

   El resultado

   La decisión quedó documentada con precisión y coste por operación de cada opción, no con una opinión. El servicio está en producción, instrumentado con OpenTelemetry, y su panel dibuja los grafos de memoria con @xyflow/react y dagre para que la auditoría sea visual y no una consulta a mano.

   arquitecturas comparadas sobre el mismo benchmark

   3

   guardián de coste por evaluación en tiempo real

   Límite duro

   • Neo4j 5
   • Graphiti
   • Mem0
   • PostgreSQL + pgvector
   • FastAPI
   • OpenTelemetry
   • +2

4. 04 · Backend y operación

   n8n autoalojado en modo cola, entregado con manual de emergencias

   El problema

   Había que automatizar procesos de negocio sin depender de la versión gestionada de n8n y sin que los datos salieran de la infraestructura propia. Y un servicio así no vale nada si, cuando falla de madrugada, nadie sabe levantarlo.

   El enfoque

   Lo levanté con Docker Compose: n8n en modo cola, PostgreSQL 15 como base de datos de estado, Redis 7 como cola de trabajos, y healthchecks y límites de CPU y memoria por contenedor para que un flujo desbocado no se lleve por delante al resto. La integración con el backend de la plataforma va por autenticación de token entre servicios con reintentos. Y escribí en Bash lo que hace falta cuando el servicio ya está vivo: copia de seguridad, restauración, monitor de estado, prueba de esfuerzo y escalado manual.

   El resultado

   Se entregó con dieciséis documentos de operación —arquitectura de alta disponibilidad, manual de emergencias, guía de operaciones, estrategia de copias, alertas y verificación de producción— y con las credenciales incrustadas retiradas del repositorio. Automatizar es la mitad fácil: lo que se entrega es un servicio que otra persona puede operar sin llamarme.

   documentos de operación entregados con el servicio

   16

   scripts de copia, restauración, monitor y prueba de esfuerzo

   14

   • n8n autoalojado
   • Docker Compose
   • PostgreSQL 15
   • Redis 7
   • Bash
   • Healthchecks y límites de recursos
   • +1

5. 05 · Rendimiento web

   De 46 MB a 4 MB de imágenes en un sitio en producción

   El problema

   Un restaurante con carta y galería fotográfica servía 46 MB de imágenes. En un móvil con datos, en la puerta del local y decidiendo dónde comer, eso no es una web lenta: es una web que no existe.

   El enfoque

   Procesado masivo con Pillow desde Python, WebP con fallback JPEG en un elemento picture con srcset, y preload con fetchpriority alto del elemento LCP. CSS crítico en línea en el head para pintar el primer bloque antes de que llegue el bundle, y un sistema de esqueletos de carga que detecta si el contenedor lleva imagen, vídeo o iframe y aplica la estrategia adecuada a cada uno, con fallback en CSS puro por si falla el script.

   El resultado

   46 MB de imágenes convertidos en 4 MB, con reducciones individuales de hasta el 98,4 %. El mismo trabajo dejó la carta bilingüe entera, 124 platos, servida desde un fichero de datos y con conmutación de idioma sin recarga.

   peso total de las imágenes del sitio

   46 MB → 4 MB

   reducción máxima en una sola imagen

   98,4 %

   • Astro
   • Tailwind CSS 4
   • astro:assets
   • Pillow
   • WebP
   • Cloudflare Pages

6. 06 · Arquitectura

   Analítica hexagonal: retirar al proveedor sin tocar el dominio

   El problema

   La analítica del frontend principal estaba atada a un proveedor externo. Cualquier cambio de proveedor, o cualquier caída suya, se metía dentro del código de producto, que es donde nunca debe entrar una dependencia de terceros.

   El enfoque

   Arquitectura hexagonal, con la disciplina completa: una interfaz de repositorio que define lo que el dominio necesita, un gestor de almacenamiento detrás, y una capa de transporte con circuit breaker y reintentos para que un proveedor caído no arrastre a la interfaz ni pierda eventos. El dominio no sabe quién está al otro lado.

   El resultado

   Cuando se decidió retirar al proveedor externo, se retiró: se sustituyó el adaptador y el dominio no se tocó. Ese es exactamente el argumento de puertos y adaptadores, y quedó demostrado en producción en lugar de en una pizarra.

   cambios en el dominio al retirar el proveedor

   0

   regiones servidas con etiquetas BCP 47, una de ellas RTL

   9

   • TypeScript 5.9
   • Next.js 16
   • React 19
   • Arquitectura hexagonal
   • Vitest

Lenguajes

• Python3.12
• TypeScript5.9
• JavaScript ES2020+
• SQL
• Bash
• HTML5 semántico
• CSS moderno

Frontend

• React19 y 17
• Next.js16
• Astro6
• Tailwind CSS4
• Radix UI
• Vite7
• Three.js con React Three Fiber
• Material UI5
• Anime.js4
• Zod
• React Hook Form
• TanStack Table

Backend

• FastAPI
• Django4.2
• Django REST Framework
• Celery
• Django Channels
• Uvicorn
• Gunicorn
• SQLAlchemy 2 asíncrono
• Alembic
• Pydanticv2
• asyncpg

IA y agentes

• LangGraph1.0
• LangChain1.0
• MCP (Model Context Protocol), servidor y cliente
• FastMCP
• langchain-mcp-adapters
• LangSmith
• OpenAI API
• RAG con búsqueda híbrida
• embeddings
• Graphiti
• Mem0
• spaCy
• scikit-learn

Datos y mensajería

• PostgreSQL16
• pgvector
• Neo4j 5 con grafo bitemporal
• Redis7
• MySQL y MariaDB
• MongoDB
• NATS como bus de eventos
• colas sobre Redis

Contenedores y orquestación

• Docker
• Docker Compose multientorno
• Kubernetes
• Helm3
• Traefik como Ingress Controller
• cert-manager con Let’s Encrypt
• almacenamiento NFS

Plataforma y automatización

• Linux (Rocky y Debian)
• Nginx como proxy inverso con TLS
• certbot
• systemd
• cortafuegos y acceso remoto seguro
• n8n autoalojado en modo cola

Observabilidad

• Prometheus
• Grafana con paneles y alertas
• structlog
• OpenTelemetry

Seguridad

• OIDC y OAuth2 con validación JWKS
• JWT entre servicios
• Vaultwarden autoalojado
• Content Security Policy
• TruffleHog en el pipeline (CI)

CI/CD y despliegue

• GitHub Actions
• GitLab CI
• GitHub Container Registry
• publicación por etiqueta de versión
• Cloudflare Pages con cabeceras y redirecciones declarativas

Calidad y pruebas

• pytest con soporte asíncrono y paralelo
• Vitest
• Jest
• Cypress con cypress-axe
• Behave (Gherkin)
• mypy en modo estricto
• Ruff
• ESLint
• Prettier
• ShellCheck

Móvil (proyecto de aprendizaje)

• React Native0.74
• Expo SDK51
• Expo Router
• NativeWind
• Jest 30 con jest-expo

Herramientas

• uv
• pnpm
• npm
• Git
• GitHub CLI
• Playwright

En esta lista solo hay tecnología con commits míos detrás. Por eso no verás Terraform, ni nube pública, ni lenguajes que no escribo: una lista corta y verdadera responde mejor en una entrevista técnica que una larga. El bloque de móvil es un proyecto de aprendizaje, y lo dejo aquí por lo que vino después: volví dos años más tarde, documenté que la cobertura era cero y lo cerré con 45 pruebas en siete grupos.