- Progetto personale
- Progetto personale: full stack, evoluto nel corso di diversi anni
- 2021 - 2026
Bollette Calcio
Un'app di scommesse calcistiche virtuali cresciuta per cinque anni: da un backend Express a NestJS, poker e un assistente AI.

- React
- TypeScript
- Vite
- Redux Toolkit
- NestJS
- Express
- MySQL
- Redis
- XState
- Flask
- LangChain
- TensorFlow
- Docker
Il problema
Un progetto personale nato a gennaio 2021: una web app per scommettere sulle partite di calcio con denaro virtuale, con una classifica degli utenti, e in seguito slot machine e poker multiplayer. È rimasto attivo per circa cinque anni ed è diviso su sei repository, quindi è soprattutto la storia di come è cambiata l'architettura.
Cosa ho realizzato
v1 (2021-2022): un'API Express, MySQL e Redis con una UI React. Le scommesse venivano refertate da uno scraper Python lanciato come processo figlio, con i token salvati su Redis.
v2 (dal 2023): lo scraper è diventato un microservizio Flask separato e il backend è stato riscritto in NestJS con TypeORM, JWT e Swagger. Il poker gira su WebSocket, con il tavolo modellato come macchina a stati XState, bot e un log degli eventi.
Modello delle quote: una rete neurale con embeddings delle squadre che genera le quote della Serie A, così l'app non dipende da un'API di quote a pagamento.
Agente (dal 2025): un assistente che compila la schedina a partire da frasi come "checkout 20". La UI è passata a Vite, React 19 e Tailwind 4.
Scelte interessanti
L'agente ha avuto due design. Il primo, costruito con LangChain e OpenAI, era una pipeline di step specializzati: riconoscimento dell'intento, estrazione delle squadre con un parser strutturato, fuzzy match della partita con embeddings e una soglia di similarità, poi esito e importo. Il secondo, da ottobre 2026, sostituisce prompt ed embeddings con domande tipizzate (scelte multiple e sì/no) poste in parallelo a un modello decisionale. Restituisce probabilità invece di testo, quindi le risposte sono template. Usa soglie di confidenza e, quando non è sicuro, ricade sul primo estrattore.
La schedina viene mostrata nella UI e il checkout resta un'azione esplicita dell'utente, così è una persona a confermare prima che il denaro si muova, anche se virtuale.
Cosa farei diversamente oggi
La prima versione accoppiava il backend a uno scraper lanciato come processo figlio, ed è per questo che l'ho estratto in un servizio a sé. Lo scraping di siti di terze parti resta fragile per natura.
L'agente tiene la schedina in memoria, quindi va persa al riavvio. L'ho documentato ma non l'ho risolto.
Non c'è una valutazione sistematica dell'agente, e le soglie di confidenza della nuova versione sono una stima iniziale, non calibrata. Il passaggio dai prompt alle decisioni tipizzate è stato motivato da affidabilità, costi e facilità di debug, ma non ho misurato la differenza.
Il modello delle quote usa come input solo le due squadre, senza feature su forma o infortuni, e non ho metriche di accuratezza.
Ti serve qualcosa di simile?
Raccontami il tuo progetto: di solito rispondo entro un giorno lavorativo.
Contattami