APIs, integraciones, automatización, sistemas observables.
Sin datos simulados, sin proyectos de juguete.
Empecé bastante pronto tocando cosas «demasiado grandes» para el nivel que tenía. Mientras mucha gente empezaba haciendo CRUDs básicos, a mí me obsesionaba entender cómo funcionaban sistemas reales detrás de una web: colas, caches, concurrencia, despliegues, sockets, infraestructura. El punto de inflexión fue cuando dejé de ver el backend como «hacer APIs» y empecé a verlo como diseñar sistemas que no se rompan cuando de verdad los usas. Ahí me enganché completamente.
Gran parte del aprendizaje vino literalmente de romper cosas. Deploys que tiraban servicios enteros, proxys mal configurados, bugs de concurrencia imposibles de reproducir, migraciones de PostgreSQL hechas rápido, middleware generando redirects absurdos en producción. Pero justo ahí es donde más aprendí. Me di cuenta de que disfruto muchísimo más debuggeando sistemas complejos y encontrando cuellos de botella reales que construyendo interfaces bonitas. Cuando consigo entender por qué algo falla a bajo nivel y arreglarlo de forma elegante, entro en «flow».
Con el tiempo acabé construyendo proyectos cada vez más orientados a arquitectura real: pipelines automatizados, SSE en tiempo real, Docker multi-servicio, reverse proxies con nginx, sistemas de scraping y trends, automatización de contenido, herramientas internas. Nunca me interesó demasiado hacer «apps genéricas». Me interesa construir infraestructura útil, rápida y estable para productos que tienen movimiento real.
Esta lista es lo que utilizo primero, no lo que tolero. Elegido por años de uso real en producción, no por leer anuncios.
Un número pequeño de sistemas reales, cada uno en producción para usuarios reales. No es un portfolio de demos a medio terminar.
Plataforma editorial multi-tenant que rastrea 11 fuentes de tendencias, puntúa oportunidad, genera y revisa artículos, y los publica en 13 sitios de nicho en 12 idiomas. Postgres, workers pg-boss, integración con Claude, pipelines de QA propios, y un dashboard con tail en vivo de cada cola.
kramaru.esCuatro estrategias polyvps funcionando 24/7 con smart take-profit, gates horarios y circuit breakers. Dinero real, no un backtest. Dashboard diario de métricas, kill-switch, log de auditoría de cada entrada.
Motor de settlement de picks de fútbol sobre OpenFootball más enriquecimiento Sofascore, conectado a un stack Dockerizado con hardening por contenedor. NGINX, Postfix, claves de cifrado de Server Actions fijas para prevenir ataques de replay de cabecera tras un incidente pasado.
POS Flutter Desktop, backend Node, MySQL, impresión térmica, integración WhatsApp. Clientes reales, offline-first.
Demo público en mkir.es: un único proceso .NET 8 fan-outa eventos de cambios en base de datos a muchos navegadores vía Server-Sent Events. Cero dependencias en cliente, HTML plano renderizando triggers de Postgres según ocurren.
mkir.esLa versión larga de un proyecto que normalmente comprimo en una frase. Las decisiones duras, las cosas que rompí, y lo que está realmente en vivo.
TopSec nació para resolver agregación, sincronización y visualización de datos en tiempo real sin depender de infraestructuras gigantes ni stacks excesivamente pesados. El reto era mantener datos vivos, rápidos y consistentes mientras múltiples servicios interactuaban a la vez.
Separar claramente qué debía vivir en backend .NET y qué debía resolverse desde Next.js. Un caso sutil hizo obvia la línea: las rutas /api más el middleware de next-intl generaban redirects 307 hacia /es/api/*. Técnicamente válido, prácticamente roto. Endpoints realtime y de stats fallaban en silencio bajo ciertos locales.
El parche que nadie te pide escribir es el que justifica la tarifa del ingeniero: en lugar de seguir parcheando rutas individuales, rehice el matcher del middleware para excluir /api por completo. Cambio visual pequeño, arquitectónico enorme.
Optimizar demasiado pronto es malo. Ignorar el rendimiento desde el diseño es peor. Principio de trabajo
La otra decisión fue mantener PostgreSQL como núcleo principal en vez de mover partes a NoSQL «porque sí». Para este tipo de sistema, consistencia y capacidad de queries complejas valían más que las décimas que pudieras arañar. Lo aburrido está bien cuando lo aburrido es correcto.
Producción se cayó una vez porque asumí que una imagen Docker realmente se había reconstruido. El código «nuevo» seguía comportándose igual que el viejo. El culpable real era npm ci fallando silenciosamente porque faltaba package-lock, dejando una build inconsistente. Perdí horas debuggeando lógica de aplicación cuando el problema era el pipeline.
Posiciones fuertes ganadas por incidentes de producción, no por Twitter. Si alguna te tensa, probablemente nos vamos a llevar bien.
Decir que no hace el sí más fiable. Estos son los proyectos donde no sería el fichaje adecuado.
Freelance y contracting desde 2022. Abierto a roles remote-first o híbridos en Málaga y la Costa del Sol cuando el proyecto justifica el desplazamiento. No me interesan entornos extremadamente corporativos donde la ingeniería desaparece bajo proceso.
El email tiene la respuesta más rápida. LinkedIn para presentaciones en frío, GitHub para código.