Ventotto sistemi, descritti con sincerità.

Django 5.2, PostgreSQL e MariaDB, rendering lato server, senza SPA. Circa 120 modelli distribuiti su quattordici app e 170 template. Deploy su hosting condiviso con Passenger, con cron invece di Celery perché lì nessun processo in background sopravvive.

Conversions API lato server con deduplica rispetto al Pixel del browser su un event id condiviso, dati personali sottoposti ad hash, eseguita su un thread in background e che fa fail open. Driver per stampanti fiscali con una modalità degradata a driver nullo: un dispositivo irraggiungibile segna lo scontrino come in attesa invece di bloccare la vendita. Un'API a bearer token per un client Windows di rilevazione presenze, esterno al repository, che carica snapshot di attività al minuto. Un sistema di ruoli risolto per priorità - superuser, poi gruppo, poi scheda del personale di clinica - che alimenta dieci dashboard diverse da un'unica base di codice.

Django 5.2, PostgreSQL, Stripe, page builder GrapesJS nell'admin. Venticinque modelli distribuiti su quattro app che contengono modelli.

Il backend di IA sta dietro un unico tipo di risultato normalizzato, con tre implementazioni intercambiabili - mock, API gestita e self-hosted - selezionate da una sola variabile d'ambiente: il prodotto gira quindi end to end senza alcun provider di IA collegato e senza modifiche al codice. Una pipeline clinica di caricamento → analisi → osservazioni → piano di trattamento → voci di costo, con ogni osservazione che porta la propria fascia di confidenza. Un middleware di attribuzione first-touch che raccoglie quattro click id di piattaforme pubblicitarie in un report di funnel dal lead al cliente pagante.

Django 5.2, MySQL, modeltranslation su tre app, CKEditor 5, builder di landing page GrapesJS.

Una macchina a stati dalla richiesta di appuntamento all'approvazione: la richiesta di un visitatore resta in attesa finché il personale non la approva, e solo allora viene creata o abbinata una scheda paziente e si materializza un appuntamento reale. Ogni lead salva le sue risposte due volte - in JSON e come righe separate - insieme a IP, user agent, referrer, geografia e l'insieme completo di UTM e click id Meta. Le landing page di campagna sono montate fuori dal routing con prefisso di lingua, così il traffico a pagamento non finisce mai su un redirect di lingua.

Django 5.2 con DRF e JWT, PostgreSQL, Celery e Redis, hashing Argon2, quarantanove app locali. React con Vite e Tailwind sul front, Flutter per il mobile. Sentry, gunicorn con gevent.

Un motore di raccomandazione che classifica sette stati del sistema nervoso a partire da un check-in, applica filtri di idoneità rigidi, comprime la priorità in una scala a sei punti perché il contesto batta la popolarità, e poi campiona per softmax invece di prendere l'argmax - così l'intero catalogo resta raggiungibile invece di ridursi sempre agli stessi venti contenuti. Un quarto slot è riservato alla scoperta e campionato per recency. Gira su query grezze del driver invece che sull'ORM, perché viene eseguito su ogni schermata. Il retrieval si fonda su circa trentamila soluzioni strutturate estratte da all'incirca novantacinque libri, con un prompt che vieta al modello di rispondere attingendo alle proprie conoscenze generali e con un ramo esplicito per le situazioni di crisi. Un harness Monte Carlo fa girare il motore reale su sessioni sintetiche - cinquantamila check-in in un'esecuzione, settantamila sessioni bilanciate in un'altra - verificando che nessuno stato di crisi riceva una scheda inadatta e che nessuna scheda sia irraggiungibile. Ha anche fatto emergere una vera lacuna di rilevamento, che è esattamente lo scopo di un harness. La scelta del provider e ogni chiave API si risolvono da una tabella modificabile nell'admin prima di ricadere sull'ambiente, così provider e chiavi ruotano senza un deploy.

Django 5.1, MySQL in produzione con PostgreSQL e SQLite come fallback per lo sviluppo, Celery e Redis con fallback in modalità eager, blocco account con django-axes, profiling Silk, builder GrapesJS. Quaranta modelli distribuiti su sei app.

