# Software feature flag: scegli uno, poi rilascia con calma URL: https://whatshouldibuildnext.com/it/lp/software-feature-flag Type: landing Locale: it Published: 2026-10-25 Updated: 2026-10-28 --- > LaunchDarkly, PostHog, GrowthBook e Unleash a confronto: come scegliere un software feature flag, quando un semplice booleano basta e cosa proteggere per primo. *Per dev che rilasciano da soli* ## Software feature flag, scelto senza hype Confronta i software feature flag in base a quello che serve davvero a un dev solo o a un piccolo team, poi definisci un progetto che vale la pena proteggere con un flag. Gratis, senza registrazione. ## Quattro lavori che fa un feature flag ### Rilascia nascosto, attiva dopo Unisci al main il lavoro non finito dietro un flag. Distribuire il codice e attivare una funzione smettono di coincidere, e il merge del venerdì fa meno paura. ### Attiva a poco a poco Abilita la funzione per te, poi per il 5% degli utenti, poi per tutti. Se gli errori salgono, ti fermi al 5% invece di chiedere scusa a tutti. ### Interruttore di emergenza in pochi secondi Un'integrazione esterna instabile o una query lenta si spegne da una dashboard. Niente rollback, niente redeploy, niente hotfix alle 3 di notte. ### Testa con utenti veri Servi due varianti, misura una metrica e tieni quella che vince. Alcuni strumenti includono gli esperimenti, altri lasciano il lavoro al tuo stack di analytics. ## Quattro strumenti, differenze oneste | Criteri | LaunchDarkly | PostHog | GrowthBook | Unleash | |---|---|---|---|---| | Licenza | Proprietaria | MIT | MIT | Apache | | Opzione self-hosted | No | Sì | Sì | Sì | | Piano gratuito | Sì, con limiti sull'uso | Sì, 1 milione di richieste di flag al mese | Sì nel cloud, gratis in self-hosting | Gratis in self-hosting | | Esperimenti integrati | Sì | Sì, nel cloud | Sì | Limitati | | Ideale per | Team che vogliono un prodotto enterprise gestito | Team che vogliono anche analytics di prodotto | Team che puntano sui test A/B | Team che hanno bisogno di sovranità dei dati | *Caso d'uso* ## Non adottare uno strumento prima di avere una funzione rischiosa L'errore più comune è installare un software feature flag su un progetto che non ha nulla da proteggere. Un flag si ripaga quando c'è una modifica che esiteresti a rilasciare a tutti: un flusso di pagamento, una migrazione di dati, una funzione IA con costi imprevedibili. Se non riesci a dare un nome a quella modifica, per ora basta un booleano in una variabile d'ambiente. Il generatore su whatshouldibuildnext.com trasforma un'idea grezza in una specifica con uno stack suggerito e una o due funzioni che portano un rischio reale, così sai cosa mettere dietro un flag prima di scegliere il fornitore. - Gratuito, lato client, senza registrazione - Indica le funzioni rischiose da rilasciare - Suggerisce uno stack compatibile con il tuo SDK di flag *Hosting* ## Hosted o self-hosted: scegli l'onere minore I software feature flag open source sono gratuiti come licenza, non nel tempo. Self-hosting significa un database da salvaguardare, un servizio da tenere in vita e una strada di aggiornamenti da seguire, il tutto per un sistema da cui il codice in produzione dipende a ogni richiesta. Gli strumenti hosted tolgono questo peso, e i loro piani gratuiti bastano per la maggior parte dei side project. Scegli il self-hosting quando la residenza dei dati o il costo per richiesta te lo impongono, non perché sembra più indie. In ogni caso, scrivi il codice con OpenFeature, così la scelta resta reversibile. - Hosted: nessun server, prezzi a consumo - Self-hosted: nessuna fattura per richiesta, l'uptime è tuo - OpenFeature rende il fornitore sostituibile ## Da zero a una funzione con flag 1. **Individua la modifica rischiosa** — Scegli la sola funzione che potrebbe farti danno se uscisse rotta. È il tuo primo flag, non tutti e venti. 2. **Parti dal piano gratuito** — Crea un account oppure avvia localmente l'immagine open source, prendi una chiave SDK e collega un solo flag in un branch. 3. **Imposta il default su off** — Fai in modo che il comportamento sicuro sia quello di fallback, così un errore nella lettura del flag non espone codice incompleto. 4. **Rilascia a fasi** — Prima tu, poi una piccola percentuale, poi tutti. Controlla errori e latenza tra un passaggio e l'altro. 5. **Elimina il flag** — Quando la funzione è al 100% e stabile, rimuovi flag e percorso di codice morto nella stessa pull request. ## Domande frequenti ### Che cos'è un software feature flag? È uno strumento che ti permette di attivare o disattivare percorsi di codice a runtime, senza rifare il deploy. Avvolgi una modifica rischiosa in un flag, la rilasci nascosta, poi la abiliti per te, per una percentuale di utenti o per tutti, e la spegni subito se si rompe. ### Serve un software feature flag su un side project da solo? Di solito no, almeno il primo giorno. Un booleano in una variabile d'ambiente copre parecchio. Ricorri a uno strumento vero quando ti servono targeting per utente, rilasci graduali o un interruttore di emergenza da azionare senza toccare un server. ### Esiste un software feature flag gratuito? Sì. LaunchDarkly, PostHog, GrowthBook, Flagsmith e Statsig hanno tutti piani gratuiti, e Unleash, GrowthBook, Flagsmith e PostHog hanno edizioni open source che puoi installare da solo. Limiti e prezzi cambiano, quindi controlla la pagina dei prezzi prima di impegnarti. ### Meglio self-hosting o un servizio hosted? Hosted significa nessun server da aggiornare e flag valutati per te. Self-hosted significa nessuna fattura per richiesta e pieno controllo dei dati, ma sei tu a gestire database e uptime. Per un side project, i piani gratuiti hosted di solito richiedono meno lavoro. ### Che cos'è OpenFeature e serve davvero? OpenFeature è un'API neutrale rispetto ai fornitori per valutare i flag. Se scrivi il codice con quella API, cambiare fornitore in seguito vuol dire sostituire un plugin, non riscrivere ogni chiamata a un flag. È un'assicurazione economica contro il vincolo a un unico fornitore. ### Come evito che i vecchi flag si accumulino? Assegna a ogni flag un responsabile e una data di rimozione al momento della creazione. Considera un flag fermo al 100% da qualche settimana come debito tecnico: elimina il flag e il ramo di codice morto nella stessa pull request. ### Cosa costruire per esercitarsi con i flag? Qualcosa con almeno una funzione che ti preoccuperebbe rilasciare a tutti. Il generatore su whatshouldibuildnext.com definisce un piccolo progetto con una o due funzioni rischiose, e così hai un motivo concreto per avvolgere del codice in un flag. ## Definisci qualcosa che vale la pena proteggere con un flag Generatore di specifiche gratuito, lato client, senza registrazione. Ottieni funzioni e uno stack suggerito, poi scegli il tuo strumento di flag. *Call to action: Genera una specifica di progetto* ## FAQ ### Che cos'è un software feature flag? È uno strumento che ti permette di attivare o disattivare percorsi di codice a runtime, senza rifare il deploy. Avvolgi una modifica rischiosa in un flag, la rilasci nascosta, poi la abiliti per te, per una percentuale di utenti o per tutti, e la spegni subito se si rompe. ### Serve un software feature flag su un side project da solo? Di solito no, almeno il primo giorno. Un booleano in una variabile d'ambiente copre parecchio. Ricorri a uno strumento vero quando ti servono targeting per utente, rilasci graduali o un interruttore di emergenza da azionare senza toccare un server. ### Esiste un software feature flag gratuito? Sì. LaunchDarkly, PostHog, GrowthBook, Flagsmith e Statsig hanno tutti piani gratuiti, e Unleash, GrowthBook, Flagsmith e PostHog hanno edizioni open source che puoi installare da solo. Limiti e prezzi cambiano, quindi controlla la pagina dei prezzi prima di impegnarti. ### Meglio self-hosting o un servizio hosted? Hosted significa nessun server da aggiornare e flag valutati per te. Self-hosted significa nessuna fattura per richiesta e pieno controllo dei dati, ma sei tu a gestire database e uptime. Per un side project, i piani gratuiti hosted di solito richiedono meno lavoro. ### Che cos'è OpenFeature e serve davvero? OpenFeature è un'API neutrale rispetto ai fornitori per valutare i flag. Se scrivi il codice con quella API, cambiare fornitore in seguito vuol dire sostituire un plugin, non riscrivere ogni chiamata a un flag. È un'assicurazione economica contro il vincolo a un unico fornitore. ### Come evito che i vecchi flag si accumulino? Assegna a ogni flag un responsabile e una data di rimozione al momento della creazione. Considera un flag fermo al 100% da qualche settimana come debito tecnico: elimina il flag e il ramo di codice morto nella stessa pull request. ### Cosa costruire per esercitarsi con i flag? Qualcosa con almeno una funzione che ti preoccuperebbe rilasciare a tutti. Il generatore su whatshouldibuildnext.com definisce un piccolo progetto con una o due funzioni rischiose, e così hai un motivo concreto per avvolgere del codice in un flag.