[{"data":1,"prerenderedAt":2081},["ShallowReactive",2],{"has-blog-posts":3,"blog-categories":4,"category-posts-architettura":17},true,[5,8,11,14],{"slug":6,"name":7},"architettura","Architettura",{"slug":9,"name":10},"devops","DevOps",{"slug":12,"name":13},"sviluppo","Sviluppo",{"slug":15,"name":16},"testing","Testing",[18,210,347,480,621,781,911,1113,1298,1448,1614,1894],{"id":19,"title":20,"body":21,"category":7,"date":192,"description":193,"extension":194,"image":195,"meta":196,"navigation":3,"path":197,"published":3,"seo":198,"seoTitle":199,"slug":200,"stem":201,"tags":202,"updated":208,"__hash__":209},"blog/blog/2026-04-16-quanto-costa-un-software-custom.md","Quanto costa un software custom? Differenze tra 5K, 18K e 50K",{"type":22,"value":23,"toc":169},"minimark",[24,32,45,50,53,58,61,65,68,71,75,78,81,84,87,95,98,102,105,111,115,118,122,126,129,133,136,140,143,147,155,159,162,166],[25,26,27,31],"p",{},[28,29,30],"strong",{},"Tre preventivi per lo stesso software: 5.000 euro, 18.000 euro, 50.000 euro."," Stessa richiesta, stesso risultato apparente: un gestionale per i tuoi ordini. Il costo dello sviluppo software varia così tanto perché qualità e approccio dietro ogni preventivo sono profondamente diversi. In pratica stai guardando tre soluzioni completamente differenti.",[25,33,34,35,38,39,44],{},"Nel software, due prodotti che “fanno la stessa cosa” in superficie possono essere costruiti in modi radicalmente differenti, e ognuno di questi modi ha senso in un contesto specifico. La vera questione è capire ",[28,36,37],{},"cosa stai comprando davvero",". E come ho scritto parlando di ",[40,41,43],"a",{"href":42},"/blog/preventivo-software-partire-dal-budget","preventivo software e budget",", partire dal vincolo economico rende la conversazione molto più utile.",[46,47,49],"h2",{"id":48},"cosa-compri-con-un-preventivo-da-5000-euro","Cosa compri con un preventivo da 5.000 euro",[25,51,52],{},"In genere compri una soluzione basata su strumenti già esistenti: un CMS configurato, un pannello CRUD predefinito, cioè un’interfaccia standard per creare, leggere, modificare e cancellare dati, una piattaforma low-code adattata alle tue esigenze. Il lavoro principale è di configurazione e integrazione.",[54,55,57],"h3",{"id":56},"vantaggi","Vantaggi",[25,59,60],{},"I vantaggi sono evidenti: in poche settimane puoi essere operativo, il costo resta contenuto, le funzionalità standard sono già collaudate e il rischio tecnico è basso perché la base è ampiamente testata.",[54,62,64],{"id":63},"limiti","Limiti",[25,66,67],{},"Il rovescio della medaglia è che sei tu ad adattarti al software, le personalizzazioni restano limitate alla struttura prevista dallo strumento e, se in futuro emergono esigenze fuori dallo standard, potresti dover cambiare soluzione.",[25,69,70],{},"Per molte attività che hanno processi simili a quelli della maggior parte delle aziende, questa è una scelta razionale ed efficace. Spendere di più, in questi casi, non porta un reale vantaggio.",[46,72,74],{"id":73},"cosa-compri-con-un-preventivo-da-50000-euro","Cosa compri con un preventivo da 50.000 euro",[25,76,77],{},"Qui non stai comprando una configurazione, ma un progetto su misura. Prima viene analizzato il tuo modo di lavorare, poi viene progettata una struttura software adatta a quel contesto, e infine viene sviluppato codice specifico per te.",[54,79,57],{"id":80},"vantaggi-1",[25,82,83],{},"In questo caso il software riflette i tuoi processi e le tue regole, mantiene una flessibilità molto più alta nel tempo, nasce con un’architettura pensata per crescere insieme al business e ti lascia proprietà e controllo completi sul sistema.",[54,85,64],{"id":86},"limiti-1",[25,88,89,90,94],{},"Naturalmente aumentano costi e tempi, cresce la dipendenza dalla qualità del fornitore e, se ",[40,91,93],{"href":92},"/blog/agenzia-abbandona-progetto-software","il fornitore si sfila a metà progetto",", il rischio diventa alto. Inoltre serve una fase di analisi molto più approfondita.",[25,96,97],{},"Questa scelta ha senso quando il modo in cui lavori è parte del tuo vantaggio competitivo, oppure quando prevedi che il tuo business cambierà molto nei prossimi anni.",[46,99,101],{"id":100},"la-fascia-intermedia-18000-euro","La fascia intermedia: 18.000 euro",[25,103,104],{},"Questa soluzione spesso combina una base preesistente con parti sviluppate su misura. Funziona bene quando gran parte delle tue esigenze rientra nello standard, le personalizzazioni sono limitate e ben isolate e il fornitore sa distinguere chiaramente cosa resta standard e cosa diventa custom. Diventa problematica quando si forza uno strumento standard a fare cose per cui non è stato progettato: in questi casi, il risultato è un sistema difficile da mantenere e da evolvere.",[25,106,107,108],{},"La domanda chiave qui è: ",[28,109,110],{},"quanto del tuo processo rientra davvero nello standard?",[46,112,114],{"id":113},"perché-i-numeri-sono-così-diversi","Perché i numeri sono così diversi",[25,116,117],{},"I preventivi non stanno valutando la stessa cosa. Quello basso misura soprattutto la capacità di configurare strumenti esistenti, quello alto valuta la capacità di progettare e costruire una soluzione su misura, quello intermedio cerca un equilibrio tra le due cose. Nessuno ti sta ingannando: la differenza sta nell’approccio di ogni fornitore.",[46,119,121],{"id":120},"le-domande-da-farsi-prima-di-scegliere","Le domande da farsi prima di scegliere",[54,123,125],{"id":124},"il-tuo-processo-è-standard-o-specifico","Il tuo processo è standard o specifico?",[25,127,128],{},"Se lavori come la maggior parte delle aziende del tuo settore, una soluzione standard è spesso sufficiente. Se il tuo modo di lavorare è particolare e distintivo, questo dovrà emergere nel software.",[54,130,132],{"id":131},"quanto-cambierà-il-tuo-business-nei-prossimi-due-anni","Quanto cambierà il tuo business nei prossimi due anni?",[25,134,135],{},"Se prevedi cambiamenti frequenti, la flessibilità diventa un fattore importante. Se il tuo modello è stabile, puoi privilegiare rapidità e costo.",[54,137,139],{"id":138},"quanto-valore-genera-questo-software","Quanto valore genera questo software?",[25,141,142],{},"Se il software serve solo a semplificare un’attività amministrativa marginale, una soluzione economica ha senso. Se il software è il cuore del tuo prodotto o dei tuoi ricavi, l’investimento deve essere proporzionato.",[54,144,146],{"id":145},"quanto-ti-costerà-cambiare-soluzione-in-futuro","Quanto ti costerà cambiare soluzione in futuro?",[25,148,149,150,154],{},"Una soluzione economica che dopo un anno non è più adeguata può diventare più costosa di un investimento iniziale maggiore ma più duraturo. È il motivo per cui ",[40,151,153],{"href":152},"/blog/costi-manutenzione-software","i costi di manutenzione software"," pesano spesso più del costo iniziale.",[46,156,158],{"id":157},"lerrore-più-comune","L’errore più comune",[25,160,161],{},"L’errore più comune è scegliere un preventivo con aspettative che non corrispondono a quello che offre. Una soluzione economica può essere perfetta se sai che stai comprando velocità e standardizzazione; una soluzione costosa può essere un ottimo investimento se sai che stai comprando flessibilità e adattabilità. Il problema nasce quando si acquista una soluzione aspettandosi caratteristiche che non può avere.",[46,163,165],{"id":164},"in-sintesi","In sintesi",[25,167,168],{},"Preventivi molto diversi per lo stesso software indicano che stai valutando approcci diversi alla soluzione del problema. Capire quale approccio ha senso per il tuo caso conta molto più del semplice confronto tra i numeri.",{"title":170,"searchDepth":171,"depth":171,"links":172},"",2,[173,178,182,183,184,190,191],{"id":48,"depth":171,"text":49,"children":174},[175,177],{"id":56,"depth":176,"text":57},3,{"id":63,"depth":176,"text":64},{"id":73,"depth":171,"text":74,"children":179},[180,181],{"id":80,"depth":176,"text":57},{"id":86,"depth":176,"text":64},{"id":100,"depth":171,"text":101},{"id":113,"depth":171,"text":114},{"id":120,"depth":171,"text":121,"children":185},[186,187,188,189],{"id":124,"depth":176,"text":125},{"id":131,"depth":176,"text":132},{"id":138,"depth":176,"text":139},{"id":145,"depth":176,"text":146},{"id":157,"depth":171,"text":158},{"id":164,"depth":171,"text":165},"2026-04-16","Tre preventivi da 5.000 a 50.000 euro per lo stesso software indicano approcci molto diversi. Come capire cosa compri davvero e quale ha senso per il tuo caso.","md","/images/blog/quanto-costa-un-software-custom.jpg",{},"/blog/2026-04-16-quanto-costa-un-software-custom",{"title":20,"description":193},"Quanto costa un software su misura (preventivi da 5K a 50K)","quanto-costa-un-software-custom","blog/2026-04-16-quanto-costa-un-software-custom",[203,204,205,206,207],"budget","preventivi","software custom","scelta fornitore","costi",null,"cWV8i-T8qBWycy0ceo7FtACkcigSDcNvqSi0LdZmXdc",{"id":211,"title":212,"body":213,"category":7,"date":331,"description":332,"extension":194,"image":333,"meta":334,"navigation":3,"path":335,"published":3,"seo":336,"seoTitle":337,"slug":338,"stem":339,"tags":340,"updated":208,"__hash__":346},"blog/blog/2026-04-14-digitalizzare-processi-aziendali.md","Digitalizzare i processi aziendali: prima fai ordine, poi il software",{"type":22,"value":214,"toc":318},[215,221,224,228,234,237,240,244,248,251,255,258,262,265,269,277,284,288,296,299,303,306,310,313,315],[25,216,217,220],{},[28,218,219],{},"Un cliente aveva centinaia di clienti, ognuno con logiche di prezzo diverse: a peso, a pezzo, con forfait, con sconti storici, con accordi presi a voce negli anni."," Voleva un software che \"automatizzasse tutto\". La digitalizzazione dei processi aziendali senza prima fare ordine produce esattamente questo: un sistema pieno di eccezioni, con decine di logiche di calcolo diverse, che nessuno riesce davvero a spiegare.",[25,222,223],{},"Quel software non era scritto male. Era la trasposizione fedele di un business senza regole chiare. Ed è qui il punto: il software codifica quello che già esiste, e se a monte manca ordine, a valle troverai solo una versione più rigida della stessa confusione.",[46,225,227],{"id":226},"il-software-è-uno-specchio","Il software è uno specchio",[25,229,230,231],{},"C’è una verità poco comoda: ",[28,232,233],{},"il software amplifica i problemi organizzativi, rendendoli più evidenti e più rigidi.",[25,235,236],{},"Se il tuo processo è chiaro ma manuale, il software lo velocizza. Se il tuo processo è lento ma ben definito, il software lo automatizza. Se invece il tuo processo è fatto di eccezioni, decisioni caso per caso e regole implicite, il software trasformerà tutto questo in una rete di condizioni difficili da capire e ancora più difficili da modificare.",[25,238,239],{},"Il codice ha bisogno di regole esplicite. Se tu non riesci a spiegare come funziona il tuo processo senza dire “dipende” ogni due frasi, chi sviluppa dovrà tradurre ogni “dipende” in una condizione diversa. E il risultato sarà un sistema che riflette esattamente quella confusione.",[46,241,243],{"id":242},"segnali-che-il-problema-sta-a-monte-del-software","Segnali che il problema sta a monte del software",[54,245,247],{"id":246},"ci-servono-molte-eccezioni","“Ci servono molte eccezioni”",[25,249,250],{},"Durante l’analisi, se ogni requisito è seguito da “sì, ma in questo caso è diverso”, non sei davanti a un processo: sei davanti a una serie di abitudini stratificate nel tempo. Un sistema sano ha poche eccezioni ben definite; un sistema caotico è composto quasi solo da eccezioni.",[54,252,254],{"id":253},"non-riesco-a-spiegarti-come-funziona","“Non riesco a spiegarti come funziona”",[25,256,257],{},"Prova a scrivere su un foglio le regole del tuo business: come si calcola il prezzo, come si applicano gli sconti, come funziona la fatturazione, come gestisci gli ordini. Se non riesci a farlo in modo lineare, probabilmente non stai descrivendo un processo, ma una serie di decisioni prese caso per caso nel tempo.",[54,259,261],{"id":260},"ogni-cliente-è-un-caso-a-sé","“Ogni cliente è un caso a sé”",[25,263,264],{},"C’è una differenza netta tra personalizzazione strutturata e caos. Nel primo caso hai pochi modelli chiari combinabili tra loro; nel secondo ogni cliente ha condizioni uniche, negoziate a voce e mai formalizzate. La prima situazione si può automatizzare. La seconda va prima ricondotta a regole.",[46,266,268],{"id":267},"cosa-succede-quando-digitalizzi-il-caos","Cosa succede quando digitalizzi il caos",[25,270,271,272,276],{},"Nella pratica si vedono sempre gli stessi effetti. Il software diventa difficile da mantenere, perché ogni nuova funzionalità deve tenere conto di tutte le eccezioni precedenti e le modifiche diventano lente, rischiose e costose. Il sistema finisce per diventare ",[40,273,275],{"href":274},"/blog/software-fragile-regressioni","fragile e ogni deploy, cioè ogni rilascio di una nuova versione, diventa fonte di tensione",".",[25,278,279,280,276],{},"Nel frattempo il team continua a lavorare “a parte”. Le persone evitano il software perché per certi casi è ancora più veloce fare a mano, quindi fogli Excel ed email continuano a vivere in parallelo. E naturalmente i costi crescono più del previsto: il costo del software dipende dalla complessità delle regole, non dalla dimensione dell'azienda. Poche regole chiare portano a un sistema semplice, mentre molte regole implicite portano a un sistema costoso e difficile. Del resto ",[40,281,283],{"href":282},"/blog/semplicita-nel-software","costruire qualcosa di semplice è già di per sé la cosa più difficile",[46,285,287],{"id":286},"prima-organizzi-poi-digitalizzi","Prima organizzi, poi digitalizzi",[25,289,290,291,295],{},"Prima di iniziare un progetto software, spesso conviene fare un lavoro preliminare molto più semplice di quanto sembri: chiarire le regole. È lo stesso principio per cui ",[40,292,294],{"href":293},"/blog/stime-sviluppo-sbagliate-perche","le stime di sviluppo sono spesso sbagliate",": senza regole chiare, non si può stimare nulla con precisione.",[25,297,298],{},"La prima domanda utile riguarda il listino. Se la risposta è “dipende dal cliente”, allora la domanda successiva è se possa dipendere da meno fattori: fasce, categorie, criteri ripetibili che coprano la maggior parte dei casi. La seconda riguarda il rapporto tra regole ed eccezioni. Se le eccezioni sono più delle regole, non sei pronto per un software; sei pronto per semplificare il processo. La terza domanda è cosa puoi standardizzare senza perdere valore, perché molte differenze percepite come fondamentali in realtà non lo sono. Il cliente vede il risultato finale, non il metodo interno con cui lo ottieni.",[46,300,302],{"id":301},"il-ruolo-di-chi-progetta-il-software","Il ruolo di chi progetta il software",[25,304,305],{},"Il lavoro più prezioso sta nell'aiutare a riformulare i requisiti prima ancora di tradurli in codice. “Ogni cliente ha il suo prezzo” può diventare “abbiamo un sistema di fasce con alcune deroghe documentate”; “ogni progetto è diverso” può diventare “abbiamo un modello con opzioni configurabili”. Questa fase è chiarificazione del modello di business.",[46,307,309],{"id":308},"una-checklist-pratica","Una checklist pratica",[25,311,312],{},"Se riesci a spiegare il tuo processo principale senza usare “dipende” più di una volta, se le eccezioni sono poche e sai elencarle, se le regole che applichi oggi sono scritte da qualche parte, se due persone diverse nella tua azienda descrivono il processo nello stesso modo e se un nuovo collaboratore potrebbe impararlo leggendo quelle regole, allora probabilmente sei pronto a digitalizzare. Se molte di queste risposte sono negative, il lavoro da fare è prima di tutto organizzativo.",[46,314,165],{"id":164},[25,316,317],{},"Il software è un acceleratore: accelera quello che già esiste. Se esiste ordine, accelera l’ordine; se esiste confusione, accelera la confusione. Mettere ordine prima di digitalizzare è il modo più efficace per evitare un software costoso che riflette problemi invece di risolverli.",{"title":170,"searchDepth":171,"depth":171,"links":319},[320,321,326,327,328,329,330],{"id":226,"depth":171,"text":227},{"id":242,"depth":171,"text":243,"children":322},[323,324,325],{"id":246,"depth":176,"text":247},{"id":253,"depth":176,"text":254},{"id":260,"depth":176,"text":261},{"id":267,"depth":171,"text":268},{"id":286,"depth":171,"text":287},{"id":301,"depth":171,"text":302},{"id":308,"depth":171,"text":309},{"id":164,"depth":171,"text":165},"2026-04-14","Digitalizzare i processi aziendali senza prima fare ordine produce solo un sistema più rigido. Perché il software amplifica quello che già esiste.","/images/blog/digitalizzare-processi-aziendali.jpg",{},"/blog/2026-04-14-digitalizzare-processi-aziendali",{"title":212,"description":332},"Digitalizzazione processi aziendali: prima ordine, poi software","digitalizzare-processi-aziendali","blog/2026-04-14-digitalizzare-processi-aziendali",[341,342,343,344,345],"digitalizzazione","processi-aziendali","analisi-requisiti","organizzazione","preparazione-progetto","yS3XLcEhoT8qwIQP2OktjN1AoFGaxANf3rhw23_5vq4",{"id":348,"title":349,"body":350,"category":7,"date":464,"description":465,"extension":194,"image":466,"meta":467,"navigation":3,"path":468,"published":3,"seo":469,"seoTitle":470,"slug":471,"stem":472,"tags":473,"updated":208,"__hash__":479},"blog/blog/2026-04-09-semplicita-nel-software.md","Semplicità nel software: perché costa più di quanto sembri",{"type":22,"value":351,"toc":453},[352,358,361,365,369,376,379,383,386,389,396,400,407,410,414,417,425,429,432,435,438,441,445,448,450],[25,353,354,357],{},[28,355,356],{},"\"Voglio un software semplice. Che basti fare click.\""," È una richiesta legittima, spesso anche la più corretta. Ma la semplicità nel software è un punto di arrivo, mai di partenza. E di solito costa più di quanto chi commissiona si aspetti, perché richiede di prendere molte decisioni al posto dell'utente e gestire in modo invisibile decine di scenari.",[25,359,360],{},"Nel software vale una regola pratica: è facile aggiungere opzioni, campi, passaggi. È più difficile toglierli senza perdere informazioni importanti, senza creare errori e senza aumentare le eccezioni.",[46,362,364],{"id":363},"perché-semplice-è-una-richiesta-costosa","Perché “semplice” è una richiesta costosa",[54,366,368],{"id":367},"dietro-ogni-click-ci-sono-molte-decisioni","Dietro ogni click ci sono molte decisioni",[25,370,371,372,375],{},"Quando l’utente preme un bottone e “succede tutto”, la complessità è stata spostata dietro le quinte. Ogni scelta che l’utente ",[28,373,374],{},"non"," fa più (perché non vede un campo, non sceglie un’opzione, non legge un’istruzione) è una scelta che il sistema fa per lui. E per farla bene serve capire contesto, regole, eccezioni, priorità.",[25,377,378],{},"Esempio tipico: “un click per generare la fattura”. Dietro a quel gesto ci sono l’identificazione corretta del cliente e del contesto, i calcoli coerenti con le regole del caso, la numerazione progressiva, la generazione del formato richiesto e l’invio ai sistemi esterni, oltre alla gestione degli esiti e alla comunicazione all’utente. A chi usa il prodotto interessa un click; al team interessa che quel click non produca una fattura sbagliata, un invio fallito o uno stato incoerente. È qui che si annida il costo.",[54,380,382],{"id":381},"togliere-richiede-capire-aggiungere-richiede-soprattutto-implementare","Togliere richiede capire. Aggiungere richiede soprattutto implementare.",[25,384,385],{},"La strada “veloce” verso una prima versione spesso è: mostrare tutto e chiedere tutto all’utente (più campi, più opzioni, più passaggi). Funziona, ma scarica complessità e rischio sull’utilizzatore.",[25,387,388],{},"La strada verso la semplicità, invece, richiede analisi: capire quali informazioni sono davvero necessarie, quali si possono dedurre, quali si possono precompilare, quali si possono rimandare, quali non servono proprio.",[25,390,391,392,395],{},"Questo è il motivo per cui molte richieste di “semplicità” richiedono più iterazioni rispetto a una UI “piena di opzioni”. Perché richiede più decisione che codice. Ed è anche il motivo per cui ",[40,393,394],{"href":293},"le stime di sviluppo sono spesso imprecise",": la complessità sta nelle decisioni, prima che nel codice.",[46,397,399],{"id":398},"il-paradosso-della-semplicità","Il paradosso della semplicità",[25,401,402,403,276],{},"Una UI, cioè l’interfaccia che l’utente vede e usa, complessa è spesso il risultato “naturale” di un progetto: si aggiunge quello che serve, poi un’eccezione, poi un’altra, poi un caso particolare. Alla fine si consegna qualcosa che \"fa tutto\", ma che richiede training e supporto. È la dinamica tipica dello ",[40,404,406],{"href":405},"/blog/scope-creep-progetti-agile","scope creep",[25,408,409],{},"Una UI semplice, al contrario, è il risultato di un lavoro di riduzione: capire cosa è essenziale, togliere il superfluo, automatizzare il resto, e verificare con persone reali che ciò che sembra ovvio lo sia davvero. È per questo che “semplice” è un obiettivo di prodotto, non una scorciatoia di sviluppo.",[46,411,413],{"id":412},"semplice-e-subito-raramente-convivono","“Semplice” e “subito” raramente convivono",[25,415,416],{},"Qui nasce la tensione tipica: chi commissiona vuole un’esperienza “a prova di click” e tempi stretti. Quando i tempi sono compressi, la probabilità più alta è questa: si consegna una versione che funziona ma è più “carica”, perché non c’è stato spazio per iterare, testare, rivedere e togliere.",[25,418,419,420,424],{},"La soluzione più onesta, di solito, è: partire con poco, farlo funzionare bene, e semplificare in iterazioni successive. È la logica del ",[40,421,423],{"href":422},"/blog/quando-lanciare-un-prodotto","lanciare presto e migliorare",", applicata alla UX: le prime versioni devono essere affidabili, poi diventano davvero semplici.",[46,426,428],{"id":427},"come-si-costruisce-davvero-la-semplicità","Come si costruisce davvero la semplicità",[25,430,431],{},"Molte richieste nascono dal desiderio di “digitalizzare ciò che facciamo oggi”. Ma replicare un processo esistente spesso significa replicarne anche i difetti. La domanda utile è un’altra: qual è il risultato che vogliamo ottenere, e qual è il percorso più diretto per arrivarci?",[25,433,434],{},"In analisi conviene togliere prima di aggiungere. Ogni “e se” introduce complessità, e dopo dieci “e se” il software che doveva essere semplice diventa un gestionale completo. La regola pratica è chiedersi, per ogni feature proposta, se il flusso principale funzionerebbe anche senza. Se la risposta è sì, quella feature può restare fuori dalla versione 1.",[25,436,437],{},"La semplicità poi va provata con utenti reali, presto. Non si decide in riunione. Si verifica sul campo, mettendo anche un prototipo grezzo davanti alle persone che useranno davvero il prodotto. Se la cosa principale si capisce senza spiegazioni, sei sulla strada giusta. Se servono istruzioni o manuali, la complessità è ancora tutta in superficie.",[25,439,440],{},"Infine bisogna accettare che la semplicità è un processo. La versione 1 raramente è davvero semplice; la versione 3 spesso lo è di più, la versione 5 ancora di più. La differenza la fanno le iterazioni guidate da osservazione e feedback, non la quantità di feature inserite fin dall’inizio.",[46,442,444],{"id":443},"euristiche-pratiche-per-chi-commissiona-software","Euristiche pratiche per chi commissiona software",[25,446,447],{},"Quando chiedi un software “semplice”, ci sono alcune domande che aiutano a evitare metà dei fraintendimenti. Bisogna chiarire semplice per chi, perché l’esperienza di un operatore esperto non è quella di un utente occasionale o di un cliente finale. Bisogna capire dove deve essere semplice: nel flusso principale, nelle eccezioni, nella configurazione, nell’onboarding. Vale la pena chiedersi anche cosa può andare storto e come il sistema dovrebbe reagire, che cosa è accettabile rimandare per non appesantire la prima versione e soprattutto qual è il costo dell’errore. Se l’errore costa molto, come succede con fatture, pagamenti o dati delicati, la semplicità richiede più rigore e più test.",[46,449,165],{"id":164},[25,451,452],{},"Un’interfaccia con 30 campi spesso costa meno da costruire nel breve periodo. Un’interfaccia con 3 campi e un bottone spesso costa di più perché richiede analisi, decisioni e gestione invisibile degli edge case. Ma nel medio periodo, la seconda riduce formazione, errori, supporto e frustrazione. Se il team è prudente quando sente “semplice”, è consapevolezza del lavoro necessario per farlo bene.",{"title":170,"searchDepth":171,"depth":171,"links":454},[455,459,460,461,462,463],{"id":363,"depth":171,"text":364,"children":456},[457,458],{"id":367,"depth":176,"text":368},{"id":381,"depth":176,"text":382},{"id":398,"depth":171,"text":399},{"id":412,"depth":171,"text":413},{"id":427,"depth":171,"text":428},{"id":443,"depth":171,"text":444},{"id":164,"depth":171,"text":165},"2026-04-09","La semplicità nel software è il punto di arrivo, non di partenza. Un prodotto dove basta un click richiede analisi, decisioni e gestione degli scenari.","/images/blog/semplicita-nel-software.jpg",{},"/blog/2026-04-09-semplicita-nel-software",{"title":349,"description":465},"Semplicità nel software: perché costa più di quanto pensi","semplicita-nel-software","blog/2026-04-09-semplicita-nel-software",[474,475,476,477,478],"prodotto","user-experience","analisi","strategia","sviluppo-software","TEJb1i3ts1_Al_dhaBaqgVW-fJLS-IubVFL0YUe22Ak",{"id":481,"title":482,"body":483,"category":7,"date":608,"description":609,"extension":194,"image":610,"meta":611,"navigation":3,"path":612,"published":3,"seo":613,"seoTitle":614,"slug":615,"stem":616,"tags":617,"updated":208,"__hash__":620},"blog/blog/2026-04-07-codice-perfetto-vs-pragmatico.md","Codice perfetto vs pragmatico: quando migliorare il codice ha senso",{"type":22,"value":484,"toc":595},[485,491,494,498,501,504,507,511,519,523,526,529,533,537,540,543,547,555,559,562,566,569,573,581,585,592],[25,486,487,490],{},[28,488,489],{},"Capita più spesso di quanto si pensi: codice scritto molto bene dal punto di vista tecnico, architettura pulita, test completi."," Poi il cliente lo guarda e capisce che non risponde al bisogno per cui era stato commissionato. La tensione tra codice perfetto e codice pragmatico nasce proprio qui: il codice ha senso quando risolve un problema reale.",[25,492,493],{},"La qualità tecnica è importante. Ma solo quando è al servizio del risultato di business. Quando diventa un obiettivo in sé, rischia di rallentare il progetto senza produrre valore percepibile.",[46,495,497],{"id":496},"il-software-è-uno-strumento","Il software è uno strumento",[25,499,500],{},"Chi scrive codice sviluppa naturalmente un senso estetico: si impara a distinguere codice chiaro da codice confuso, strutture solide da soluzioni improvvisate. Questa sensibilità è preziosa.",[25,502,503],{},"Il problema nasce quando “questo codice non mi piace” diventa un motivo sufficiente per fermarsi e riscrivere, anche se quel codice funziona e nessun utente ne percepisce i limiti.",[25,505,506],{},"Il software è uno strumento. Il suo scopo è produrre un risultato. La qualità interna conta, ma è subordinata a ciò che il prodotto deve ottenere all’esterno.",[46,508,510],{"id":509},"quando-la-qualità-diventa-un-costo","Quando la qualità diventa un costo",[25,512,513,514,518],{},"Ci sono situazioni ricorrenti in cui l’attenzione alla perfezione tecnica produce più costi che benefici. Succede quando moduli stabili vengono riscritti solo per renderli più eleganti, quando si introducono astrazioni “per il futuro” che poi non arriva mai, quando si ottimizzano prestazioni in parti del sistema che hanno carichi minimi o quando partono refactoring estesi, a volte vere e proprie ",[40,515,517],{"href":516},"/blog/riscrivere-software-da-zero","riscritture da zero",", mentre il cliente sta aspettando funzionalità nuove. In tutti questi casi, il tempo viene investito in qualcosa che migliora il codice ma non il prodotto percepito dagli utenti.",[46,520,522],{"id":521},"il-punto-non-è-scrivere-codice-brutto","Il punto non è scrivere codice brutto",[25,524,525],{},"“Meglio un codice brutto che funziona” è una frase pericolosa se presa alla lettera.",[25,527,528],{},"Conviene ragionare come su una scala di priorità. Prima di tutto il codice deve risolvere il problema; se non lo fa, tutto il resto perde importanza. Poi deve essere affidabile, cioè non introdurre bug, problemi di sicurezza o instabilità. Infine deve poter essere modificato senza traumi, con nomi comprensibili, una struttura ragionevole e senza trappole nascoste. Se queste tre condizioni sono rispettate, il codice è già a un livello adeguato per la maggior parte delle fasi di un progetto.",[46,530,532],{"id":531},"le-situazioni-in-cui-si-sbaglia-più-spesso","Le situazioni in cui si sbaglia più spesso",[54,534,536],{"id":535},"il-refactoring-non-richiesto","Il refactoring non richiesto",[25,538,539],{},"Un modulo funziona da mesi senza problemi, ma “internamente è brutto”. Si decide di riscriverlo. Questo è il classico refactoring, cioè la riorganizzazione del codice senza cambiare ciò che il prodotto fa. Il risultato tipico è tempo speso senza beneficio diretto e, a volte, l’introduzione di nuovi bug in qualcosa che era già stabile.",[25,541,542],{},"Il codice che funziona in produzione da tempo è già stato testato dal caso reale. Cambiarlo senza una motivazione di business è spesso un rischio inutile.",[54,544,546],{"id":545},"lastrazione-prematura","L’astrazione prematura",[25,548,549,550,554],{},"Si introduce un pattern o un livello di astrazione pensando a futuri scenari che, nella pratica, non si presentano. I ",[40,551,553],{"href":552},"/blog/design-pattern-oltre-il-linguaggio","design pattern hanno valore"," quando risolvono un problema reale, non quando anticipano un problema immaginario. Questo rende il codice più complesso oggi per un beneficio ipotetico domani.",[54,556,558],{"id":557},"le-ottimizzazioni-premature","Le ottimizzazioni premature",[25,560,561],{},"Si investe tempo per rendere una parte del sistema estremamente performante quando i volumi reali non lo richiedono. Quel tempo poteva essere investito in funzionalità che gli utenti stavano aspettando.",[46,563,565],{"id":564},"le-euristiche-pratiche-quando-fermarsi-e-quando-no","Le euristiche pratiche: quando fermarsi e quando no",[25,567,568],{},"Ci sono alcune regole semplici che aiutano a decidere. Vale la pena fermarsi a migliorare il codice quando sta causando bug ricorrenti, rende molto difficile aggiungere nuove funzionalità, nessuno nel team capisce davvero come funziona oppure crea rischi di sicurezza o di stabilità. Al contrario, conviene andare avanti quando quel codice funziona da tempo senza problemi, il cambiamento sarebbe solo estetico o strutturale, il beneficio sarebbe percepito solo dagli sviluppatori e ci sono feature di business più urgenti in attesa. Queste euristiche aiutano a mantenere la qualità sotto controllo senza trasformarla nel centro del progetto.",[46,570,572],{"id":571},"il-concetto-di-abbastanza-buono","Il concetto di “abbastanza buono”",[25,574,575,576,580],{},"“Abbastanza buono” non significa mediocrità. Significa proporzionare lo sforzo al valore: nomi chiari anche se non impeccabili, una struttura leggibile senza rigidità accademiche, ",[40,577,579],{"href":578},"/blog/test-coverage-cosa-misura","test sui flussi critici e non ovunque",", e un codice pronto a cambiare senza pretendere di prevedere ogni possibile futuro. Questo livello è sufficiente per permettere al prodotto di evolvere senza rallentare il business.",[46,582,584],{"id":583},"per-chi-decide","Per chi decide",[25,586,587,588,591],{},"Se il tuo team consegna in ritardo ma il codice è sempre “impeccabile”, vale la pena fare una domanda semplice: ",[28,589,590],{},"quanto di quello che state facendo questa settimana sarà visibile o utile per un utente?"," Se la risposta è “poco”, probabilmente c’è uno squilibrio tra qualità interna e valore esterno.",[25,593,594],{},"Il software migliore non è quello scritto meglio. È quello che risolve il problema giusto, al momento giusto, con il livello di qualità adeguato a quella fase del prodotto.",{"title":170,"searchDepth":171,"depth":171,"links":596},[597,598,599,600,605,606,607],{"id":496,"depth":171,"text":497},{"id":509,"depth":171,"text":510},{"id":521,"depth":171,"text":522},{"id":531,"depth":171,"text":532,"children":601},[602,603,604],{"id":535,"depth":176,"text":536},{"id":545,"depth":176,"text":546},{"id":557,"depth":176,"text":558},{"id":564,"depth":171,"text":565},{"id":571,"depth":171,"text":572},{"id":583,"depth":171,"text":584},"2026-04-07","Codice elegante che non risolve un problema di business è un costo, non un valore. Meglio un codice pragmatico che funziona, senza cadere nel caos.","/images/blog/codice-perfetto-vs-pragmatico.jpg",{},"/blog/2026-04-07-codice-perfetto-vs-pragmatico",{"title":482,"description":609},"Codice perfetto vs pragmatico: trovare il giusto equilibrio","codice-perfetto-vs-pragmatico","blog/2026-04-07-codice-perfetto-vs-pragmatico",[6,618,474,619,477],"pragmatismo","qualita","r6lmHuh9TqImpTGbMQQBzMNV8n5_bHdw2n8vAmFFwA4",{"id":622,"title":623,"body":624,"category":7,"date":768,"description":769,"extension":194,"image":770,"meta":771,"navigation":3,"path":772,"published":3,"seo":773,"seoTitle":774,"slug":775,"stem":776,"tags":777,"updated":208,"__hash__":780},"blog/blog/2026-02-24-clean-code-guida-pratica.md","Clean Code: guida utile (non dogma)",{"type":22,"value":625,"toc":755},[626,631,634,638,650,653,656,660,663,667,674,677,681,684,688,694,697,701,713,717,720,727,731,734,737,741,748,752],[25,627,628],{},[28,629,630],{},"Clean Code di Robert C. Martin è uno dei libri più influenti degli ultimi vent’anni nello sviluppo software. Ha aiutato moltissimi team a scrivere codice più leggibile e manutenibile.",[25,632,633],{},"Ho visto anche l’effetto collaterale: team che applicano regole “da libro” senza contesto e finiscono per produrre complessità non necessaria. Codice elegante, sì, ma costoso: più file, più livelli, più cerimonia, e tempi di consegna che si allungano. Il problema non è Clean Code: il problema è trattarlo come dogma invece che come bussola. E quella differenza, nel software, si paga in soldi, tempo e opportunità.",[46,635,637],{"id":636},"cosa-clean-code-fa-bene-molto-bene","Cosa Clean Code fa bene (molto bene)",[25,639,640,641,645,646,649],{},"Prima di criticare, vale la pena riconoscere cosa funziona davvero. I nomi che significano qualcosa sono una forma di manutenzione preventiva: ",[642,643,644],"code",{},"calculateMonthlyRevenue()"," è molto meglio di ",[642,647,648],{},"calc()",", perché riduce il tempo di comprensione, accelera l’onboarding e limita gli errori banali. Lo stesso vale per funzioni piccole e con responsabilità chiara. Non serve l’ossessione delle “5 righe massimo”, ma una funzione leggibile è più facile da testare, modificare e correggere di un blocco enorme che mescola logica, side effect e condizioni.",[25,651,652],{},"Conta molto anche la struttura prevedibile. Convenzioni condivise su stile, organizzazione ed error handling rendono il codice più navigabile e riducono la frizione: meno tempo perso a interpretare scelte arbitrarie.",[25,654,655],{},"Se un team parte dal caos, Clean Code spesso è un upgrade immediato. Il guaio inizia quando “linee guida” diventano “legge”.",[46,657,659],{"id":658},"dove-il-dogma-fa-danni","Dove il dogma fa danni",[25,661,662],{},"Il danno tipico è sempre lo stesso: ottimizzi la forma del codice prima di sapere se quella forma serve. Vale anche per principi come SOLID, cioè un insieme di regole usate per rendere il codice più ordinato e meno rigido, che diventano utili solo se applicati con giudizio.",[54,664,666],{"id":665},"astrarre-troppo-presto","Astrarre troppo presto",[25,668,669,670,673],{},"Ridurre duplicazione è utile, ma la duplicazione “piccola” a volte è un compromesso accettabile. Il rischio vero non è ripetere tre righe: è creare un’astrazione sbagliata che vincola tutto il progetto. Una regola pratica: ",[28,671,672],{},"duplica finché non vedi un pattern stabile",". Se il comportamento si sta ancora chiarendo (tipico di prodotti giovani), astrarre subito è come cementare una decisione quando non hai ancora capito la strada.",[25,675,676],{},"Un po’ di duplicazione costa poco. Un’astrazione prematura costa settimane quando scopri che era quella sbagliata.",[54,678,680],{"id":679},"frammentare-il-codice-in-troppi-micro-file","Frammentare il codice in troppi micro-file",[25,682,683],{},"“Classi piccole” è un buon principio finché migliora la comprensione. Oltre una certa soglia diventa frammentazione: per seguire un flusso devi saltare tra 10 file, e la leggibilità peggiora. Segnale tipico: “Per capire il login devo aprire 12 classi”. In quel caso hai solo spostato la complessità: da dentro un file a tra file. A volte una classe di 150 righe ben organizzata è più leggibile di 8 classi da 20 righe che si rimbalzano responsabilità.",[54,685,687],{"id":686},"test-come-cerimonia","Test come cerimonia",[25,689,690,691,276],{},"L’enfasi sui test è positiva. Ma se diventa “testiamo tutto perché sì”, ottieni una suite enorme che non protegge i flussi critici. È facile finire a testare getter/setter e logica ovvia, mentre restano scoperti i punti dove il business perde davvero soldi (pagamenti, permessi, integrazioni). È lo stesso problema della coverage: ",[40,692,693],{"href":578},"puoi avere numeri alti e non testare ciò che conta",[25,695,696],{},"La domanda giusta non è “quanta coverage?”. È: “che incidente stiamo prevenendo con questo test?”",[54,698,700],{"id":699},"solid-applicato-senza-contesto","SOLID applicato senza contesto",[25,702,703,704,707,708,712],{},"SOLID è utile su sistemi complessi. Applicato ovunque e subito, può trasformare un progetto semplice in un labirinto di interfacce e livelli. Regola pratica: ",[28,705,706],{},"usa SOLID per ridurre rischio e accoppiamento nei punti caldi"," (moduli core, logica instabile, aree con molte modifiche). Non trasformarlo in un requisito estetico su ogni form e ogni endpoint. Per un ",[40,709,711],{"href":710},"/blog/cos-e-un-mvp-software","MVP",", spesso la priorità è avere un sistema chiaro, modificabile e consegnato in tempo — più che inseguire l’architettura “da manuale”.",[46,714,716],{"id":715},"il-costo-concreto-del-dogma","Il costo concreto del dogma",[25,718,719],{},"Per chi gestisce un prodotto, questi eccessi si traducono in effetti misurabili. I tempi di consegna si gonfiano perché la “forma perfetta” diventa parte implicita del requisito, anche quando nessuno l’aveva chiesta. L’onboarding rallenta, perché più livelli e più frammentazione rendono difficile capire dove mettere mano, soprattutto quando le astrazioni non rispondono a un bisogno reale.",[25,721,722,723,726],{},"Poi c’è il refactoring infinito. Se il team viene premiato più per “pulire” che per consegnare, entra in un ciclo di perfezionamento continuo: il codice migliora marginalmente, mentre il prodotto rallenta. E naturalmente diventano più instabili anche le ",[40,724,725],{"href":293},"stime",", perché stai stimando la feature insieme a tutta la cerimonia che le viene costruita attorno.",[46,728,730],{"id":729},"dovè-il-confine-5-regole-pratiche","Dov’è il confine: 5 regole pratiche",[25,732,733],{},"Il confine pratico si può riassumere così. I nomi chiari vanno quasi sempre scelti, perché hanno un ritorno altissimo e costano poco. Le astrazioni hanno senso quando esistono insieme ripetizione e stabilità; se la logica cambia spesso, conviene aspettare. La leggibilità del flusso conta più della frammentazione elegante: se per capire una feature devi aprire troppi file, hai già perso qualcosa.",[25,735,736],{},"Anche i test vanno scelti per impatto, non per rituale. Ha senso proteggere i flussi che costano soldi quando si rompono, come pagamenti, permessi, integrazioni e regressioni. E soprattutto la qualità va misurata nel tempo, non nel gusto personale. La domanda utile è sempre la stessa: quanto ci costerà cambiare questa cosa tra tre mesi?",[46,738,740],{"id":739},"la-sensibilità-conta-più-delle-regole","La sensibilità conta più delle regole",[25,742,743,744,747],{},"Clean Code ti dà un vocabolario e una direzione. Ma la parte che fa la differenza è il giudizio: sapere quando un principio va applicato e quando diventa overhead. Il codice deve servire il business, non vincere un concorso di eleganza. Una cattedrale è impressionante, ma se dovevi costruire una casa abitabile in quattro settimane, hai sbagliato obiettivo. La ",[40,745,746],{"href":282},"semplicità è la cosa più difficile"," da ottenere, e spesso è il segno di vera competenza.",[46,749,751],{"id":750},"come-riconoscere-il-problema","Come riconoscere il problema",[25,753,754],{},"Alcuni segnali sono chiari: feature piccole che diventano “progetti architetturali”, un team che parla spesso di “rifare bene” ma consegna poco, codice apparentemente pulitissimo insieme a onboarding lento, modifiche che richiedono di toccare troppi livelli e troppe classi. In questi casi stai comprando complessità spacciata per qualità.",{"title":170,"searchDepth":171,"depth":171,"links":756},[757,758,764,765,766,767],{"id":636,"depth":171,"text":637},{"id":658,"depth":171,"text":659,"children":759},[760,761,762,763],{"id":665,"depth":176,"text":666},{"id":679,"depth":176,"text":680},{"id":686,"depth":176,"text":687},{"id":699,"depth":176,"text":700},{"id":715,"depth":171,"text":716},{"id":729,"depth":171,"text":730},{"id":739,"depth":171,"text":740},{"id":750,"depth":171,"text":751},"2026-02-24","Le regole di Clean Code salvano progetti dal caos. Ma applicate senza giudizio generano complessità inutile. Dove sta il confine pratico.","/images/blog/clean-code-guida-pratica.jpg",{},"/blog/2026-02-24-clean-code-guida-pratica",{"title":623,"description":769},"Clean Code: guida pratica o dogma da evitare?","clean-code-guida-pratica","blog/2026-02-24-clean-code-guida-pratica",[6,778,779,619,478],"best-practice","debito-tecnico","AFRJ19Eot_VkQplNkQiYRHzvjSvhTdYBIhWV4JBqV7M",{"id":782,"title":783,"body":784,"category":7,"date":898,"description":899,"extension":194,"image":900,"meta":901,"navigation":3,"path":902,"published":3,"seo":903,"seoTitle":904,"slug":905,"stem":906,"tags":907,"updated":208,"__hash__":910},"blog/blog/2026-02-19-design-pattern-oltre-il-linguaggio.md","Design pattern: perché contano più del linguaggio che usi",{"type":22,"value":785,"toc":890},[786,791,794,797,808,811,815,826,833,837,840,843,846,850,853,857,860,864,867,877,881,884,887],[25,787,788],{},[28,789,790],{},"Il tuo miglior sviluppatore conosce Laravel a memoria. Sa ogni metodo di Eloquent, ogni helper di Blade, ogni dettaglio del framework. Ora chiediti: tra tre anni, quanta di quella conoscenza sarà ancora davvero rilevante?",[25,792,793],{},"Ora pensa a uno sviluppatore che conosce i design pattern software, cioè schemi ricorrenti per organizzare bene il codice, e ragiona per strutture: sa quando isolare l'accesso ai dati, quando disaccoppiare i componenti, quando evitare dipendenze inutili. Sa progettare un sistema prima di scrivere una riga di codice.",[25,795,796],{},"Quella competenza resta valida tra tre anni. E tra dieci.",[25,798,799,800,804,805,276],{},"Stiamo entrando in un’era dove ",[40,801,803],{"href":802},"/blog/ai-impatto-business-software","l’AI scrive codice sempre meglio",". Non codice perfetto — ma codice funzionante, velocemente. Quello che l’AI non sa fare è ",[28,806,807],{},"decidere come strutturare un sistema",[25,809,810],{},"E il linguaggio con cui si struttura un sistema non è un framework. Sono i design pattern.",[46,812,814],{"id":813},"il-programmatore-sta-diventando-sempre-più-un-progettista","Il programmatore sta diventando sempre più un progettista",[25,816,817,818,821,822,825],{},"Fino a poco tempo fa, gran parte del lavoro quotidiano di uno sviluppatore era scrivere codice. Oggi una parte crescente di quel lavoro può essere accelerata dall’AI, e questo sposta il valore: meno digitazione, più progettazione. Lo sviluppatore che fa davvero la differenza sa ",[28,819,820],{},"cosa far scrivere"," e ",[28,823,824],{},"come organizzare il risultato",", più di quello che scrive codice velocemente.",[25,827,828,829,276],{},"Chi ragiona per pattern riesce a guidare l’implementazione verso una struttura solida. Chi ragiona solo per sintassi ottiene codice che funziona oggi, ma che diventa rapidamente ",[40,830,832],{"href":831},"/blog/sviluppare-con-ai","debito tecnico",[46,834,836],{"id":835},"perché-i-pattern-valgono-più-dei-linguaggi","Perché i pattern valgono più dei linguaggi",[25,838,839],{},"I pattern valgono più dei linguaggi perché non dipendono dalla sintassi. Isolare l’accesso ai dati, separare responsabilità e ridurre l’accoppiamento sono concetti che funzionano allo stesso modo in PHP, TypeScript, Go o Python. Cambia lo strumento, non il principio. Un team che ragiona per pattern riesce quindi a muoversi tra tecnologie diverse senza ripartire da zero ogni volta.",[25,841,842],{},"In più i pattern non scadono con la stessa velocità di framework e librerie. Ogni pochi anni emerge un nuovo standard, una nuova API, un nuovo modo di fare le cose, ma le idee dietro Observer, Strategy, Dependency Injection o Repository restano lì da decenni e continuano a sostenere i sistemi ben progettati.",[25,844,845],{},"Infine i pattern facilitano la comunicazione tecnica. Quando un team condivide un linguaggio comune di progettazione, molte decisioni diventano più rapide da spiegare e comprendere. Questo riduce incomprensioni, tempi di onboarding e attriti nelle code review.",[46,847,849],{"id":848},"i-pattern-che-contano-davvero-nella-pratica","I pattern che contano davvero nella pratica",[25,851,852],{},"Non serve conoscerne decine. Nella maggior parte dei progetti bastano pochi concetti ben applicati. Isolare l’accesso ai dati evita che la logica di business dipenda direttamente dal database o dall’ORM. Separare i componenti tramite eventi permette di aggiungere comportamenti senza modificare codice esistente. Incapsulare le varianti di comportamento aiuta a introdurre nuove funzionalità senza toccare quelle già funzionanti. Centralizzare la creazione di oggetti complessi riduce duplicazioni e incoerenze, mentre gestire le dipendenze in modo esplicito rende il codice più modulare e testabile. Applicati con criterio, questi principi risolvono una parte enorme dei problemi architetturali che emergono nel tempo.",[46,854,856],{"id":855},"lerrore-di-valutare-gli-sviluppatori-per-tecnologia","L’errore di valutare gli sviluppatori per tecnologia",[25,858,859],{},"Molti annunci di lavoro cercano esperienza su uno specifico framework. Questo porta ad assumere persone molto competenti su uno strumento, ma non necessariamente sulla progettazione del sistema. In un contesto dove il codice si può scrivere più velocemente che mai, la differenza la fa chi sa progettare prima di implementare.",[46,861,863],{"id":862},"cosa-significa-per-chi-investe-in-un-prodotto-software","Cosa significa per chi investe in un prodotto software",[25,865,866],{},"Un sistema progettato con principi chiari è un sistema che può evolvere. Puoi cambiare un componente senza effetti a catena. Puoi aggiungere funzionalità senza dover riscrivere ciò che esiste.",[25,868,869,870,873,874,276],{},"Un sistema costruito senza queste basi funziona finché non devi modificarlo, e nel software, prima o poi, ",[40,871,872],{"href":152},"devi sempre modificarlo",". È così che nascono le riscritture, i ritardi e i costi che ",[40,875,876],{"href":293},"esplodono oltre le stime",[46,878,880],{"id":879},"il-futuro-appartiene-a-chi-progetta","Il futuro appartiene a chi progetta",[25,882,883],{},"L’AI sta rendendo la scrittura del codice più accessibile e veloce. Ma progettare un sistema che regge nel tempo richiede ancora competenze umane.",[25,885,886],{},"I design pattern non sono teoria accademica. Sono strumenti pratici che determinano quanto un software sarà semplice da mantenere, estendere e far evolvere.",[25,888,889],{},"Il codice può essere riscritto. Una buona progettazione ti evita di doverlo fare.",{"title":170,"searchDepth":171,"depth":171,"links":891},[892,893,894,895,896,897],{"id":813,"depth":171,"text":814},{"id":835,"depth":171,"text":836},{"id":848,"depth":171,"text":849},{"id":855,"depth":171,"text":856},{"id":862,"depth":171,"text":863},{"id":879,"depth":171,"text":880},"2026-02-19","I design pattern restano rilevanti anche quando l'AI scrive codice. Perché la progettazione pesa più del linguaggio, e cosa significa per sviluppatori e team.","/images/blog/design-pattern-oltre-il-linguaggio.jpg",{},"/blog/2026-02-19-design-pattern-oltre-il-linguaggio",{"title":783,"description":899},"Design pattern software: perché valgono più del codice","design-pattern-oltre-il-linguaggio","blog/2026-02-19-design-pattern-oltre-il-linguaggio",[6,908,909,477,478],"design-pattern","ai","YlKUUsNpmncnStaN1tL8UxKNj0lB75sMDlSIrjA9Oa4",{"id":912,"title":913,"body":914,"category":7,"date":1095,"description":1096,"extension":194,"image":1097,"meta":1098,"navigation":3,"path":1099,"published":3,"seo":1100,"seoTitle":1101,"slug":1102,"stem":1103,"tags":1104,"updated":208,"__hash__":1112},"blog/blog/2026-02-10-backend-frontend-separati-costi.md","Separare backend e frontend: quando ha senso (e quando no)",{"type":22,"value":915,"toc":1074},[916,921,924,928,932,935,939,946,949,953,957,960,964,971,975,983,987,994,998,1002,1009,1016,1020,1023,1027,1030,1034,1037,1041,1044,1050,1056,1060,1063,1067],[25,917,918],{},[28,919,920],{},"\"Separiamo backend e frontend così le API sono riusabili.\" Questa frase, in molti progetti, porta a costi di sviluppo molto più alti del necessario. Perché nella teoria suona perfetta — architettura pulita, disaccoppiamento, flessibilità futura. Nella pratica? API progettate di fretta per servire un solo frontend, documentazione assente o incompleta, e un costo di sviluppo che è molto più alto di quello che sarebbe stato necessario.",[25,922,923],{},"Se stai avviando un progetto e qualcuno ti propone di separare backend e frontend \"per il futuro\", fermati. Quel futuro spesso non arriva nei tempi immaginati — e intanto stai pagando oggi per una flessibilità che potresti non usare.",[46,925,927],{"id":926},"perché-si-separa-backend-e-frontend","Perché si separa backend e frontend",[54,929,931],{"id":930},"la-promessa-della-riusabilità","La promessa della riusabilità",[25,933,934],{},"Il ragionamento è questo: costruisci un backend con API REST (o GraphQL), e poi qualsiasi frontend può consumarle. Vuoi un'app mobile? Collegala alle stesse API. Un partner vuole integrarsi? Le API sono già pronte. Vuoi rifare il frontend con un altro framework? Il backend non cambia. In teoria è elegante. In pratica, succede qualcos'altro.",[54,936,938],{"id":937},"la-realtà-api-frontend-driven-senza-documentazione","La realtà: API frontend-driven senza documentazione",[25,940,941,942,945],{},"Il team ha poco tempo. Le scadenze sono strette. Quindi le API vengono progettate ",[28,943,944],{},"per il frontend che si sta costruendo",", non per un consumatore generico. Ogni endpoint restituisce esattamente i dati che quella specifica vista necessita. Le risposte sono modellate sulla struttura delle pagine, non sulle entità di business.",[25,947,948],{},"Risultato: le API difficilmente risultano davvero riusabili. Sono il backend di quel frontend specifico, con un livello di indirezione in più che non aggiunge valore ma aggiunge complessità. E la documentazione? Spesso è assente o incompleta. Quando tra un anno qualcuno proverà a usare quelle API per un'app mobile, dovrà leggere il codice del frontend per capire cosa fanno gli endpoint.",[46,950,952],{"id":951},"quanto-costa-davvero-la-separazione","Quanto costa davvero la separazione",[54,954,956],{"id":955},"doppio-lavoro-su-autenticazione-e-autorizzazione","Doppio lavoro su autenticazione e autorizzazione",[25,958,959],{},"Con un'applicazione monolitica, l'autenticazione è un problema risolto: sessione server-side, cioè gestita dal server stesso, middleware, e via. Con API separate devi gestire token JWT, cioè credenziali firmate che identificano l’utente, refresh token, CORS, cioè le regole che permettono o bloccano chiamate tra domini diversi, e tutta l'infrastruttura di autenticazione stateless, cioè senza memoria di sessione sul server. È lavoro aggiuntivo che in un monolite spesso non è necessario.",[54,961,963],{"id":962},"doppia-gestione-degli-errori","Doppia gestione degli errori",[25,965,966,967,970],{},"Nel monolite, un errore mostra una pagina di errore. Fine. Con backend e frontend separati, devi progettare un contratto di errore: codici HTTP, formati di risposta, messaggi localizzati, gestione dei timeout, retry logic. E il frontend deve interpretare tutto e mostrare messaggi sensati all'utente. Ogni caso limite va gestito ",[28,968,969],{},"due volte"," — una lato backend, una lato frontend. Il tempo di sviluppo aumenta sensibilmente su ogni funzionalità che gestisce errori.",[54,972,974],{"id":973},"doppio-deploy-doppio-ambiente-doppio-debugging","Doppio deploy, doppio ambiente, doppio debugging",[25,976,977,978,982],{},"Due repository. Due pipeline di CI/CD. Due ambienti di staging. Due set di variabili d'ambiente. Quando qualcosa si rompe in produzione, devi capire se il bug è nel backend, nel frontend, o nel contratto tra i due. Il debugging diventa un'investigazione tra due codebase che parlano attraverso HTTP. Con un ",[40,979,981],{"href":980},"/blog/monolite-vs-microservizi","monolite",", apri un file, metti un breakpoint, e vedi cosa succede. Con due applicazioni separate, apri due terminali, due debugger, e l’analisi diventa più complessa.",[54,984,986],{"id":985},"il-costo-in-termini-di-team","Il costo in termini di team",[25,988,989,990,276],{},"Spesso servono competenze distinte: sviluppatori backend e sviluppatori frontend. O sviluppatori full-stack che però devono fare context switch continuo tra due mondi. Il risultato è che o hai un team più grande, o hai persone meno efficaci perché spalmano la loro attenzione su due codebase. Trovare sviluppatori senior è già difficile: trovarne due tipi diversi per lo stesso progetto è ",[40,991,993],{"href":992},"/blog/come-assumere-sviluppatori-bravi","una complessità in più",[46,995,997],{"id":996},"lalternativa-laravel-inertia-e-il-monolite-moderno","L'alternativa: Laravel Inertia e il monolite moderno",[54,999,1001],{"id":1000},"cosè-laravel-inertia-spiegato-semplice","Cos'è Laravel Inertia (spiegato semplice)",[25,1003,1004,1005,1008],{},"Laravel Inertia è un approccio che ti dà il ",[28,1006,1007],{},"meglio dei due mondi",": tutta la potenza del backend Laravel, con routing, autenticazione, autorizzazione, ORM, cioè il livello che collega oggetti del codice e tabelle del database, e sessioni, con un frontend moderno in Vue, React o Svelte, senza la necessità di API REST, JWT e configurazioni CORS.",[25,1010,1011,1012,1015],{},"Il frontend e il backend vivono nello ",[28,1013,1014],{},"stesso progetto",": il backend passa i dati direttamente ai componenti frontend, come se fossero viste server-rendered, ma con tutta l'interattività di una single-page application.",[54,1017,1019],{"id":1018},"cosa-elimini","Cosa elimini",[25,1021,1022],{},"Con questo approccio elimini una serie di costi strutturali: non hai bisogno di API REST dedicate perché i dati fluiscono direttamente dal controller Laravel ai componenti Vue o React; non devi costruire un’autenticazione stateless perché usi le sessioni di Laravel, già consolidate; il tema CORS scompare perché si tratta della stessa applicazione; non devi mantenere documentazione API interna per un frontend che vive nello stesso progetto; e naturalmente eviti il doppio deploy, con un solo ambiente da mantenere.",[54,1024,1026],{"id":1025},"cosa-tieni","Cosa tieni",[25,1028,1029],{},"Allo stesso tempo tieni ciò che di solito interessa davvero a chi vuole separare. Continui a scrivere un frontend moderno con componenti Vue o React, ottieni l’interattività tipica di una SPA e mantieni una struttura pulita in cui il backend gestisce logica, dati e autorizzazione, mentre il frontend si occupa di presentazione e interazione.",[54,1031,1033],{"id":1032},"per-chi-funziona","Per chi funziona",[25,1035,1036],{},"Inertia funziona perfettamente per la grande maggioranza dei progetti web: SaaS, dashboard, applicazioni CRUD, portali, e-commerce, piattaforme interne. Non funziona se hai davvero bisogno di API pubbliche, se il frontend deve funzionare offline, o se hai più client diversi che consumano gli stessi dati. Nella mia esperienza, una minoranza dei progetti rientra in queste eccezioni.",[46,1038,1040],{"id":1039},"ma-se-poi-ci-serve-lapp-mobile","\"Ma se poi ci serve l'app mobile?\"",[25,1042,1043],{},"Questa è l'obiezione più comune. La risposta ha due parti.",[25,1045,1046,1049],{},[28,1047,1048],{},"Primo: spesso non si rivela necessario."," Molti progetti che separano backend e frontend \"per l'app mobile\" non costruiranno mai quell'app, oppure lo faranno quando i requisiti saranno molto diversi da quelli di oggi.",[25,1051,1052,1055],{},[28,1053,1054],{},"Secondo: se ti serve, puoi aggiungerla dopo."," Aggiungere un layer API a un monolite esistente è spesso più semplice che costruire tutto separato dall'inizio. La logica di business esiste già: devi solo esporre degli endpoint progettati per il client reale, non per uno ipotetico. Il costo di aggiungere API in un secondo momento è spesso inferiore al costo di mantenerle dal giorno zero quando nessuno le usa.",[46,1057,1059],{"id":1058},"il-vero-costo-della-decisione-sbagliata","Il vero costo della decisione sbagliata",[25,1061,1062],{},"Facciamo i conti su un progetto medio, per esempio un SaaS con autenticazione, dashboard, gestione dati e qualche integrazione. Con backend e frontend separati devi impostare autenticazione JWT, gestire gli errori su entrambi i lati, configurare e mantenere due pipeline CI/CD, toccare due codebase per quasi ogni feature e affrontare debugging più lento su ogni bug. Con Laravel Inertia, o strumenti simili, usi le sessioni Laravel per l’autenticazione, concentri la gestione errori in un solo punto, fai un solo deploy e in genere ogni feature si traduce in un controller e un componente. La separazione porta quindi molto spesso a costi sensibilmente più alti rispetto a un monolite con Inertia, senza benefici concreti nel breve periodo.",[46,1064,1066],{"id":1065},"come-prendere-la-decisione-giusta","Come prendere la decisione giusta",[25,1068,1069,1070,1073],{},"Prima di separare, conviene chiedersi se oggi esista davvero più di un client che consumerà quelle API, se quelle API verranno documentate e mantenute come un prodotto, se il team ha le competenze per gestire due codebase e se il ",[40,1071,1072],{"href":293},"time-to-market"," sia critico. Se a queste domande manca un “sì” chiaro, il monolite moderno con Inertia resta spesso la scelta più efficace.",{"title":170,"searchDepth":171,"depth":171,"links":1075},[1076,1080,1086,1092,1093,1094],{"id":926,"depth":171,"text":927,"children":1077},[1078,1079],{"id":930,"depth":176,"text":931},{"id":937,"depth":176,"text":938},{"id":951,"depth":171,"text":952,"children":1081},[1082,1083,1084,1085],{"id":955,"depth":176,"text":956},{"id":962,"depth":176,"text":963},{"id":973,"depth":176,"text":974},{"id":985,"depth":176,"text":986},{"id":996,"depth":171,"text":997,"children":1087},[1088,1089,1090,1091],{"id":1000,"depth":176,"text":1001},{"id":1018,"depth":176,"text":1019},{"id":1025,"depth":176,"text":1026},{"id":1032,"depth":176,"text":1033},{"id":1039,"depth":171,"text":1040},{"id":1058,"depth":171,"text":1059},{"id":1065,"depth":171,"text":1066},"2026-02-10","Separare backend e frontend con API REST: quando ha davvero senso per il tuo progetto e quando un monolite moderno (Laravel + Inertia, Rails) costa meno e scala uguale.","/images/blog/backend-frontend-separati-costi.jpg",{},"/blog/2026-02-10-backend-frontend-separati-costi",{"title":913,"description":1096},"Separare backend e frontend: quando conviene davvero","backend-frontend-separati-costi","blog/2026-02-10-backend-frontend-separati-costi",[6,1105,1106,1107,1108,1109,1110,1111,477],"backend","frontend","api-rest","laravel","inertia","startup","costo-sviluppo","i7dz3-lnoxwPitFPo9eTt-sRbJLJpgnjgb2tjpqo5Hk",{"id":1114,"title":1115,"body":1116,"category":7,"date":1283,"description":1284,"extension":194,"image":1285,"meta":1286,"navigation":3,"path":1287,"published":3,"seo":1288,"seoTitle":1289,"slug":1290,"stem":1291,"tags":1292,"updated":208,"__hash__":1297},"blog/blog/2026-01-22-riscrivere-software-da-zero.md","Riscrivere un software da zero: quando ha senso e quando no",{"type":22,"value":1117,"toc":1265},[1118,1123,1126,1130,1133,1136,1139,1143,1147,1150,1154,1157,1161,1168,1175,1179,1182,1188,1192,1196,1199,1203,1206,1210,1217,1221,1224,1228,1231,1238,1242,1245,1248,1251,1255,1262],[25,1119,1120],{},[28,1121,1122],{},"\"Questo codice è irrecuperabile. Dobbiamo riscrivere tutto da zero.\" Ecco, questa frase costa quanto poche altre nel mondo dello sviluppo software. Ogni volta che la senti, puoi scommettere che la riscrittura è già costata il triplo del previsto, ha preso il doppio del tempo, e alla fine ti ritrovi con gli stessi vecchi compromessi di prima — solo che adesso si chiamano in un altro modo.",[25,1124,1125],{},"Riscrivere tutto da capo è la tentazione più forte, e anche la più rischiosa, per un team di sviluppo. Chi prende decisioni sul prodotto dovrebbe trattare questa scelta come tratterebbe un investimento da centinaia di migliaia di euro. Perché, alla fine, è esattamente quello.",[46,1127,1129],{"id":1128},"perché-il-team-vuole-riscrivere","Perché il team vuole riscrivere",[25,1131,1132],{},"Prima di tutto, questa voglia di cancellare tutto e ripartire non viene dal nulla. Quando il team dice che il codice è un disastro, non sta inventando. Il debito tecnico esiste, le nuove feature richiedono troppo tempo, i bug spuntano come funghi, e la frustrazione di lavorare su quel codice difficile è reale.",[25,1134,1135],{},"Però c’è un salto logico tra “questo codice è ingestibile” e “dobbiamo buttare via tutto”. Sarebbe come dire: “la casa ha problemi all’impianto idraulico, quindi demoliamola.” A volte serve davvero. Quasi sempre, no.",[25,1137,1138],{},"Riscrivere da zero è così allettante perché ti fa sognare un foglio bianco. Tutti gli errori del passato spariscono, niente più compromessi, niente più codice incomprensibile. Stavolta faremo tutto bene. Peccato che quel “tutto bene” sia solo un’illusione.",[46,1140,1142],{"id":1141},"perché-le-riscritture-vanno-male","Perché le riscritture vanno male",[54,1144,1146],{"id":1145},"il-vecchio-sistema-sa-più-di-quanto-pensi","Il vecchio sistema sa più di quanto pensi",[25,1148,1149],{},"Joel Spolsky l’ha detto nel 2000 e non è cambiato nulla: quel codice brutto, pieno di hack e workaround, contiene anni di conoscenza nascosta. Ogni if strano, ogni commento oscuro, ogni pezzo di codice scritto in emergenza rappresenta un problema già scoperto e risolto, una regola di business che nessuno si ricorda più, ma che è fondamentale. Riscrivendo da zero butti via tutto questo. E lo riscopri nel modo peggiore: un cliente alla volta che ti segnala un bug che il vecchio sistema, per quanto brutto, gestiva.",[54,1151,1153],{"id":1152},"i-requisiti-non-aspettano","I requisiti non aspettano",[25,1155,1156],{},"Mentre il team riscrive, il resto dell’azienda non si ferma. I clienti vogliono ancora nuove feature. I competitor lanciano aggiornamenti. Il mercato si muove. A quel punto hai due scelte, nessuna delle due bella: o blocchi lo sviluppo del vecchio sistema per concentrarti sulla riscrittura (e il prodotto non evolve per mesi), oppure porti avanti entrambi insieme (il team si divide, le energie si dimezzano, e la riscrittura sembra non finire mai).",[54,1158,1160],{"id":1159},"le-stime-sono-sempre-sbagliate","Le stime sono sempre sbagliate",[25,1162,1163,1164,1167],{},"Gli sviluppatori ",[40,1165,1166],{"href":293},"sbagliano a stimare quasi per definizione",", ma quando si parla di riscritture è ancora peggio. Il team conta solo le cose visibili: le feature. Peccato che il vero lavoro sia tutto quello che non si vede: gestione degli errori, casi limite, integrazioni, migrazioni dati, performance.",[25,1169,1170,1171,1174],{},"La verità? ",[28,1172,1173],{},"Prendi la stima del team e moltiplica per tre."," Se dicono sei mesi, preparati a diciotto. Non è pessimismo: è la media di come vanno davvero le riscritture che ho visto.",[54,1176,1178],{"id":1177},"i-compromessi-torneranno","I compromessi torneranno",[25,1180,1181],{},"Ecco la parte più dura da accettare. I compromessi nel vecchio codice non ci sono perché chi c’era prima era incapace. Sono nati perché il business aveva limiti reali: scadenze, budget, richieste che cambiavano all’ultimo. Quei limiti sono ancora qui. Anche il nuovo team, sotto pressione, finirà per fare le stesse scelte.",[25,1183,1184,1185,276],{},"Dai due anni, e il codice \"nuovo\" avrà già il suo debito tecnico, i suoi workaround, e qualcuno proporrà: \"Riscriviamo tutto da zero.\" È la stessa dinamica per cui ",[40,1186,1187],{"href":152},"il software ha costi di manutenzione continui",[46,1189,1191],{"id":1190},"cosa-fare-invece-di-riscrivere","Cosa fare invece di riscrivere",[54,1193,1195],{"id":1194},"refactoring-incrementale","Refactoring incrementale",[25,1197,1198],{},"Non buttare via tutto. Migliora il sistema un pezzo alla volta. Questo è il refactoring incrementale: cambiare e ripulire il codice senza riscrivere l’intero prodotto da capo. Parti dai moduli che causano più problemi, quelli pieni di bug e quelli dove ogni nuova feature è un incubo, e sistemali uno dopo l’altro. Il bello di questo approccio? Il prodotto continua a funzionare, il team continua a consegnare, e ogni passo avanti si vede davvero. Non è emozionante come un foglio bianco, ma funziona.",[54,1200,1202],{"id":1201},"strangler-fig-pattern","Strangler fig pattern",[25,1204,1205],{},"Se davvero c’è una parte che non si salva, estraila. Costruisci il nuovo componente accanto al vecchio, sposta il traffico poco alla volta, e quando il nuovo funziona (con utenti veri, in produzione), spegni il vecchio. È la versione più pragmatica della riscrittura: non butti mai tutto insieme, non rischi mai di restare senza sistema funzionante, e puoi fermarti quando vuoi, con qualcosa che già funziona.",[54,1207,1209],{"id":1208},"investi-nel-testing-prima-di-toccare-il-codice","Investi nel testing prima di toccare il codice",[25,1211,1212,1213,1216],{},"Se il team ha paura di cambiare perché “potremmo rompere qualcosa”, il primo investimento è una ",[40,1214,1215],{"href":578},"suite di test",", non la riscrittura. Quando i test coprono i flussi critici, il refactoring diventa sicuro. Senza test, sia la riscrittura che il refactoring sono solo una scommessa.",[54,1218,1220],{"id":1219},"scrivi-le-regole-di-business","Scrivi le regole di business",[25,1222,1223],{},"Il vero problema, spesso, sta nelle regole di business che nessuno sa davvero spiegare, più che nel codice. Prima di pensare a una riscrittura, fermati e documenta tutte le regole di business. Parla con chi usa il prodotto, con chi lo ha progettato, con chi si occupa dei casi limite. Quella documentazione vale più di qualsiasi nuova versione del codice.",[46,1225,1227],{"id":1226},"quando-la-riscrittura-ha-senso-davvero","Quando la riscrittura ha senso davvero",[25,1229,1230],{},"Ci sono casi in cui riscrivere è una scelta legittima. Se il tuo prodotto gira su una tecnologia abbandonata, che nessuno sa più mantenere e da cui non esiste una migrazione praticabile, la riscrittura può essere l’unica strada. Lo stesso vale quando il dominio è cambiato davvero: magari hai costruito un tool interno che ora deve diventare un SaaS multi-tenant con migliaia di utenti, e l’architettura originaria non regge più. In quel caso non stai inseguendo il refactoring di un difetto, stai affrontando un cambio di natura del prodotto.",[25,1232,1233,1234,1237],{},"La riscrittura può anche avere senso se il codebase è ancora piccolo. Un ",[40,1235,1236],{"href":710},"MVP nato in pochi mesi"," si può rifare; cinque anni di lavoro, molto meno. In quasi tutti gli altri casi, però, il refactoring incrementale resta la strada più sensata.",[46,1239,1241],{"id":1240},"le-domande-da-farsi-prima-di-dire-sì-a-una-riscrittura","Le domande da farsi prima di dire sì a una riscrittura",[25,1243,1244],{},"Se il tuo team propone di buttare tutto e ricominciare, le domande da fare sono molto concrete. Che cosa non funziona esattamente? Se la risposta resta vaga, del tipo “è un casino”, bisogna fermarsi e pretendere un’analisi precisa. Avete già provato a migliorare il codice poco per volta? Se no, vale la pena capire perché.",[25,1246,1247],{},"Poi c’è il lato economico: quanto ci costa non fare nulla per sei mesi? Quanti bug finiscono in produzione, quanto tempo in più richiede ogni feature, quanti soldi perdiamo? E quali funzionalità smetteremo di sviluppare mentre il team riscrive tutto? Questo è il costo opportunità che quasi nessuno considera.",[25,1249,1250],{},"Infine c’è la domanda più pratica di tutte: come spostiamo dati e utenti? Se il team non ha un piano preciso, non è pronto a riscrivere.",[46,1252,1254],{"id":1253},"riscrivere-tutto-è-spesso-il-sintomo-di-un-problema-di-processo-non-la-sua-soluzione","Riscrivere tutto è spesso il sintomo di un problema di processo, non la sua soluzione.",[25,1256,1257,1258,1261],{},"Lo so, è dura da accettare, ma è la verità. Se il team vuole riscrivere tutto, ",[28,1259,1260],{},"qualcosa si è rotto nel processo — non solo nel codice."," Manca il refactoring continuo. Mancano standard. Nessuno trova il tempo per la manutenzione. È debito tecnico che si accumula sprint dopo sprint, senza mai pagarlo. La riscrittura non aggiusta questo problema. Lo azzera per un po’, tutto qui. Se il processo resta com’era, tra due anni sarai di nuovo nello stesso punto.",[25,1263,1264],{},"Meglio investire nel processo. Meglio investire in refactoring continuo. Meglio dare al team il tempo per lavorare bene, davvero. Costa meno di una riscrittura, e porta più lontano.",{"title":170,"searchDepth":171,"depth":171,"links":1266},[1267,1268,1274,1280,1281,1282],{"id":1128,"depth":171,"text":1129},{"id":1141,"depth":171,"text":1142,"children":1269},[1270,1271,1272,1273],{"id":1145,"depth":176,"text":1146},{"id":1152,"depth":176,"text":1153},{"id":1159,"depth":176,"text":1160},{"id":1177,"depth":176,"text":1178},{"id":1190,"depth":171,"text":1191,"children":1275},[1276,1277,1278,1279],{"id":1194,"depth":176,"text":1195},{"id":1201,"depth":176,"text":1202},{"id":1208,"depth":176,"text":1209},{"id":1219,"depth":176,"text":1220},{"id":1226,"depth":171,"text":1227},{"id":1240,"depth":171,"text":1241},{"id":1253,"depth":171,"text":1254},"2026-01-22","Riscrivere un software da zero costa più del previsto e spesso non risolve il problema reale. Quando conviene davvero, quando no, e le alternative che funzionano (strangler pattern, refactoring incrementale).","/images/blog/riscrivere-software-da-zero.jpg",{},"/blog/2026-01-22-riscrivere-software-da-zero",{"title":1115,"description":1284},"Riscrivere software da zero: rischi, costi e alternative","riscrivere-software-da-zero","blog/2026-01-22-riscrivere-software-da-zero",[1293,1294,779,1295,1296],"riscrivere-software","refactoring","modernizzazione","scelta-tecnica","bPm3Pyn7B5r-OTd0BW7zOBPcE4ueVGg_Z-H6KtvWN0Q",{"id":1299,"title":1300,"body":1301,"category":7,"date":1434,"description":1435,"extension":194,"image":1436,"meta":1437,"navigation":3,"path":1438,"published":3,"seo":1439,"seoTitle":1440,"slug":1441,"stem":1442,"tags":1443,"updated":208,"__hash__":1447},"blog/blog/2026-01-20-monolite-vs-microservizi.md","Monolite vs microservizi: quando servono davvero i servizi distribuiti",{"type":22,"value":1302,"toc":1421},[1303,1312,1315,1319,1322,1325,1332,1336,1340,1343,1346,1350,1353,1357,1360,1363,1367,1370,1373,1381,1385,1388,1391,1395,1398,1401,1403,1410,1414],[25,1304,1305],{},[28,1306,1307,1308,1311],{},"Prima o poi, in ogni startup arriva quel momento. Di solito parte tutto dallo sviluppatore più carico del gruppo: \"Dobbiamo passare ai microservizi. Il monolite non scala! Guarda Netflix, loro sì che lo fanno. Dobbiamo pensare in grande.\" E così, senza accorgersene, il team si lancia in una ",[40,1309,1310],{"href":516},"migrazione che dura mesi",", non risolve i veri problemi, e ne tira fuori di nuovi.",[25,1313,1314],{},"Se il tuo prodotto va bene così com’è, monolitico, cioè raccolto in un’unica applicazione, forse conviene lasciarlo stare. Non è che i microservizi, cioè tanti servizi separati che collaborano tra loro, siano sbagliati: semplicemente risolvono problemi che probabilmente tu non hai.",[46,1316,1318],{"id":1317},"il-vero-problema-che-risolvono-i-microservizi","Il vero problema che risolvono i microservizi",[25,1320,1321],{},"I microservizi risolvono diversi problemi tecnici reali, ma nella pratica diventano davvero utili soprattutto quando la complessità organizzativa del team cresce molto.",[25,1323,1324],{},"In organizzazioni molto grandi, come Netflix, Amazon o Google, se tutti lavorano sullo stesso prodotto, il monolite diventa una gabbia. Ogni rilascio richiede che i team si parlino, si sincronizzino. Se c’è un bug da una parte, blocca tutto il resto. Le riunioni di allineamento portano via più tempo dello sviluppo.",[25,1326,1327,1328,1331],{},"Qui i microservizi funzionano: ogni team ha il suo servizio, lo rilascia quando vuole, e parla con gli altri solo tramite API chiare. Certo, il prezzo è la complessità tecnica di gestire tanti servizi. Il vantaggio? Ogni team può andare per conto suo. ",[28,1329,1330],{},"Se il team è piccolo e ben coordinato, spesso questo problema è molto meno rilevante."," Bastano due parole a voce e si risolve tutto, i deploy sono semplici, e tutta la fatica aggiuntiva dei microservizi non porta nessun beneficio vero.",[46,1333,1335],{"id":1334},"cosa-succede-davvero-quando-ti-butti-sui-microservizi-troppo-presto","Cosa succede davvero quando ti butti sui microservizi troppo presto",[54,1337,1339],{"id":1338},"la-complessità-operativa-schizza-alle-stelle","La complessità operativa schizza alle stelle",[25,1341,1342],{},"Un monolite? È un processo, un database, un deploy e via. Con i microservizi ti ritrovi con decine di processi, spesso anche più database, mille pipeline di deploy, e una rete di servizi da tenere in piedi. All’improvviso ti servono service discovery, cioè meccanismi per far sì che i servizi si trovino tra loro, bilanciamento del carico, circuit breaker per i guasti, tracing distribuito per seguire una richiesta che passa da cinque servizi diversi, logging centralizzato per raccogliere i log da ogni dove. E qualcuno deve pure occuparsene, ogni giorno.",[25,1344,1345],{},"Così il tuo team di cinque persone, che prima lavorava solo sulle funzionalità, ora passa quasi metà del tempo a tenere in piedi l’infrastruttura. Rischi di ridurre sensibilmente la velocità di sviluppo per inseguire un problema che non avevi.",[54,1347,1349],{"id":1348},"il-debugging-diventa-un-incubo","Il debugging diventa un incubo",[25,1351,1352],{},"Nel monolite, quando qualcosa va storto, hai uno stack trace. Lo leggi, capisci dov’è il guaio, lo sistemi. Nei microservizi, la stessa richiesta dell’utente viaggia tra quattro servizi diversi. L’errore può essere ovunque: in uno dei servizi, nella comunicazione tra loro, nel message broker, in un timeout di rete, o in una race condition che si mostra solo se le risposte arrivano in un certo ordine. Risultato? Risolvere un bug in un sistema distribuito può richiedere molto più tempo rispetto a un monolite. Se sei un team piccolo, questa cosa ti spezza.",[54,1354,1356],{"id":1355},"la-gestione-della-coerenza-dei-dati-diventa-molto-più-complessa","La gestione della coerenza dei dati diventa molto più complessa",[25,1358,1359],{},"Nel monolite hai una transazione bella pulita. Inizi, fai le operazioni, commit o rollback. I dati restano sempre a posto. Nei microservizi, ogni servizio si tiene il suo database. Se devi fare un’operazione che coinvolge due servizi, entri nel magico mondo della consistenza eventuale — saga, outbox, compensazione. Devi gestire il caso in cui il primo servizio va, il secondo no. E nel frattempo, cosa mostri all’utente?",[25,1361,1362],{},"Non è impossibile, per carità. Solo che ora ti ritrovi con una complessità vera, che prima non avevi. Devi progettarla, implementarla, testarla, mantenerla. E questo vale per ogni singola operazione che passa tra più servizi.",[46,1364,1366],{"id":1365},"ma-il-monolite-non-scala","\"Ma il monolite non scala!\"",[25,1368,1369],{},"Questa è un’idea molto diffusa, ma spesso imprecisa. Un monolite scritto bene scala eccome. Puoi aumentare la potenza del server (scaling verticale) o aggiungere più istanze dietro a un load balancer (scaling orizzontale), senza grossi drammi. Laravel, Rails e Django possono gestire carichi molto elevati su infrastrutture moderne, se configurati e ottimizzati correttamente.",[25,1371,1372],{},"E sai quante richieste al secondo riceve davvero il tuo prodotto? Se non hai idea, di solito sono molte meno di quello che pensi. Nella pratica, molte web app ricevono un carico molto inferiore a quello che si immagina: un server solo le regge senza problemi — basta che il database sia ottimizzato.",[25,1374,1375,1376,1380],{},"Molto spesso il vero collo di bottiglia è proprio ",[40,1377,1379],{"href":1378},"/blog/web-app-lenta-problema-database","il database",". Query lente, N+1 che non vedi, indici che mancano. Questi problemi ce li hai sia nei monoliti che nei microservizi — anzi, con i microservizi te li ritrovi moltiplicati, uno per ogni servizio.",[46,1382,1384],{"id":1383},"quando-i-microservizi-hanno-davvero-senso","Quando i microservizi hanno davvero senso",[25,1386,1387],{},"I microservizi non sono il male. Hanno senso in situazioni molto specifiche. Per esempio quando hai un team davvero numeroso e la coordinazione diventa un problema concreto, al punto che per fare un deploy servono settimane di sincronizzazione. Oppure quando hai componenti che devono scalare in modo molto diverso, come un servizio che elabora video e richiede cento istanze mentre il resto dell’app ne usa due. O ancora quando esistono esigenze tecniche reali che impongono stack diversi, per esempio machine learning in Python e il resto del sistema in PHP.",[25,1389,1390],{},"Tutte queste sono sfide che in genere arrivano dopo che il prodotto ha avuto successo, non prima. Pensare ai microservizi fin dall’inizio è come comprare un autobus perché “magari un giorno avremo più passeggeri”. Per adesso sei da solo sull’autobus e il parcheggio ti costa un occhio.",[46,1392,1394],{"id":1393},"cosa-fare-invece-dei-microservizi","Cosa fare invece dei microservizi",[25,1396,1397],{},"Quando il monolite inizia a diventare difficile da gestire, quasi sempre la soluzione non è spacchettarlo. Di solito basta organizzarlo meglio. Conviene definire con chiarezza i moduli per domini di business, con confini leggibili; in Laravel puoi usare directory per dominio, in Symfony bounded contexts. Tutto resta nello stesso deploy, ma il codice smette di essere indistinto.",[25,1399,1400],{},"Aiuta anche far comunicare i moduli tramite API interne e interfacce, invece di lasciare import casuali ovunque. Così, se un giorno servirà davvero estrarre un servizio, il confine sarà già pronto. Prima ancora di discutere architettura, poi, bisogna guardare al database: spesso i problemi di scalabilità stanno lì, nelle query. E se il problema è la paura del deploy, conviene investire in CI/CD, test automatici e rilasci frequenti, non in un’architettura che moltiplica i punti di rottura.",[46,1402,584],{"id":583},[25,1404,1405,1406,1409],{},"Se nel tuo team qualcuno propone di passare ai microservizi, le domande da fare sono poche ma precise. Qual è il problema concreto che vogliamo risolvere? Se la risposta resta vaga, con parole come “scalabilità” o “modernizzazione”, è già un campanello d’allarme. Abbiamo davvero le competenze necessarie? Servono skill di DevOps, Kubernetes, networking e monitoring distribuito. E quanto ci costa questa migrazione in termini reali? ",[40,1407,1408],{"href":293},"Le stime su questi passaggi tendono a essere fortemente sottovalutate",". Infine, la domanda più importante: esiste una soluzione più semplice? Molto spesso sì.",[46,1411,1413],{"id":1412},"un-buon-monolite-è-un-vantaggio-competitivo","Un buon monolite è un vantaggio competitivo",[25,1415,1416,1417,1420],{},"Nel 2026, con ",[40,1418,1419],{"href":831},"l'AI che accelera lo sviluppo",", un monolite ben strutturato fa la differenza. Una codebase unica e coerente tende a essere più semplice da navigare anche per gli strumenti AI, con relazioni tra moduli chiare, debug lineare. Invece, su un sistema distribuito, l’AI deve rincorrere servizi, interpretare protocolli, gestire stati sparsi ovunque. La semplicità è una feature, prima ancora che una pecca. E nel software, le feature che ti fanno dormire sereno sono sempre quelle sottovalutate.",{"title":170,"searchDepth":171,"depth":171,"links":1422},[1423,1424,1429,1430,1431,1432,1433],{"id":1317,"depth":171,"text":1318},{"id":1334,"depth":171,"text":1335,"children":1425},[1426,1427,1428],{"id":1338,"depth":176,"text":1339},{"id":1348,"depth":176,"text":1349},{"id":1355,"depth":176,"text":1356},{"id":1365,"depth":171,"text":1366},{"id":1383,"depth":171,"text":1384},{"id":1393,"depth":171,"text":1394},{"id":583,"depth":171,"text":584},{"id":1412,"depth":171,"text":1413},"2026-01-20","Monolite vs microservizi: perché la maggior parte delle startup non ha bisogno di un'architettura distribuita e come un monolite ben fatto scala.","/images/blog/monolite-vs-microservizi.jpg",{},"/blog/2026-01-20-monolite-vs-microservizi",{"title":1300,"description":1435},"Monolite vs microservizi: quando servono davvero","monolite-vs-microservizi","blog/2026-01-20-monolite-vs-microservizi",[6,1444,981,1110,1445,9,1446],"microservizi","scalabilita","gestione-team","XYFDaOyvMwJxflmNkgb2NY9q98j84lqDx5DEIgoah_Q",{"id":1449,"title":1450,"body":1451,"category":7,"date":1599,"description":1600,"extension":194,"image":1601,"meta":1602,"navigation":3,"path":1603,"published":3,"seo":1604,"seoTitle":1605,"slug":1606,"stem":1607,"tags":1608,"updated":208,"__hash__":1613},"blog/blog/2026-01-15-web-app-lenta-problema-database.md","Web app lenta: perché il collo di bottiglia è quasi sempre il database",{"type":22,"value":1452,"toc":1586},[1453,1460,1463,1467,1470,1477,1481,1484,1487,1490,1494,1497,1501,1504,1508,1511,1515,1518,1522,1525,1528,1534,1538,1541,1544,1547,1550,1554,1557,1560,1563,1566,1570,1573,1580,1583],[25,1454,1455,1456,1459],{},"La web app va lenta. Gli utenti si lamentano, il team propone di aumentare le risorse del server. Le prestazioni migliorano per un po’, poi la lentezza ritorna. A quel punto qualcuno propone: \"",[40,1457,1458],{"href":516},"Riscriviamo tutto da zero",".\"",[25,1461,1462],{},"Se questa sequenza ti è familiare, vale la pena considerare un’ipotesi che spesso viene sottovalutata: il collo di bottiglia non è (solo) l’infrastruttura, ma il modo in cui il codice interroga il database. Non è sempre così, ma succede molto più spesso di quanto si pensi.",[46,1464,1466],{"id":1465},"come-funziona-davvero-il-problema-spiegato-semplice","Come funziona davvero il problema (spiegato semplice)",[25,1468,1469],{},"Ogni pagina che un utente apre richiede dati al database. È normale. La differenza la fa quante richieste vengono fatte e come vengono fatte. Immagina di dover mostrare una lista di 100 clienti con il loro ultimo ordine. Una persona andrebbe in archivio e prenderebbe tutte le informazioni necessarie in un’unica consultazione. Un software scritto senza attenzione a questo aspetto può fare qualcosa di molto diverso: recupera l’elenco dei clienti, poi per ciascun cliente va a recuperare separatamente il suo ordine. Il risultato è lo stesso, ma il numero di accessi al database cresce rapidamente.",[25,1471,1472,1473,1476],{},"Questo schema è noto come ",[28,1474,1475],{},"problema N+1",", cioè il caso in cui invece di fare una query ben costruita ne fai una iniziale più tante altre quasi identiche. È una delle cause più frequenti di lentezza nelle applicazioni data-driven: i dati sono corretti, ma il modo in cui vengono recuperati è inefficiente. L’aspetto meno intuitivo è che il codice che produce questo comportamento può apparire perfettamente ordinato e conforme alle best practice del framework. Senza misurazioni, è facile non accorgersene.",[46,1478,1480],{"id":1479},"perché-succede-e-perché-spesso-non-si-vede","Perché succede (e perché spesso non si vede)",[25,1482,1483],{},"Molti framework moderni — come Laravel, Symfony, Ruby on Rails o Django — incoraggiano l'uso di ORM e query builder. Strumenti molto utili, che permettono di lavorare in modo produttivo senza scrivere SQL a mano.",[25,1485,1486],{},"Il rovescio della medaglia è che, senza strumenti di osservabilità, diventa facile perdere visibilità su quante query partono per una pagina, quanto tempo impiegano e come scalano al crescere dei dati. Il punto non riguarda gli strumenti in sé, ma le abitudini di monitoraggio. In molti team queste metriche vengono guardate solo quando le prestazioni peggiorano già in produzione.",[25,1488,1489],{},"Il risultato è un paradosso comune: codice pulito e idiomatico per il framework può generare accessi al database poco efficienti, se nessuno misura cosa succede davvero sotto.",[46,1491,1493],{"id":1492},"i-segnali-dallarme-da-tenere-docchio","I segnali d'allarme da tenere d'occhio",[25,1495,1496],{},"Non serve essere tecnici per intercettare alcuni indizi.",[54,1498,1500],{"id":1499},"le-pagine-diventano-più-lente-col-tempo","Le pagine diventano più lente col tempo",[25,1502,1503],{},"All'inizio tutto funziona bene. Con pochi utenti e pochi dati, anche query inefficienti hanno un impatto minimo. Con la crescita dei dati, le stesse query iniziano a pesare molto di più. Se la lentezza aumenta insieme al volume di dati, è probabile che il problema sia nel modo in cui vengono recuperati, non nella quantità in sé.",[54,1505,1507],{"id":1506},"i-costi-dei-server-crescono-più-del-previsto","I costi dei server crescono più del previsto",[25,1509,1510],{},"Quando i costi infrastrutturali aumentano più rapidamente del numero di utenti o del traffico, può essere un segnale di inefficienze applicative — spesso lato database. Non è una diagnosi automatica, ma è un indizio che vale la pena verificare con metriche.",[54,1512,1514],{"id":1513},"si-tende-a-risolvere-con-infrastruttura-e-cache","Si tende a risolvere con infrastruttura e cache",[25,1516,1517],{},"Aumentare le risorse del server o introdurre cache può aiutare molto, e in molti casi è parte della soluzione. Tuttavia, se queste scelte vengono fatte senza aver prima misurato e compreso il carico sul database, si rischia di mascherare inefficienze strutturali invece di risolverle.",[46,1519,1521],{"id":1520},"quanto-costa-ignorare-il-problema","Quanto costa ignorare il problema",[25,1523,1524],{},"Studi di settore, come quelli divulgati da Google tramite Think with Google e analisi di Akamai Technologies, mostrano una correlazione chiara tra tempi di caricamento su mobile, aumento del bounce rate e calo delle conversioni negli e-commerce. Il punto non è il numero esatto di secondi. È il principio: anche piccoli aumenti di latenza possono avere effetti misurabili sul comportamento degli utenti.",[25,1526,1527],{},"Sul piano tecnico, se il database sta gestendo un volume di query molto superiore al necessario, la crescita degli utenti rende il sistema sempre più difficile da scalare. A un certo punto, aumentare le risorse non è più sufficiente o diventa economicamente poco sostenibile.",[25,1529,1530,1531,276],{},"C'è anche un effetto organizzativo: quando le prestazioni diventano un problema ricorrente, ogni nuova funzionalità viene percepita come un rischio, e lo sviluppo rallenta. È il classico scenario in cui il team diventa ",[40,1532,1533],{"href":274},"fragile e ha paura di deployare",[46,1535,1537],{"id":1536},"la-domanda-che-chiarisce-la-situazione","La domanda che chiarisce la situazione",[25,1539,1540],{},"Una domanda semplice aiuta a capire molto:",[25,1542,1543],{},"“Quante query fa la pagina principale?”",[25,1545,1546],{},"Se il team ha un numero aggiornato, significa che misura e osserva. Se la risposta è incerta, probabilmente questa dimensione non è sotto controllo.",[25,1548,1549],{},"Ci sono anche altre domande utili. Abbiamo visibilità sulle query per pagina o endpoint in produzione? Conosciamo la query più lenta e quanto tempo impiega? Le prestazioni sono peggiorate negli ultimi mesi? Se il team riesce a rispondere con precisione, significa che sta osservando il sistema. Se brancola nel vago, il problema è già davanti.",[46,1551,1553],{"id":1552},"cosa-puoi-fare-in-pratica","Cosa puoi fare in pratica",[25,1555,1556],{},"Il primo passo è misurare. Devi ottenere visibilità su quante query vengono eseguite per pagina o endpoint, cioè per ogni singola pagina o punto di accesso del sistema, e quanto tempo impiegano. In sviluppo bastano spesso strumenti di debug; in produzione è preferibile un sistema di monitoring o APM, cioè uno strumento che misura prestazioni ed errori dell’applicazione, che mostri dati reali.",[25,1558,1559],{},"Con i numeri davanti emergono subito i punti critici: pagine con centinaia di query, endpoint lenti, report che stressano il database. Ha più senso partire da lì che ottimizzare in modo generico.",[25,1561,1562],{},"A quel punto si interviene sulle query più pesanti. Molto spesso una piccola parte di schermate o endpoint genera gran parte del carico. Ridurre accessi ridondanti, introdurre join adeguati e verificare indici e piani di esecuzione può produrre un impatto notevole.",[25,1564,1565],{},"Infine serve prevenzione. Una volta sistemati i casi peggiori, conviene introdurre pratiche che impediscano di ricadere nello stesso schema: metriche di performance visibili al team, attenzione alle query in code review e alert quando un endpoint supera certe soglie.",[46,1567,1569],{"id":1568},"quanto-costa-intervenire","Quanto costa intervenire?",[25,1571,1572],{},"In molti casi, intervenire sulle query critiche richiede un effort contenuto rispetto ai benefici ottenuti, soprattutto quando il problema è concentrato in poche aree del prodotto. Non è una regola universale, ma è una situazione frequente nelle applicazioni cresciute nel tempo.",[25,1574,1575,1576,1579],{},"Senza questo lavoro, si finisce per compensare inefficienze con risorse sempre maggiori, fino a dover affrontare interventi molto più costosi e invasivi. O peggio, qualcuno propone di ",[40,1577,1578],{"href":980},"riscrivere tutto il monolite in microservizi"," quando il vero problema era nelle query.",[25,1581,1582],{},"La domanda chiave resta la stessa:",[25,1584,1585],{},"“Quante query fa questa pagina?”",{"title":170,"searchDepth":171,"depth":171,"links":1587},[1588,1589,1590,1595,1596,1597,1598],{"id":1465,"depth":171,"text":1466},{"id":1479,"depth":171,"text":1480},{"id":1492,"depth":171,"text":1493,"children":1591},[1592,1593,1594],{"id":1499,"depth":176,"text":1500},{"id":1506,"depth":176,"text":1507},{"id":1513,"depth":176,"text":1514},{"id":1520,"depth":171,"text":1521},{"id":1536,"depth":171,"text":1537},{"id":1552,"depth":171,"text":1553},{"id":1568,"depth":171,"text":1569},"2026-01-15","Web app lenta e costi server che crescono? Spesso il collo di bottiglia è nel database, non nell'infrastruttura. Come misurare e ottimizzare.","/images/blog/web-app-lenta-problema-database.jpg",{},"/blog/2026-01-15-web-app-lenta-problema-database",{"title":1450,"description":1600},"Web app lenta: cause e ottimizzazione database","web-app-lenta-problema-database","blog/2026-01-15-web-app-lenta-problema-database",[1609,1610,1446,1110,477,207,1611,1612],"performance","database","infrastruttura","web-app","1VwxOM99pAKADu_l8TsM0VczpTBirmO8eNzeIUF7Zts",{"id":1615,"title":1616,"body":1617,"category":7,"date":1878,"description":1879,"extension":194,"image":1880,"meta":1881,"navigation":3,"path":1882,"published":3,"seo":1883,"seoTitle":1884,"slug":1885,"stem":1886,"tags":1887,"updated":208,"__hash__":1893},"blog/blog/2026-01-13-quale-framework-javascript-scegliere.md","React, Vue o Angular: come scegliere il framework JavaScript",{"type":22,"value":1618,"toc":1859},[1619,1622,1625,1629,1632,1635,1638,1641,1645,1648,1652,1655,1661,1667,1673,1677,1680,1685,1690,1695,1699,1702,1707,1712,1718,1722,1725,1731,1737,1743,1746,1750,1757,1761,1764,1767,1771,1774,1777,1781,1784,1787,1791,1794,1797,1800,1804,1807,1813,1816,1820,1823,1826,1833,1836,1840,1843,1846,1850,1853,1856],[25,1620,1621],{},"Periodicamente emergono nuovi framework JavaScript e nuove proposte che promettono di cambiare il modo in cui costruiamo il frontend. Puntuale come la pioggia a novembre, qualcuno nel team propone di buttare via tutto e riscrivere il progetto con la novità del momento. E poi c’è sempre l’articolo di turno che decreta la morte del framework X e l’ascesa inarrestabile di Y. Ma, alla fine, i progetti che davvero funzionano sono quelli dove il team smette di inseguire la moda e impara a lavorare bene con quello che già ha tra le mani.",[25,1623,1624],{},"Se ti stai chiedendo quale framework JavaScript scegliere per un nuovo prodotto, o stai anche solo pensando di cambiare quello che usi già, questo articolo è pensato per te. Non ti darò la risposta secca su quale framework “è il migliore”. Voglio raccontarti invece quali sono i costi reali, cosa cambia davvero nell’uso quotidiano, e soprattutto perché la domanda “quale framework scelgo?” si traduce quasi sempre in “quello che il tuo team conosce meglio”.",[46,1626,1628],{"id":1627},"perché-il-mondo-javascript-e-typescript-è-un-campo-minato","Perché il mondo JavaScript e TypeScript è un campo minato",[25,1630,1631],{},"Prima di parlare dei singoli framework, bisogna capire perché il frontend è così caotico.",[25,1633,1634],{},"JavaScript è nato in fretta, dieci giorni nel ’95 per mettere un po’ di movimento nelle pagine web. Da lì, s’è ingrandito a strati, aggiungendo specifiche, API, convenzioni — senza mai potersi permettere di rompere tutto quello che già funzionava. Poi è arrivato TypeScript a mettere una pezza sulla mancanza di tipi, ma sotto il cofano gira sempre lo stesso motore.",[25,1636,1637],{},"Risultato: ogni pochi anni qualcuno reinventa la gestione dello stato, il routing, il rendering. Non perché chi c’era prima avesse sbagliato, ma perché il web cambia in fretta, gli utenti chiedono sempre di più, e nessuno ha ancora trovato una soluzione definitiva.",[25,1639,1640],{},"Se gestisci un prodotto software, questa è la verità: qualunque framework scegli oggi, tra cinque anni il panorama sarà cambiato di nuovo. Non puoi sapere quale sarà ancora di moda nel 2031. Quello che conta è: quanto ti costerà mantenere e far crescere il progetto che inizi oggi?",[46,1642,1644],{"id":1643},"react-vs-vue-vs-angular-costi-e-compromessi-veri","React vs Vue vs Angular: costi e compromessi veri",[25,1646,1647],{},"Non esiste il framework perfetto. Esistono solo scelte con pro e contro, ed ecco quelli che fanno davvero la differenza.",[54,1649,1651],{"id":1650},"react-tanta-libertà-tanta-responsabilità","React: tanta libertà, tanta responsabilità",[25,1653,1654],{},"React nasce come libreria per costruire interfacce e lascia molte scelte architetturali al team. Tutto il resto — routing, stato, form, fetch dei dati — tocca a te (o meglio, al tuo team) sceglierlo, configurarlo e mantenerlo.",[25,1656,1657,1660],{},[28,1658,1659],{},"Quando conviene usarlo:"," Se hai un team esperto, capace di prendersi responsabilità architetturali, React ti lascia carta bianca. L’ecosistema è il più grande che ci sia: trovi di tutto, sviluppatori ovunque, tonnellate di risorse.",[25,1662,1663,1666],{},[28,1664,1665],{},"Il prezzo da pagare?"," Ogni progetto React è una storia a sé. Non ci sono regole forti su come organizzare codice, gestire lo stato, o strutturare l’app. Quando entra qualcuno di nuovo, non basta che sappia React: deve capire tutte le scelte che il team ha fatto. L’onboarding dura di più, dipendi parecchio da chi ha impostato le cose, e se il team non è solido rischi di prendere decisioni sbagliate che ti inseguono per anni.",[25,1668,1669,1672],{},[28,1670,1671],{},"Il pool di sviluppatori"," Il più vasto che c’è. Trovare gente che conosce React è facile. Trovare gente davvero in gamba, capace di fare anche le scelte architetturali che React non fa per te… beh, quella è un’altra storia.",[54,1674,1676],{"id":1675},"vue-il-compromesso-che-funziona","Vue: il compromesso che funziona",[25,1678,1679],{},"Vue è un framework completo ma progressivo. Puoi usarlo su una singola pagina, ma va benissimo anche per grandi progetti. Ha idee chiare su come si fanno le cose, ma non ti obbliga a seguirle tutte subito.",[25,1681,1682,1684],{},[28,1683,1659],{}," Se vuoi un buon equilibrio tra struttura e libertà. Vue propone convenzioni molto adottate dalla community, come Vue Router e Pinia, che rendono la struttura dei progetti piuttosto omogenea. Un team anche non super esperto diventa produttivo velocemente.",[25,1686,1687,1689],{},[28,1688,1665],{}," L'ecosistema è più piccolo di quello React. Non è la fine del mondo, ma si sente. Alcune librerie particolari esistono solo per React, o arrivano su Vue in ritardo. Anche il bacino di sviluppatori è più ristretto.",[25,1691,1692,1694],{},[28,1693,1671],{}," Buono, e in crescita. Non è grande come quello React, ma chi lavora con Vue spesso ha una preparazione più omogenea, perché il framework impone convenzioni che rendono i progetti più simili tra loro.",[54,1696,1698],{"id":1697},"angular-struttura-rigida-zero-sorprese","Angular: struttura rigida, zero sorprese",[25,1700,1701],{},"Angular è il classico framework “batterie incluse”. Fornisce una struttura molto definita e opinionata su come organizzare un’applicazione: come scrivere il codice, come gestire i form, come funziona la dependency injection, cioè il modo in cui un componente riceve dall’esterno gli oggetti di cui ha bisogno, addirittura come si fanno i test. Davvero, non hai molta voce in capitolo — tutto è già impostato.",[25,1703,1704,1706],{},[28,1705,1659],{}," Se lavori su applicazioni enterprise belle grosse, con team numerosi, dove la coerenza conta più della velocità nei primi mesi. Angular dà il meglio di sé quando ci sono 15 sviluppatori che devono lavorare insieme senza pestarsi i piedi. Le sue regole rigide rendono il codice prevedibile. Se assumi qualcuno che conosce Angular, può orientarsi in fretta in qualsiasi progetto.",[25,1708,1709,1711],{},[28,1710,1665],{}," La curva di apprendimento è la più dura tra i tre. Ci sono tanti concetti da digerire prima di diventare produttivi. I primi mesi vanno lenti. E poi, trovare sviluppatori Angular può essere meno immediato rispetto a React, perché il bacino è più orientato al mondo enterprise, e chi lo conosce bene non è così comune.",[25,1713,1714,1717],{},[28,1715,1716],{},"Il pool di sviluppatori,"," è generalmente più orientato al mondo enterprise ed è meno ampio rispetto a React. Chi usa Angular di solito lo padroneggia (la difficoltà iniziale scoraggia i “turisti”), ma le opzioni per assumere sono poche.",[46,1719,1721],{"id":1720},"svelte-solid-qwik-e-gli-altri-occasione-o-rischio","Svelte, Solid, Qwik e gli altri: occasione o rischio?",[25,1723,1724],{},"Ogni settimana spunta un nuovo framework: Svelte, Solid, Qwik, Astro… Sono tecnicamente validi, alcuni hanno idee geniali. Ma se devi scegliere per motivi di business, i problemi concreti sono tre.",[25,1726,1727,1730],{},[28,1728,1729],{},"Primo:"," il pool di talenti è minuscolo. Se il tuo unico sviluppatore Svelte se ne va, sostituirlo ti costa tempo e soldi. Con React pubblichi un annuncio e ti arrivano 50 candidature. Con Svelte ne ricevi tre, se va bene.",[25,1732,1733,1736],{},[28,1734,1735],{},"Secondo:"," l'ecosistema è ancora acerbo. Ci sono meno librerie, meno integrazioni testate davvero in produzione, poche risposte su Stack Overflow quando il team si blocca alle due di notte.",[25,1738,1739,1742],{},[28,1740,1741],{},"Terzo:"," l’ecosistema è meno maturo e dipende da community più piccole rispetto ai framework principali. I framework minori spesso dipendono da community piccole o da uno o due maintainer. Se la community rallenta, potresti ritrovarti con meno aggiornamenti, meno librerie mantenute e meno risorse disponibili.",[25,1744,1745],{},"Non vuol dire che siano tecnologie sbagliate, sia chiaro. Ma se ci costruisci sopra il tuo business, è una scommessa che devi fare consapevolmente, non solo per entusiasmo.",[46,1747,1749],{"id":1748},"il-fattore-che-cambia-tutto-lai-nello-sviluppo-frontend","Il fattore che cambia tutto: l'AI nello sviluppo frontend",[25,1751,1752,1753,1756],{},"Fino a un anno fa, scegliere il framework era una questione di competenze del team, ecosistema, e tipo di progetto. Adesso c’è un quarto fattore che conta davvero: quanto bene lavorano gli strumenti AI con quel framework. ",[40,1754,1755],{"href":831},"Claude Code, Cursor, Codex","… Gli assistenti AI che stanno rivoluzionando la produttività dei team non funzionano allo stesso modo con ogni framework. E la differenza si sente.",[54,1758,1760],{"id":1759},"angular-e-ai-i-pattern-rigidi-aiutano","Angular e AI: i pattern rigidi aiutano",[25,1762,1763],{},"Sembra strano, ma il framework più “noioso”, nella mia esperienza, è quello con cui gli strumenti AI producono risultati più coerenti. Angular ha pattern rigidi e prevedibili. Un servizio si scrive in un modo solo. Un componente ha sempre la stessa struttura. La dependency injection segue regole precise. Anche i test sono standardizzati.",[25,1765,1766],{},"Per un modello AI, questa prevedibilità tende a ridurre ambiguità e a migliorare la coerenza del codice generato. Quando il pattern è chiaro e milioni di progetti lo ripetono uguale, la struttura più uniforme riduce l’ambiguità per il modello. Meno ambiguità, meno errori.",[54,1768,1770],{"id":1769},"react-e-ai-la-grande-flessibilità-può-portare-a-risultati-meno-coerenti-senza-convenzioni-condivise-nel-progetto","React e AI: la grande flessibilità può portare a risultati meno coerenti senza convenzioni condivise nel progetto",[25,1772,1773],{},"React invece lascia totale libertà, e l’AI fatica proprio per questo. Ogni progetto React ha convenzioni sue. La gestione dello stato si fa con Redux, oppure Zustand, Jotai… o altre dieci librerie. L’organizzazione dei componenti? Mille possibilità. Le stesse cose si possono fare con hook personalizzati, higher-order components, render props o pattern inventati dal team.",[25,1775,1776],{},"L’AI non sa quali regole segue il tuo progetto. Genera codice “giusto per React”, ma spesso incompatibile con le scelte che avete fatto. Risultato: passi più tempo a correggere e adattare che a risparmiare.",[54,1778,1780],{"id":1779},"vue-e-ai-il-compromesso-funziona","Vue e AI: il compromesso funziona",[25,1782,1783],{},"Vue offre un buon equilibrio: le sue convenzioni aiutano l’AI, pur lasciando una certa flessibilità al team. Le sue convenzioni — Composition API, Pinia, Vue Router — sono abbastanza standard da dare all’AI un buon contesto. Ma c’è ancora una certa flessibilità, quindi a volte il codice generato non si allinea perfettamente al progetto.",[25,1785,1786],{},"In pratica: l'AI è più affidabile con Vue che con React, ma meno che con Angular.",[46,1788,1790],{"id":1789},"impatto-dellai-sulla-produttività-dipende-tutto-dal-framework","Impatto dell'AI sulla produttività: dipende tutto dal framework",[25,1792,1793],{},"Se il tuo team usa strumenti AI ogni giorno — e sta diventando rapidamente una pratica comune nei team — il framework che scegli cambia davvero quanto riesci a tirare fuori da queste tecnologie.",[25,1795,1796],{},"Con Angular, nella mia esperienza, il codice generato dall’AI richiede in genere meno adattamenti. Qualche ritocco, niente di più. Con Vue serve una revisione un po’ più attenta, mentre con React, spesso, solo uno sviluppatore esperto riesce a integrare davvero il contributo dell’AI senza dover riscrivere tutto.",[25,1798,1799],{},"Tradotto in termini di budget: lo stesso team ottiene ritorni diversi dall’AI, solo perché usa un framework invece che un altro. Non è l’unico aspetto, certo, ma chi deve pianificare dovrebbe tenerlo a mente.",[46,1801,1803],{"id":1802},"conta-di-più-il-team-del-framework","Conta di più il team del framework",[25,1805,1806],{},"Dopo tutto questo, c’è una verità che molti non vogliono sentire: il framework conta molto meno di quanto si pensi. Ho visto progetti React eccellenti e altri molto difficili da mantenere. La differenza, come sempre, la faceva il team e non la tecnologia. Angular può essere una roccia o un incubo da mantenere. La differenza non la fa la tecnologia. La fa il team.",[25,1808,1809,1810,276],{},"Un team che conosce davvero il proprio framework lavora meglio, fa meno errori, stima meglio tempi e costi, risolve i problemi senza andare nel panico. Un team che sceglie il framework \"alla moda\" ma lo conosce solo in superficie è una bomba a orologeria con la UI scintillante. E se non trovi sviluppatori che conoscono il framework che hai scelto, il problema potrebbe essere ",[40,1811,1812],{"href":992},"nella tua offerta, non nel mercato",[25,1814,1815],{},"La vera differenza la fa la competenza specifica, non la moda tecnologica. Sempre. E con l’AI questa cosa pesa il doppio: chi conosce il framework sa cosa chiedere all’AI, sa quando fidarsi di quello che propone e quando invece è meglio lasciar perdere. Chi va a tentoni prende tutto per buono e accumula debiti tecnici.",[46,1817,1819],{"id":1818},"come-scegliere-il-framework-frontend-nel-2026","Come scegliere il framework frontend nel 2026",[25,1821,1822],{},"Se devi decidere adesso, la prima regola è partire dal team che hai e non dal framework che sogni. Se i tuoi sviluppatori sanno usare Vue, resta su Vue. Se sanno React, vai di React. Cambiare framework costa quasi sempre molto più di quanto si immagini, tra formazione, cali di produttività e bug nuovi.",[25,1824,1825],{},"Se invece stai partendo da zero, guarda il tipo di prodotto. Per un’applicazione enterprise complicata e un team numeroso, Angular può aiutare a mettere ordine. Per un prodotto che deve cambiare spesso e un team piccolo, Vue è molto pratico. Se hai senior forti e un’interfaccia con esigenze fuori dal comune, React ti offre la flessibilità necessaria.",[25,1827,1828,1829,1832],{},"Va considerato anche il fattore AI. Se il team lavora ogni giorno con questi strumenti, la prevedibilità del framework cambia davvero quanto riesci a guadagnarci. Non è l’unico criterio, ma pesa. E soprattutto non ha senso riscrivere solo perché “adesso si usa altro”. Se il framework che hai fa il suo lavoro, ",[40,1830,1831],{"href":516},"riscrivere da zero costerà quasi certamente più del previsto",". Meglio investire tempo e soldi nel formare il team e migliorare il codice che già esiste.",[25,1834,1835],{},"Lo stesso vale per i framework minori. Se hai motivi tecnici forti per scegliere Svelte, Solid o simili, e il team li conosce davvero, la scelta può avere senso. Se invece nasce solo dall’entusiasmo del momento, rischi di spendere soldi inseguendo un capriccio.",[46,1837,1839],{"id":1838},"il-framework-è-solo-un-mezzo-il-team-è-ciò-che-conta","Il framework è solo un mezzo, il team è ciò che conta",[25,1841,1842],{},"Scegliere il framework JavaScript è uno dei temi più discussi nello sviluppo software — e paradossalmente, tra i meno decisivi. Ci si divide tra React, Vue, Angular come se fosse una religione, quando la vera differenza la fa una cosa molto più semplice: quanto bene il tuo team conosce e usa ciò che ha.",[25,1844,1845],{},"Investi nelle persone. Nella formazione. Nel tempo per lavorare meglio. Il framework è solo uno strumento, non il traguardo. Se qualcuno ti propone di riscrivere tutto con il framework “del momento”, chiediti: il problema è davvero lo strumento… o è come lo stiamo usando? Per esperienza, quasi sempre è la seconda.",[46,1847,1849],{"id":1848},"la-mia-esperienza","La mia esperienza",[25,1851,1852],{},"Dopo tutta questa carrellata, la mia esperienza personale è semplice. Uso Vue dal 2018 e per me resta un ottimo compromesso. Lo preferivo di più all’epoca delle Options API, rispetto alle Composition API che somigliano da vicino ad alcuni pattern introdotti in React, ma nel complesso continua a sembrarmi una soluzione molto equilibrata.",[25,1854,1855],{},"React l’ho usato per qualche mese in ambito professionale e l’ho trovato più faticoso da gestire rispetto a Vue e Angular, soprattutto per la libertà architetturale che lascia al team. Ci sono troppi modi diversi di fare le stesse cose e troppo dipende da come è stato impostato il progetto in cui entri.",[25,1857,1858],{},"Angular lo uso da pochi mesi, da quando ho capito che una parte importante del futuro del nostro lavoro passerà dalla collaborazione con l'AI. Dei tre è quello che conosco meno, ma mi piace molto proprio per il suo carattere strutturato: noioso, prolisso, ripetitivo, prevedibile. E questa prevedibilità, nel lavoro quotidiano, spesso aiuta più di quanto si voglia ammettere.",{"title":170,"searchDepth":171,"depth":171,"links":1860},[1861,1862,1867,1868,1873,1874,1875,1876,1877],{"id":1627,"depth":171,"text":1628},{"id":1643,"depth":171,"text":1644,"children":1863},[1864,1865,1866],{"id":1650,"depth":176,"text":1651},{"id":1675,"depth":176,"text":1676},{"id":1697,"depth":176,"text":1698},{"id":1720,"depth":171,"text":1721},{"id":1748,"depth":171,"text":1749,"children":1869},[1870,1871,1872],{"id":1759,"depth":176,"text":1760},{"id":1769,"depth":176,"text":1770},{"id":1779,"depth":176,"text":1780},{"id":1789,"depth":171,"text":1790},{"id":1802,"depth":171,"text":1803},{"id":1818,"depth":171,"text":1819},{"id":1838,"depth":171,"text":1839},{"id":1848,"depth":171,"text":1849},"2026-01-13","React, Vue, Angular (+ Svelte): come scegliere il framework JavaScript giusto. Costi reali, ruolo del team, ecosistema e impatto dell'AI sulla decisione.","/images/blog/quale-framework-javascript-scegliere.jpg",{},"/blog/2026-01-13-quale-framework-javascript-scegliere",{"title":1616,"description":1879},"React, Vue o Angular: quale framework JavaScript scegliere","quale-framework-javascript-scegliere","blog/2026-01-13-quale-framework-javascript-scegliere",[1888,1889,1890,1891,1106,1892,1446,6,909,1110],"javascript","react","vue","angular","typescript","nHGTseCMi85A2PHnjrvNimtvox5Rawqze-qhbGEXui0",{"id":1895,"title":1896,"body":1897,"category":7,"date":2066,"description":2067,"extension":194,"image":2068,"meta":2069,"navigation":3,"path":2070,"published":3,"seo":2071,"seoTitle":2072,"slug":2073,"stem":2074,"tags":2075,"updated":208,"__hash__":2080},"blog/blog/2026-01-01-sito-web-senza-server-nuxt-cloudflare.md","Sito web senza server: perché scegliere Nuxt e Cloudflare",{"type":22,"value":1898,"toc":2052},[1899,1906,1909,1913,1916,1919,1923,1926,1929,1933,1936,1940,1943,1946,1950,1953,1956,1960,1963,1966,1970,1985,1992,1999,2003,2006,2009,2012,2016,2019,2023,2026,2038,2042,2045],[25,1900,1901,1902,1905],{},"Un sito web senza server da gestire, che nella maggior parte dei casi non ha costi di hosting, è estremamente raro che vada offline e richiede pochissima manutenzione? Sembra la classica promessa da venditore troppo gasato, lo so. Eppure, è proprio così che funziona il sito che stai leggendo adesso. E no, non è un ",[40,1903,1904],{"href":710},"MVP tirato via in fretta",": è un approccio architetturale preciso.",[25,1907,1908],{},"In questo articolo ti spiego perché ho scelto Nuxt e Cloudflare, cosa ci guadagni davvero se scegli anche tu questa soluzione e perché, magari, non è la soluzione perfetta per tutti.",[46,1910,1912],{"id":1911},"il-problema-che-tutti-fanno-finta-di-non-vedere","Il problema che tutti fanno finta di non vedere",[25,1914,1915],{},"Diciamolo senza girarci intorno: la maggior parte dei siti web è costruita in modo troppo complicato. Un semplice sito vetrina da dieci pagine non ha bisogno di un server che gira giorno e notte, di un database MySQL, o di PHP che sforna codice a ogni visita. Eppure, WordPress funziona così. E WordPress, ricordiamolo, manda avanti il poco meno della metà dei siti web a livello mondiale.",[25,1917,1918],{},"Il risultato? Devi gestire server, aggiornare plugin, fare backup al database, installare patch di sicurezza ogni mese. E quando qualcosa si rompe (succede sempre), il sito ti lascia a piedi proprio quando il tuo futuro cliente più importante compila il tuo form di contatto. Se hai mai gestito un sito WordPress, conosci quella sensazione: il pulsante “Aggiorna” nella dashboard che sai che devi premere per evitare che il sito diventi vulnerabile, e tu che incroci le dita sperando che stavolta non si rompa tutto.",[46,1920,1922],{"id":1921},"come-funziona-questo-sito-spoiler-niente-server-dietro","Come funziona questo sito (spoiler: niente server dietro)",[25,1924,1925],{},"La pagina che stai leggendo è servita da una rete distribuita di server Cloudflare in tutto il mondo. Quando pubblico un articolo, Nuxt trasforma tutto in semplici file HTML statici. Questi file vengono serviti attraverso oltre 300 data center Cloudflare sparsi nel mondo. Quando entri sul sito, il file ti arriva dal data center più vicino a te. Niente calcoli, niente database, niente PHP che si sveglia dal letargo.",[25,1927,1928],{},"È un po’ come la differenza tra chiedere a qualcuno di farti un panino sul momento (il sito tradizionale) o prenderne uno già pronto dal bancone (il sito statico). Il secondo, in genere, è più veloce. E, nella pratica, non ha costi di hosting per la maggior parte dei casi.",[46,1930,1932],{"id":1931},"i-numeri-che-davvero-contano","I numeri che davvero contano",[25,1934,1935],{},"Basta chiacchiere, vediamo cosa cambia davvero.",[54,1937,1939],{"id":1938},"costo-hosting-zero-euro-al-mese","Costo hosting: zero euro al mese",[25,1941,1942],{},"Non è un errore. Cloudflare Pages offre un piano gratuito più che sufficiente per la maggior parte dei siti statici, con limiti molto alti difficili da raggiungere in casi normali. Il loro modello di business si basa su altri servizi: per questo possono offrire hosting statico gratuito con limiti molto ampi.",[25,1944,1945],{},"Per darti un’idea, un hosting WordPress condiviso costa in genere tra 5 e 15 euro al mese, un VPS decente tra 20 e 50 euro e un hosting gestito tra 50 e 150 euro. In tre anni il risparmio può facilmente arrivare a centinaia, in alcuni casi migliaia di euro. Non è poco, soprattutto per un sito che nel frattempo va anche meglio.",[54,1947,1949],{"id":1948},"tempo-di-caricamento-meno-di-un-secondo","Tempo di caricamento: meno di un secondo",[25,1951,1952],{},"Qui il Time to First Byte è tipicamente molto basso, nell’ordine di poche decine di millisecondi. Tanto per capirci: un battito di ciglia dura tra i 100 e i 150ms. La pagina inizia a caricarsi prima che tu finisca di sbattere le palpebre.",[25,1954,1955],{},"Google PageSpeed mi dà stabilmente punteggi sopra il 95. Buone performance aiutano a ottenere ottime Core Web Vitals, cioè gli indicatori con cui Google valuta velocità, stabilità visiva e reattività delle pagine. Gratis anche questo. Occhio però: il punteggio sopra 95 si ottiene anche grazie alle ottimizzazioni lato codice. Il server aiuta, ma se il sito fosse fatto male, né Nuxt né Cloudflare farebbero miracoli!",[54,1957,1959],{"id":1958},"livelli-di-disponibilità-tipici-delle-grandi-cdn-globali","Livelli di disponibilità tipici delle grandi CDN globali",[25,1961,1962],{},"Cloudflare ha oltre 300 data center nel mondo che possono servire i tuoi file, si riduce drasticamente il rischio di avere un singolo punto debole. Se un data center va in fiamme (succede, davvero, se non ci credi chiedi a chi aveva il server ospitato su OVH il 9 marzo 2021), le richieste vengono automaticamente servite da altri data center della rete.",[25,1964,1965],{},"La disponibilità è paragonabile a quella delle grandi infrastrutture CDN, cioè reti globali che distribuiscono i contenuti da tanti punti del mondo, molto difficili da ottenere con un singolo server. E in quell’ora, spesso il sito resta comunque visibile: le pagine sono già in cache dappertutto.",[46,1967,1969],{"id":1968},"la-sicurezza-di-chi-non-ha-niente-da-perdere","La sicurezza di chi non ha niente da perdere",[25,1971,1972,1973,1976,1977,1980,1981,276],{},"Qui inizia il bello. Un sito WordPress è un bersaglio facile in mille modi: ",[28,1974,1975],{},"SQL injection",", bug nel core, plugin pieni di buchi (ce ne sono migliaia), tentativi di ",[28,1978,1979],{},"brute force"," per entrare nel login. Ogni cosa installata è una porta che qualcuno può provare a sfondare. Se vuoi capire meglio come funzionano queste vulnerabilità, ne parlo in dettaglio nell'articolo su come ",[40,1982,1984],{"href":1983},"/blog/sicurezza-backend-produzione","il tuo backend può diventare una bomba ad orologeria",[25,1986,1987,1988,1991],{},"Il mio sito, invece, ",[28,1989,1990],{},"riduce drasticamente la superficie di attacco",". Non c’è un database da “bucare”. Nessun pannello admin a vista. Niente codice lato server da colpire. Restano ovviamente aspetti di sicurezza da curare (repository, DNS, pipeline di deploy), ma scompaiono i rischi tipici dei CMS dinamici sempre esposti. Cloudflare fornisce protezioni automatiche contro DDoS, gestione SSL e filtri firewall già integrati nell’infrastruttura.",[25,1993,1994,1995,1998],{},"Il modo più semplice per non farsi rubare qualcosa? Non averlo. Questa è ",[28,1996,1997],{},"sicurezza progettata",", non rattoppata.",[46,2000,2002],{"id":2001},"il-rovescio-della-medaglia","Il rovescio della medaglia",[25,2004,2005],{},"Non sarebbe corretto raccontarla tutta rosa e fiori. Il primo limite è che serve comunque qualcuno con competenze tecniche, anche se esistono CMS headless e interfacce che semplificano molto la gestione dei contenuti. Nuxt non è pensato per chi vuole trascinare blocchi o cliccare “installa”: serve qualcuno che sappia dove mettere le mani.",[25,2007,2008],{},"Il secondo limite riguarda il tipo di progetto. Se hai bisogno di login utenti, e-commerce con carrelli, commenti in tempo reale o logiche dinamiche complesse, l’architettura si complica e devi integrare servizi backend o edge functions. Nuxt può farlo benissimo, ma a quel punto non stai più parlando di un semplice sito statico.",[25,2010,2011],{},"Il terzo limite è operativo: ogni modifica richiede un deploy. Non correggi un errore dal telefono con la stessa immediatezza di WordPress. Devi aprire il file, cambiare, fare commit e aspettare che il sito si aggiorni. Per un blog personale si risolve in pochi minuti, ma resta un flusso meno immediato.",[46,2013,2015],{"id":2014},"per-chi-funziona-davvero","Per chi funziona davvero",[25,2017,2018],{},"Questa soluzione è particolarmente adatta ai siti aziendali che devono stare sempre online, ai portfolio professionali dove la velocità e la prima impressione contano davvero, ai blog e ai magazine che pubblicano contenuti senza bisogno di interazione in tempo reale e alle landing page che devono reggere picchi di traffico improvvisi. In generale funziona bene per i siti in cui il contenuto cambia poco, ma deve restare sempre accessibile, veloce e sicuro.",[46,2020,2022],{"id":2021},"facciamo-due-conti","Facciamo due conti",[25,2024,2025],{},"Un sito WordPress, con hosting affidabile, manutenzione e qualche plugin premium, può facilmente arrivare a diverse centinaia di euro l’anno tra hosting, aggiornamenti e due plugin premium.",[25,2027,2028,2029,2033,2034,2037],{},"Un sito Nuxt su Cloudflare costa di più all’inizio (diciamo il 20-30% in più), ma dopo l’hosting è gratis e la manutenzione si riduce molto e si concentra soprattutto sul codice e sugli ",[40,2030,2032],{"href":2031},"/blog/dipendenze-open-source-costo-nascosto","aggiornamenti delle dipendenze",". Il break-even, in molti casi, arriva nel giro del primo anno. Ma il vero vantaggio non è nei soldi: è ",[28,2035,2036],{},"dormire tranquilli"," sapendo che il sito non va giù alle tre di notte perché un plugin ha fatto i capricci.",[46,2039,2041],{"id":2040},"in-conclusione","In conclusione",[25,2043,2044],{},"WordPress non è il cattivo della storia. Per tanti progetti è perfetto. Ma per un sito vetrina, un portfolio, un blog aziendale? Probabilmente stai pagando (in soldi e in nervi) per cose che non ti servono.",[25,2046,2047,2048,2051],{},"La tecnologia è andata avanti. Oggi puoi avere un sito ",[28,2049,2050],{},"più veloce, più sicuro e più affidabile"," spesso anche spendendo meno. Basta scegliere lo strumento giusto.",{"title":170,"searchDepth":171,"depth":171,"links":2053},[2054,2055,2056,2061,2062,2063,2064,2065],{"id":1911,"depth":171,"text":1912},{"id":1921,"depth":171,"text":1922},{"id":1931,"depth":171,"text":1932,"children":2057},[2058,2059,2060],{"id":1938,"depth":176,"text":1939},{"id":1948,"depth":176,"text":1949},{"id":1958,"depth":176,"text":1959},{"id":1968,"depth":171,"text":1969},{"id":2001,"depth":171,"text":2002},{"id":2014,"depth":171,"text":2015},{"id":2021,"depth":171,"text":2022},{"id":2040,"depth":171,"text":2041},"2026-01-01","Sito web senza server con Nuxt e Cloudflare: costi contenuti, affidabilità, niente manutenzione. Quando conviene scegliere questo approccio e quando no.","/images/blog/sito-web-senza-server-nuxt-cloudflare.jpg",{},"/blog/2026-01-01-sito-web-senza-server-nuxt-cloudflare",{"title":1896,"description":2067},"Sito web senza server: vantaggi di Nuxt e Cloudflare","sito-web-senza-server-nuxt-cloudflare","blog/2026-01-01-sito-web-senza-server-nuxt-cloudflare",[2076,2077,2078,1609,2079],"nuxt","cloudflare","jamstack","sicurezza","Wkr2d12saKUxUHbAUeBczwLjVUkEsmt0hSxHVDRkuZU",1779395073442]