La finalizzazione del pagamento è raddoppiata di proposito ed è idempotente - la stessa routine viene eseguita dal webhook Stripe e dalla pagina di ritorno, e termina subito se la prenotazione risulta già pagata: un webhook perso non può quindi far perdere una prenotazione pagata. Il channel manager non offre alcuno schema di firma dei webhook, così l'endpoint è autenticato da un segreto nel percorso dell'URL, con un test che lo svuota per dimostrare che fa fail closed. Una macchina a stati delle prenotazioni instrada i soggiorni confermati sul canale diretto e i blocchi su un canale separato; la proprietà senza id di canale viene invece abbinata localmente tramite slug. Ogni email in uscita viene salvata prima dell'invio da un backend di posta su misura.

Django 5.1, MySQL, Celery con fallback in modalità eager quando Redis non c'è, admin Unfold con uno studio incluso nel repository, HTMX e Alpine sopra Tailwind. Circa quaranta modelli distribuiti su dieci app. Flutter per entrambi i client mobile, JWT in secure storage.

Un checkout in corso viene tenuto come prenotazione temporanea e promosso a prenotazione reale solo quando Stripe conferma la sessione, così i checkout abbandonati non bloccano mai disponibilità. Sei tipi distinti di documento fiscale condividono mixin comuni per le parti e per le righe, invece di essere un unico modello di fattura con un flag di tipo. Le schede degli ospiti si riconciliano tra i canali attraverso un livello di ospite canonico, con registri separati per persone fisiche e aziende: la stessa persona arrivata da una OTA e da una prenotazione diretta è una sola scheda. Ogni segreto delle integrazioni si risolve prima dal database, con una cache di sessanta secondi, così le chiavi ruotano a caldo.

Django 5.0, MySQL, modeltranslation su otto lingue, Tailwind e Alpine da CDN senza passaggio di build. Trentotto modelli.

Conferma della prenotazione con un codice email a sei cifre, con rate limit per IP, un tetto di cinque tentativi, scadenza a quindici minuti e un'attesa prima del rinvio. Token firmati a durata limitata danno a un ospite anonimo accesso alla propria pagina di prenotazione per ventiquattro ore, senza account. Il prezzo viene ricalcolato lato server a ogni salvataggio, a partire da una tabella di fasce di durata a cinque livelli incrociata con il livello di assicurazione, con lo sconto applicato solo al subtotale del noleggio - mai preso per buono dal client.

Django 5.1, MySQL, Redis e Celery, DRF con JWT e OpenAPI, admin Unfold, modeltranslation e parler. Un'applicazione React 19 costruita con Vite e distribuita già compilata. Quattordici app, sette lingue con cataloghi di traduzione completi.

Scoring dei lead con un modello di linguaggio e ricerca web: le risposte del form, le UTM, i click id, l'esito dell'autenticazione e lo stato do-not-call vengono assemblati in un dossier e valutati in una fascia, con una motivazione e un'azione consigliata, usando una chiave dedicata a ciascun cliente. Uno stack di conformità in tre parti - scrub completo con rilevamento del tipo di linea e dei numeri mobili, controllo dei litiganti seriali e ricerca di numero riassegnato rispetto a una data di consenso. Il tenant si risolve dall'header Host con una cache di cinque minuti, e ogni invio del form viene ricontrollato rispetto al cliente di quell'host, così un lead che attraversa due tenant è strutturalmente impossibile. Il form builder salva un HMAC di ogni codice di verifica invece del codice, e ogni casella di consenso scrive un record immutabile del testo esatto, dell'IP e dell'URL.

Django 5.2 con Wagtail, due datastore - PostgreSQL per lo stato operativo e ClickHouse come raccoglitore ad alto volume del tracking - Redis, Celery con beat e Flower, DRF più un livello JWT scritto a mano per il mobile. Quarantasei modelli nella sola app centrale.

