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 soporteEDNONmar. 2024 → actualidad2 a 7 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 webIndra · prácticasoct. → dic. 20233 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 soporteEDNONago. 2022 → sept. 20231 a 2 m
Mismas funciones que el puesto actual.
Técnico y administrador de sistemasDoezos Consultoría IT2019 → 2020—
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
Lo mismo que hacía con una incidencia a las tres de la mañana, aplicado a escribir código. Tres etapas en orden, cada una con un proyecto que la demuestra.
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.
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 / Vercel) 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.
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. Los siete puntos de cada ficha marcan en qué proyectos está viva.
frontend/
React
Next.js (App Router)
Tailwind CSS
Zustand
backend/
Node.js + Express
NestJS
PostgreSQL
Prisma
infra/
Docker
solo en el build
Fly.io / Render
Vercel
tooling/
TypeScript
Vitest + Playwright
pnpm
GitHub Actions