Antes de escribir la solución, quiero entender qué se rompe de verdad
Soy desarrollador full-stack, titulado en Desarrollo de Aplicaciones Web. Pero antes de tocar el primer componente ya llevaba años dando soporte a sistemas en producción 24×7, y eso cambia cómo abordo un problema: primero busco la causa, no el parche más rápido. Debajo van tres ejemplos reales de eso, no adjetivos sueltos.
- DAW (2024) · ASIR (2018)
- Galicia, España
- Español · Gallego · Inglés
- Primera posición como desarrollador
Por dónde he pasado
Cuatro puestos antes de dedicarme al desarrollo. Cada uno se despliega con lo que de verdad aporta.
Técnico de redes y soporte2 a 9 m
Compaginado con la búsqueda de mi primera posición como desarrollador. Gestión, soporte y monitorización de una red corporativa 24×7 — datos, voz, WiFi y seguridad — con resolución de incidencias de primer nivel, tickets, informes periódicos y copias de seguridad.
Desarrollador de aplicaciones web3 m
Backend sobre arquitectura de microservicios: endpoints REST, mantenimiento de la interfaz en React y refactorización de servicios existentes dentro del flujo de revisión del equipo.
Técnico de redes y soporte1 a 2 m
Mismas funciones que el puesto actual.
Técnico y administrador de sistemas—
Desarrollo y mantenimiento de webs de clientes en PrestaShop y WordPress, con el hosting, el dominio y el servidor detrás gestionados también por mí.
Cómo trabajo
No son tres virtudes en una lista — es el mismo criterio dejando un rastro distinto cada vez, con un proyecto real detrás de cada uno. Elige cuál mirar.
Cómodo en código que no es mío
En las prácticas en Indra no partía de cero: eran endpoints REST sobre microservicios ya en producción, con su propio flujo de revisión. Entender una convención ajena antes de tocarla es un hábito, no una excepción.
- ✓ tcp
- ✓ dns
- ✓ tls
Diagnóstico antes que reinicio
Dando soporte a una red corporativa en 24×7 aprendes a no conformarte con 'no responde': hay que mirar dónde se rompe de verdad. Es el mismo criterio detrás de NetPulse: checks reales por TCP, DNS y TLS, no un ping que solo dice sí o no.
Por fases, sin dejarlo roto entre pasos
CodeQuest RPG era una prueba de concepto abandonada a medias. Lo reconstruí en fases: la migración a TypeScript fue archivo por archivo, comprobando build y juego jugable en cada paso, en vez de una reescritura de golpe que se rompe a mitad sin que te enteres.
En Sistema de Reservas, la API y el frontend son dos repositorios separados que se despliegan por separado (Fly.io / Cloudflare Workers) y solo se hablan por una variable de entorno — el mismo criterio de tratar un servicio ajeno como una caja negra con un contrato, no como código propio a medio camino.
API y frontend separados, cada uno con su contrato y su despliegue.
Ver Sistema de ReservasTodos los proyectos de esta web los he decidido yo. No he trabajado todavía en un equipo de producto grande, con roadmap ajeno y prioridades que no controlo — es exactamente lo que busco ahora.
Docker y los PaaS los uso para desplegar lo mío, pero no he operado contenedores a escala ni montado observabilidad de verdad (métricas, trazas, alertas). Sé lo que falta porque lo he visto funcionar desde el otro lado.
Mi experiencia con datos es relacional. NoSQL, colas y todo lo que va con procesamiento asíncrono lo he leído, no lo he puesto en producción.
El papel real de la IA en mi trabajo
Escribo estos proyectos dirigiendo a Claude, no a mano línea a línea. No lo escondo porque no hay nada que esconder: acelera la escritura, pero no decide qué construir, ni por qué, ni cuándo algo está terminado.
## La arquitectura, el modelo de datos y qué se descarta los decido yo antes de pedirle nada a la IA — no le paso el problema entero y espero una app hecha.
## Reviso cada diff como si fuera de un compañero de equipo: nada se sube sin que entienda por qué está ahí y qué pasaría si lo quitara.
## Si no puedo defender una línea en una entrevista, no está terminada — el criterio de 'hecho' no es que compile, es que sea mía de verdad.
Stack, con el motivo de cada elección
No es una lista de logos: cada tecnología está aquí por un motivo concreto, el mismo que aparece en los casos de estudio. Abre una ficha para leerlo y ver en cuántos proyectos está viva.
frontend/
React
Rendimiento y estabilidad en interfaces con pantallas que se montan y desmontan mucho, no solo formularios estáticos.
Next.js (App Router)
Server components para no exponer claves de API al navegador y cachear datos con fetch + revalidate, sin montar una capa de caché propia.
Tailwind CSS
Utilidades para iterar rápido en la maquetación sin mantener una hoja de estilos propia a mano.
Zustand
Un único store organizado por dominios, sin la ceremonia de Redux para el estado que de verdad necesita ser global.
backend/
Node.js + Express
API REST clásica cuando el cliente ya es un proyecto frontend separado, sin necesidad de un framework full-stack.
NestJS
Estructura por módulos y servicios que encaja con patrones de estrategia (un tipo de comprobación, una clase) y con schedulers propios.
PostgreSQL
Relaciones reales (FKs, UNIQUE constraints) y agregados con índices compuestos que encajan mejor en un modelo relacional que en un documento.
Prisma
Migraciones versionadas y modelo tipado, en vez de escribir SQL a mano en cada cambio de esquema.
infra/
Dockersolo en el build
Build multi-stage con runtime final solo con el compilado y las dependencias de producción — imagen más pequeña, sin el toolchain de compilación.
Fly.io / Render
PaaS con capa gratuita, barata para un proyecto de portfolio, a cambio de cold starts que hay que mitigar explícitamente (keepalive, reintentos).
Cloudflare Workers
Despliegue automático desde main vía Wrangler, en el edge y sin los cold starts del resto del stack, sin infraestructura propia que mantener.
tooling/
TypeScript
Tipado en cliente y servidor; strict cuando el proyecto lo permite desde el principio, progresivo cuando se parte de JS existente.
Vitest + Playwright
Vitest para la lógica de negocio sin levantar navegador; Playwright para un e2e real del flujo completo cuando hace falta.
pnpm
Workspaces para compartir tipos entre backend y frontend en un monorepo sin duplicar interfaces que se desincronizan.
GitHub Actions
CI (lint, typecheck, test) en cada push y pull request, gratuito para proyectos personales.