Ogni fornitore è associato a uno dei tre sotto-punteggi - raggiungibilità, autenticità, intento - eseguiti in parallelo in un thread pool e mediati in un voto composito con pesi regolabili dall'admin. Gli adapter che vanno in errore o che si astengono escono dal denominatore invece di contare zero, e qualunque adapter bloccante impone d'ufficio il voto più basso. L'insieme dei segnali comprende biometria comportamentale, fingerprinting TLS, profondità di scroll e cadenza di compilazione del form, accanto a tre sotto-segnali prodotti da modelli di linguaggio. L'instradamento verso l'acquirente filtra su credito, orari di lavoro, capacità giornaliera e settimanale, verticale e geografia, poi risolve la parità sul carico delle ultime ventiquattro ore prima della priorità. Ogni chiamata in uscita verso un fornitore scrive una riga di log con endpoint, stato e riepilogo della risposta, proprio per poter riconciliare il costo per lead di ciascun fornitore.

Flutter con Riverpod, Dio e go-router, secure storage per i token. Un'app Django complementare che espone il registro dell'admin via REST.

I permessi non vengono reimplementati: l'API mappa i verbi HTTP sui permessi view, add, change e delete di Django, e ricerca, paginazione e ordinamento degli elenchi arrivano direttamente dalla configurazione di ciascuna classe admin. Aggiungere un modello all'admin Django lo aggiunge all'app mobile. Un'app gemella per gli acquirenti riprende i quattordici set di temi per cliente dell'applicazione web, legge quello attivo al login e lo mette in cache, così all'avvio a freddo non c'è un lampo con l'identità visiva sbagliata.

Django 5.2 con Wagtail, MySQL, Redis, Celery con beat, Channels e Daphne per i WebSocket, DRF con JWT, pandas e numpy, web3 per il canale crypto. Flutter e Dart per i client mobile e desktop, un solo lib/ condiviso tra tutti e tre. Diciassette lingue configurate.

Sette letture indipendenti di indicatori per ciascun timeframe, e un timeframe concorda solo quando almeno cinque delle sette sono d'accordo - poi una conferma multi-timeframe sopra, con filtri opzionali su candele e notizie e stop e target derivati dall'ATR. Ogni passata scrive una riga di audit, che abbia prodotto un segnale o meno, e il dry-run è il comportamento predefinito. Il canale di pagamento in crypto non tiene alcuna chiave privata sul server: un'attività pianificata osserva la catena per individuare i trasferimenti verso un indirizzo di ricezione, abbina i depositi in attesa per importo e conferma dopo dodici conferme. Due middleware impilati rendono il prodotto irraggiungibile finché l'onboarding non è davvero completo.

Django 4.2, MySQL, admin Unfold con una dashboard Chart.js, modeltranslation su otto lingue, Tailwind e Alpine da CDN. Sessantadue modelli distribuiti su nove app, sessantatré tabelle.

La catena logistica è reale, non dichiarativa: la generazione della lettera di vettura registra richiesta completa, risposta ed errore in relazione all'ordine, e la fatturazione emette documenti e note di credito sullo stesso ordine. Il prezzo in doppia valuta salva un importo nativo e un importo di visualizzazione come coppia, invece di un importo e un tasso, così un ordine passato non si riprezza in silenzio quando il cambio si muove.

Django 4.2, MySQL, admin Unfold, ReportLab con un carattere tipografico registrato su misura per la composizione dei PDF. Cinquantacinque modelli.

Il corpo del contratto è un modello giuridico strutturato che si numera da solo, congela i dati del beneficiario al momento della firma e verifica che un contratto sia collegato o a una persona fisica o a un'azienda, mai a entrambe. I PDF delle offerte vengono composti stanza per stanza - otto tipi di stanza, ciascuno con la propria descrizione, il prezzo e le fotografie - come un documento impaginato, non come il riempimento di un template. Ogni importo è salvato in entrambe le valute, in colonne parallele.

Django 5.2, MySQL, admin Unfold con template su misura per calendario e foglio ore. Il client desktop è in Tkinter - circa 1.600 righe - impacchettato con PyInstaller in un unico eseguibile e distribuito tramite un installer.

La logica di uscita automatica è la parte interessante: una sessione si chiude al suo ultimo heartbeat solo quando è passata la fine giornata prevista e non arriva alcun heartbeat da dieci minuti - e un heartbeat successivo che porta un timestamp di applicazione viva può far rivivere una sessione che una vera interruzione aveva chiuso. È un problema di stato distribuito affrontato come si deve, invece di un cron notturno che tira a indovinare.

