La GA va guadagnata

Scritta agosto 2026

Dal costruire da solo una piattaforma gestionale multi-tenant — una di quattro note su ciò che il lavoro ha insegnato davvero.

Ogni elenco di funzionalità che ho scritto in vita mia era un'affermazione sul futuro. Il modulo esisteva, i test erano verdi, le schermate si disegnavano — e niente di tutto questo rispondeva all'unica domanda che una persona si fa davvero, cioè se la cosa funziona quando un utente vero fa il lavoro vero nell'ambiente in cui è stata rilasciata.

Così ho costruito un registro che etichetta ogni superficie della piattaforma, e ho invertito il default. alpha significa: si sa che non funziona da capo a fondo. beta significa completo e plausibile ma non dimostrato contro la realtà — ed è il valore a cui si risolve una superficie non registrata, così dimenticarsi di etichettare qualcosa non le regala in silenzio una promozione. ga significa dimostrato, e richiede una stringa di evidence che nomini cosa lo dimostra.

La conseguenza ci ha messo quattro mesi ad arrivare: la prima superficie ha raggiunto ga quattro mesi dopo la nascita dell'etichetta. Non perché il codice fosse cattivo — perché nulla era ancora stato eseguito da nessuna parte se non su un portatile.

Ciò che ha guadagnato la prima è stato un luogo, non un test

Il test di processo di quella superficie guidava l'intero flusso a ogni pull request, da giorni. La frase che stava fra lui e la ga era che nessuna esecuzione era mai avvenuta altrove che su uno stack locale. Quando finalmente è girato contro l'ambiente rilasciato — una esecuzione, nessun tentativo ripetuto, niente saltato, ogni riga riletta attraverso un client privilegiato — quella è stata tutta la differenza.

Un test che esiste non è un'esecuzione che è avvenuta.

La promozione la scrive uno strumento e non una mano, e lo strumento rifiuta. Nessun test di processo: rifiutato. Un'esecuzione le cui affermazioni venivano dalla lettura del file di test invece che dall'esecuzione stessa: rifiutato. Un albero di lavoro non committato, un bersaglio locale, zero test, qualunque cosa saltata o ritentata: rifiutato. Ha prodotto più rifiuti che promozioni, e quel rapporto è lo strumento che funziona, non che fallisce.

Il rifiuto che mi tengo

Una superficie è stata eseguita tre volte ed è andata pass, fail, pass. L'intera ragione per cui lo strumento non ritenta nulla è che il secondo tentativo non ha il diritto di cancellare il primo. La causa si è rivelata essere un clic atterrato nell'intervallo fra il completamento di un reload e l'aggancio dei gestori da parte del framework: il clic raggiungeva il DOM e non il componente, così la schermata non cambiava mai e l'asserzione sotto aspettava venti secondi un numero che non si sarebbe mai mosso.

L'ho risolto asserendo per primo lo stato di pressione del bottone stesso, il che trasforma "il clic è arrivato?" in una domanda con una risposta invece che in qualcosa dedotto dalla cifra che ne dipende. Sono seguite sette esecuzioni pulite, ed è stata rifiutata lo stesso — un'esecuzione che ha avuto bisogno di essere ripetuta per venire pulita non è una prova, e promuoverla comunque avrebbe reso l'etichetta priva di significato la volta dopo che l'avessi guardata.

Quella superficie adesso è ga, e come ci è arrivata è la metà più utile. Non è stata promossa allentando qualcosa. È stata promossa quando mi sono accorto che lo strumento le stava facendo la domanda sbagliata: l'asticella era un modello scritto per un modulo che scrive record, e questa calcola a partire da record che non ha creato. Una dashboard veniva rifiutata perché falliva un test su scritture che non esegue, e lo strumento non ha mai nominato l'asticella che stava applicando.

Così adesso ci sono due tipi di prova, e il secondo non è quello facile. Un processo che scrive una riga e la rilegge non può facilmente essere d'accordo con sé stesso per caso; una cifra confrontata con un database sì, perché entrambi i lati possono essere calcolati dallo stesso errore e il confronto passa allora per sempre. Quel tipo deve quindi includere un controllo negativo — un'asserzione eseguita contro un valore che si sa essere sbagliato, e che deve fallire — mentre l'altro no.

Un rifiuto può significare due cose diverse, e vale la pena saperle distinguere. Una è lo strumento che tiene il punto contro un risultato che volevo. L'altra è lo strumento che sbaglia. La prima costa una giornata. La seconda resta invisibile finché qualcuno non si chiede perché un'intera classe di superfici non passi mai, ed è per questo che è rimasta lì per mesi.

La maggior parte della piattaforma sta ancora a beta. Potrei muovere quei numeri in un pomeriggio rietichettando. La ragione per non farlo è che il registro è l'unica cosa fra me e il mio stesso ottimismo, e il suo valore è esattamente la sua disponibilità a dire di no.

Da dove nascono

Nascono da un progetto solo: una piattaforma gestionale multi-tenant per studi professionali, dove clienti, commesse, ore, preventivi e fatture sono collegati dall’inizio alla fine invece di essere venduti come cinque strumenti che condividono un login. Attorno le stanno i siti pubblici, la documentazione e gli strumenti di sviluppo con cui è costruita: sette applicazioni in produzione e un solo database Postgres, in un unico repository.

È costruita e mantenuta da una persona sola, fuori dall’orario di un lavoro a tempo pieno. È un dato di contesto, non un vanto, ed è la ragione per cui queste note suonano così: da solo non puoi rimediare a un errore lavorando di più, e quindi conta la leva — cosa automatizzare, cosa rifiutarsi di dichiarare, e quali controlli restituiscono più tempo di quanto ne costino.

Il codice è privato e qui non se ne regala niente. Quello che queste pagine descrivono è un metodo: come una cosa è stata misurata, cosa la misura ha smentito, e cosa è cambiato di conseguenza. Un metodo vale più letto che tenuto per sé — ed è la parte che nessuno può copiare senza prima averla capita.