API, integrazioni, automazione, sistemi osservabili.
Nessun dato simulato, nessun progetto giocattolo.
Ho iniziato presto mettendo le mani su sistemi troppo grandi per il livello che avevo. Mentre molta gente intorno a me scriveva CRUD da principianti, io ero ossessionato da quello che succede davvero dietro un prodotto reale: code, cache, concorrenza, deploy, socket, infrastruttura. Il punto di svolta è stato il giorno in cui ho smesso di vedere il backend come «fare API» e ho iniziato a vederlo come progettare sistemi che non si rompono nel momento in cui la gente li usa per davvero. È lì che mi sono attaccato per sempre.
Gran parte di quello che so è arrivato dal rompere cose. Deploy che hanno buttato giù interi servizi, proxy mal configurati, bug di concorrenza impossibili da riprodurre, migrazioni PostgreSQL fatte di fretta, middleware che generava redirect assurdi in produzione. È esattamente lì che ho imparato di più. Mi sono accorto che mi piace molto di più fare debug di sistemi complessi e inseguire colli di bottiglia veri che costruire interfacce belle. Capire perché qualcosa fallisce a basso livello e sistemarlo in modo elegante è quello che più si avvicina al flow per me.
Con il tempo i miei progetti si sono spostati verso architettura vera: pipeline automatizzate, SSE in tempo reale, stack Docker multi-servizio, reverse proxy con nginx, sistemi di scraping e tendenze, automazione dei contenuti, tooling interno. Le «app generiche» non mi sono mai interessate molto. Voglio costruire infrastruttura utile, veloce e stabile per prodotti che si muovono davvero.
Questa lista è quello che uso per primo, non quello che tollero. Scelto da anni di usura in produzione, non leggendo annunci.
Un piccolo numero di sistemi reali, ognuno in produzione per utenti reali. Non un portfolio di demo a metà.
Piattaforma editoriale multi-tenant che traccia 11 fonti di tendenze, valuta opportunità, genera e revisiona articoli, e li pubblica su 13 siti di nicchia in 12 lingue. Postgres, worker pg-boss, integrazione Claude, pipeline QA proprie e una dashboard con tail dal vivo di ogni coda.
kramaru.esQuattro strategie polyvps in funzione 24/7 con smart take-profit, hourly gates e circuit breaker. Denaro vero, non un backtest. Dashboard giornaliera di metriche, kill-switch, log di audit di ogni entrata.
Motore di settlement di pronostici calcio su OpenFootball più arricchimento Sofascore, collegato a uno stack Dockerizzato con hardening per container. NGINX, Postfix, chiavi di cifratura Server Actions fisse per prevenire attacchi di replay di header dopo un incidente passato.
POS Flutter Desktop, backend Node, MySQL, stampa termica, integrazione WhatsApp. Clienti reali, offline-first.
Demo pubblica su mkir.es: un singolo processo .NET 8 diffonde eventi di cambiamento del database a molti browser tramite Server-Sent Events. Zero dipendenze lato client, HTML semplice che disegna trigger Postgres in tempo reale.
mkir.esLa versione lunga di un progetto che di solito comprimo in una frase. Le decisioni difficili, le cose che ho rotto e quello che è davvero in vita.
TopSec esiste per aggregare, sincronizzare e visualizzare dati in tempo reale senza appoggiarsi a infrastrutture giganti o stack troppo pesanti per il prodotto. Il brief era semplice a dirsi e duro a consegnarsi: tenere i dati vivi, veloci e coerenti mentre più servizi si parlano contemporaneamente.
Tracciare una linea netta tra ciò che vive nel backend .NET 8 e ciò che si risolve da Next.js. Un caso sottile ha reso la linea ovvia: le rotte /api più il middleware next-intl producevano redirect 307 verso /es/api/*. Tecnicamente validi, in pratica rotti. Endpoint in tempo reale e di stat fallivano in silenzio sotto certi locale.
La patch che nessuno ti chiede di scrivere è quella che giustifica la tariffa dell'ingegnere: invece di sistemare le regole di redirect una per una, ho riscritto il matcher del middleware per escludere /api per intero. Cambio visivo piccolo, architettonico enorme.
Ottimizzare troppo presto è male. Ignorare la performance dal primo giorno è peggio. Principio di lavoro
L'altra decisione è stata tenere PostgreSQL come unica fonte di verità. Per questo prodotto, coerenza e capacità di scrivere query complesse valevano più di qualsiasi guadagno di velocità che potessi spremere da un NoSQL. Noioso va bene quando noioso è corretto.
La produzione è caduta una volta perché ho dato per scontato che un'immagine Docker fosse davvero stata ricostruita. Il codice «nuovo» continuava a comportarsi come quello vecchio. Il vero colpevole: npm ci falliva in silenzio perché mancava package-lock, lasciando la build inconsistente. Ho passato ore a fare debug della logica applicativa per quello che era un problema di pipeline.
Posizioni forti guadagnate con incidenti di produzione, non su Twitter. Se qualcuna di queste ti irrigidisce, probabilmente andremo d'accordo.
Dire no rende il sì più affidabile. Questi sono i progetti dove non sarei l'assunzione giusta.
Freelance e contracting dal 2022. Aperto a ruoli remote-first o ibridi a Málaga e sulla Costa del Sol quando il progetto giustifica lo spostamento. Non interessato ad ambienti molto corporate dove l'ingegneria sparisce sotto il processo.
L'email ha la risposta più rapida. LinkedIn per le presentazioni, GitHub per il codice.