Laravel 11 con Breeze, MySQL, Blade con Vite, Tailwind e Alpine, DomPDF. Undici modelli, diciotto migrazioni.

Niente di architetturalmente insolito, e non deve fingere il contrario: è un piccolo strumento interno, corretto. La parte con sostanza è la dashboard della pipeline, che aggrega i conteggi per tipo di spazio e per uso, la distribuzione per fascia di superficie e il budget medio rispetto al valore totale e incassato delle proforma.

Django 4.2, MySQL, admin Unfold, modeltranslation su dieci lingue, Tailwind e Alpine. Circa trenta modelli. Un plugin complementare per lo strumento di design, fuori dal runtime Django.

La pipeline prende il codice sorgente incollato, ne genera diagrammi di architettura e di flusso, poi costruisce una specifica di schermate e palette che un plugin dello strumento di design scarica e disegna come frame reali e modificabili. È uno strumento piccolo, ma elimina l'ora meno piacevole dell'avvio di un progetto.

Solo libreria standard di Python. Nessun framework, nessuna dipendenza, nessun passaggio di build, circa 920 righe. Il server è il server HTTP della libreria standard, con una coda di lavori su thread.

Gestisce correttamente l'autenticazione a due livelli del fornitore - credenziali di servizio per emettere credenziali cliente, poi credenziali cliente per la generazione, messe in cache e riutilizzate - e tratta la generazione come davvero asincrona, interrogando ogni lavoro sul proprio thread con un timeout. Senza credenziali configurate la UI disabilita la generazione e lo dichiara, invece di fallire al momento dell'uso.

PHP e Laravel 8 con Jetstream e Livewire, MySQL, template Blade, Laravel Mix che compila Tailwind, Bootstrap, jQuery, Alpine e Sass. Tredici modelli, ventinove migrazioni, trentadue controller, Apache su cPanel.

La traduzione vive nello schema invece che in un pacchetto: i modelli di articoli, shop, galleria e menu portano ciascuno quattro set di colonne parallele, uno per lingua, e il rumeno è arrivato cinque anni dopo il lancio, con migrazioni che allargano ognuno di essi. È un progetto più rozzo di una tabella di traduzioni, e ha un pregio reale: leggere una riga tradotta è la stessa query di leggere una riga non tradotta, senza join e senza logica di fallback da sbagliare. Vale la pena dirlo chiaramente: è un monolite CRUD convenzionale, su uno stack che ha preso gli anni. Quello che dimostra non è l'ingegno, ma il fatto di essere stato mantenuto senza clamore per anni dopo la consegna.

Django 4.2, MariaDB, admin Jazzmin con inline annidati, modeltranslation e Rosetta per modificare le traduzioni dal browser, Bootstrap e AOS. Trenta modelli. Quattro container: nginx, web, database e uno scheduler.

Il modulo di invio delle campagne calcola quanti intervalli sono trascorsi dall'ora di partenza e invia il lotto successivo di dieci destinatari, tracciando l'avanzamento e scrivendo un log di consegna con un message id generato per ogni destinatario - una cadenza di invio pensata per reggere un host di posta condiviso invece di dare per scontato un provider di invio. Un job orario interroga poi l'IMAP, analizza le notifiche di bounce e le riconcilia con quei log di consegna tramite message id. Sotto, una protezione anti-abuso a più livelli: URL trappola che bannano l'IP di origine per trenta giorni, una blocklist di bot dannosi e limiti di frequenza per singola vista.

HTML statico con Tailwind compilato in un unico foglio di stile, moduli JavaScript nativi, un solo endpoint PHP per il form di contatto. Apache su hosting condiviso.

L'endpoint di posta parla SMTP direttamente - apre da sé un socket TLS ed esegue l'handshake di autenticazione, senza alcuna libreria di posta - perché l'host non offriva alternative utilizzabili. L'analytics è davvero subordinato al consenso: il tag non viene caricato affatto finché il consenso non è memorizzato, e in più rispetta il Do-Not-Track e si rifiuta di girare fuori dall'hostname di produzione. La scrittura da destra a sinistra è gestita nei sorgenti Tailwind invece di essere aggiunto come un secondo foglio di stile, e ogni URL dichiara le proprie alternative di lingua.

Django 4.2, MySQL, admin Unfold, modeltranslation. PayPal chiamato direttamente via REST invece che tramite un SDK.

Un pattern CMS a modelli singleton in cui ciascuna delle circa venti sezioni di pagina crea da sé la propria riga alla migrazione, così chi scrive non apre mai l'admin su una schermata vuota e non deve mai sapere cosa sia una fixture. Tutte le chiavi di terze parti stanno in un vault su database invece che in file di ambiente, che è il compromesso giusto per un cliente che cambia fornitore più spesso di quanto faccia deploy.

HTML statico. Nessun framework, nessun database, nessun passaggio di build - la risposta giusta per un catalogo che cambia due volte l'anno e deve sopravvivere alla finestra di supporto di qualsiasi framework.

Niente, ed è proprio questo il punto. Non ogni richiesta è un sistema, e un sito statico che il cliente può ospitare ovunque per dieci anni qui è un risultato migliore di un CMS in cui nessuno farà mai accesso.

Django 4.2 con django-unfold, MySQL tramite PyMySQL, modeltranslation su otto lingue, CKEditor per i campi lunghi, Tailwind e Alpine caricati da un CDN senza passaggio di build, Whitenoise, Passenger su cPanel. Trentadue modelli distribuiti su tre app.

Qui non c'è niente di difficile, e questa voce si guadagna il posto dimostrando l'abilità opposta: un sito il cui proprietario non ha mai bisogno di uno sviluppatore per cambiarne una parola. Il difetto, e lo dico chiaramente, si vede nello schema - il modello del portfolio porta ancora un campo superficie e un campo località ereditati dal template immobiliare da cui è stato forkato, e circa un terzo dell'elenco delle dipendenze è ereditato e mai importato. È questo che costa davvero forkare un progetto funzionante per risparmiare una settimana, e preferisco mostrarlo piuttosto che toglierlo dal racconto.

Vue 3 con la Composition API, Vue Router, Vite con chunking manuale dei vendor, Tailwind, GSAP, icone Lucide. Circa seimilatrecento righe distribuite su otto rotte, una delle quali è una pagina di design system. Apache che serve il risultato della build.

Dodici componenti di animazione, uno per servizio, scritti invece che presi da una libreria, con sotto dei composable per intersection observer e conteggio progressivo. È lavoro artigianale ed è tutta la sua ambizione. Porta anche l'esempio più netto che ho di una dipendenza sopravvissuta al proprio scopo: reCAPTCHA v3 si carica su ogni pagina e non protegge nulla, perché sul sito non c'è alcun modulo - la rotta contatti è un link mailto, e la libreria di validazione installata per il modulo mai costruito è ancora nel manifest. Uno script di terze parti che gira a ogni caricamento di pagina senza fare niente è una responsabilità in materia di consenso, non un residuo innocuo, ed è nella lista delle cose da rimuovere.

Solidity 0.8.24 con OpenZeppelin 5.1 fissato alla versione esatta, Hardhat ed ethers v6, Node 20 per il relayer e il faucet, Terraform e Docker Compose per la flotta di validatori, uno stack Blockscout incluso nel repository dietro nginx per l'explorer, JavaScript nativo per le dApp e il wallet, Rust e Anchor per il ramo Solana. 3.500 righe di Solidity originale, 12.000 di JavaScript, 142 test dei contratti distribuiti su quattro suite.

Un unico file di allocazione è l'unica fonte di verità per l'offerta di cento milioni, e la build ne genera il genesis, le directory compose per ruolo e gli script di deploy, per devnet, testnet e mainnet allo stesso modo - le tre reti non possono quindi divergere. Un passaggio di preflight si rifiuta di costruire un genesis di mainnet finché resta un indirizzo segnaposto. Il faucet reimplementa il protocollo WebSocket del client del nodo, così la pagina non ha bisogno di alcun caso speciale per le reti locali. Il relayer avanza il proprio cursore dei blocchi solo dopo che ogni messaggio di un intervallo è stato salvato, perché avanzare prima perde trasferimenti in modo definitivo e nulla riesegue la scansione. La conservazione dell'offerta è un invariante di progetto e non un controllo: esattamente una catena mette in deposito e tutte le altre emettono, il cap del token è uguale all'offerta del genesis, e gli script di deploy non emettono nulla. La versione di OpenZeppelin è fissata perché la 5.2 emette un opcode più recente dell'EVM del nodo - una libreria più nuova produrrebbe bytecode che i suoi stessi validatori non potrebbero eseguire. Il bridge è un bridge a quorum fidato, ed è descritto come tale in tre punti distinti invece di essere chiamato trustless.

Python 3.11 con pandas e numpy, con versioni volutamente vincolate perché le wheel precompilate si installino su hosting condiviso senza compilatore. SQLite per il registro delle operazioni, MySQL per l'export, il server HTTP della libreria standard per la dashboard. 18.000 righe distribuite su 94 moduli e 541 test.

Il modello di linguaggio gira su un proprio ciclo in background e scrive una cache che il loop di trading legge all'istante, perché un round trip da uno a tre secondi su barre da cinque secondi significa agire su un prezzo che non esiste più - e quel guasto è silenzioso, dato che la risposta continua a sembrare sensata. Può emettere un bias e due moltiplicatori; non può inventare un'operazione, scegliere una direzione, dimensionare una posizione o spostare uno stop, e in caso di errore ricade su neutro. Il livello di apprendimento è una regressione logistica scritta a mano proprio perché non possa nascondere l'overfitting: in-sample e out-of-sample riportati sempre insieme, split che rispettano l'ordine temporale e, stampata accanto, una baseline ingenua che prende ogni operazione. Le uscite scattano sul prezzo del sottostante invece che sul premio dell'opzione, perché il premio si muove con la volatilità e il decadimento temporale. Il supervisore usa un file lock da quando due avvii distanti pochi secondi sono sfuggiti a un controllo tramite pidfile e hanno lasciato due bot a operare su un solo conto.

Django 4.2, django-unfold, MySQL, modeltranslation su dieci lingue, CKEditor, Tailwind e Alpine da un CDN, Passenger su cPanel. Trenta modelli distribuiti su tre app, più un plugin Figma complementare.

Il generatore Figma costruisce il suo albero di nodi in modo deterministico - frame, rettangoli e testi disposti dal codice - e solo dopo offre un passaggio opzionale con il modello per abbellirlo. Quest'ordine è tutto il progetto: lo stesso progetto produce sempre lo stesso layout, e il modello può migliorare il risultato ma non è mai la ragione per cui esiste. Il plugin recupera la sua specifica tramite un URL admin firmato, così l'app desktop di Figma può scaricare un design senza tenere una sessione. Due lacune che non farò finta siano risolte: il lato push dell'integrazione Figma è ancora uno stub, e il client OpenAI viene importato senza essere fissato a una versione, quindi un'installazione pulita di quel pannello fallisce finché non lo si aggiunge.

Python 3.11 e Django 5.2 LTS, django-unfold, MySQL tramite PyMySQL, Redis, Celery con beat, results e Flower, Strawberry GraphQL con l'estensione di ottimizzazione per Django, modeltranslation, Silk solo in sviluppo, React 18 e Vite per l'isola di front-end. Dieci app, trentatré modelli, circa ottomiladuecento righe di Python.

Il tracciamento delle conversioni scatta due volte di proposito: il pixel del browser e l'API lato server inviano lo stesso evento con lo stesso event id, la piattaforma li deduplica, e gli eventi che i blocker altrimenti eliminerebbero - di solito da un quinto a due quinti - sopravvivono. I campi personali vengono sottoposti ad hash prima di uscire, e un errore di tracciamento viene ingoiato invece che sollevato, perché un lead vale più di un lead riportato alla perfezione. Il motore dei moduli è fatto di nove modelli e dodici tipi di domanda su un funnel a cinque stati con una traccia di audit degli eventi; i suoi endpoint pubblici sono deliberatamente esenti da CSRF, perché il markup è scritto nell'admin e servito così com'è, e un id di sessione impossibile da indovinare, emesso dal server, fa il lavoro che avrebbe fatto il token. Ogni vincolo di versione nel file delle dipendenze porta con sé la ragione per cui esiste, comprese quelle di cui preferirei non avere bisogno. Il punto debole è la copertura: ventitré smoke test per ottomila righe, che non bastano, e lo so.