[{"data":1,"prerenderedAt":6641},["ShallowReactive",2],{"has-blog-posts":3,"all-posts":4,"blog-categories":6636},true,[5,231,379,498,665,834,1028,1136,1253,1418,1619,1799,1931,2061,2200,2357,2521,2649,2816,2995,3121,3240,3405,3603,3749,3884,4041,4168,4291,4416,4616,4759,4955,5133,5313,5498,5647,5813,6093,6240,6452],{"id":6,"title":7,"body":8,"category":210,"date":211,"description":212,"extension":213,"image":214,"meta":215,"navigation":3,"path":216,"published":3,"seo":217,"seoTitle":218,"slug":219,"stem":220,"tags":221,"updated":229,"__hash__":230},"blog/blog/2026-05-21-claude-code-vs-codex-quale-scegliere.md","Claude Code vs Codex: quale scegliere per programmare?",{"type":9,"value":10,"toc":198},"minimark",[11,20,23,26,29,34,37,43,46,49,53,56,59,62,65,68,71,75,78,81,84,87,90,93,97,104,107,110,113,116,120,123,126,129,138,142,145,148,151,154,158,161,164,167,170,173,177,180,183,186,189,192,195],[12,13,14,15,19],"p",{},"Se stai cercando un confronto tra Claude Code e Codex, probabilmente vuoi rispondere a una domanda molto pratica: ",[16,17,18],"strong",{},"quale usare per programmare davvero?"," Non in una demo, non su un benchmark sintetico, ma dentro un codebase reale, con vincoli reali, bug reali e poco tempo per sistemare quando qualcosa va storto.",[12,21,22],{},"Negli ultimi mesi uso sia Claude Code sia OpenAI Codex su progetti reali. Non per fare benchmark da laboratorio, ma perché quando stai lavorando su un codebase devi portare a casa una modifica: leggere codice esistente, capire vincoli, fare una scelta, implementarla, verificare che non abbia rotto altro.",[12,24,25],{},"In questi giorni mi sono capitati due episodi quasi speculari. Stesso tipo di lavoro: una task concreta, codebase reale, prompt dettagliato, interazioni successive per correggere la direzione. Da una parte Claude Code con Opus 4.7. Dall'altra Codex con GPT-5.5.",[12,27,28],{},"Il risultato è stato interessante proprio perché non ha prodotto una classifica semplice. In un caso Claude si è perso e Codex ha risolto in pochi minuti. Nell'altro Codex ha prodotto una soluzione brutta e fragile, mentre Claude ha consegnato codice pulito quasi subito.",[30,31,33],"h2",{"id":32},"claude-code-o-codex-risposta-breve","Claude Code o Codex: risposta breve",[12,35,36],{},"Se devo semplificare, oggi li vedo così: Claude Code è spesso più forte quando serve progettare o modificare una feature con molto contesto; Codex è molto forte come revisore, semplificatore e secondo parere tecnico quando una soluzione sta diventando troppo complicata.",[12,38,39,40],{},"Quindi la domanda \"meglio Claude Code o Codex?\" è posta male. La domanda utile è: ",[16,41,42],{},"per quale fase del lavoro?",[12,44,45],{},"Per scrivere una feature complessa, soprattutto se il progetto ha un flusso applicativo già strutturato, tendo a preferire Claude. Per revisionare codice, togliere complessità, individuare rischi e uscire da un vicolo cieco, Codex è spesso il compagno giusto.",[12,47,48],{},"Il punto non è scegliere una squadra. Il punto è sapere quando cambiare strumento.",[30,50,52],{"id":51},"claude-code-vs-codex-dove-claude-si-è-incartato","Claude Code vs Codex: dove Claude si è incartato",[12,54,55],{},"Il primo episodio riguardava una feature in Go e Angular: un workflow editor, cioè un'interfaccia per creare e modificare un flusso visuale simile a una macchina a stati finiti. Stati, transizioni, frecce, nodi editabili. Il tipo di interfaccia dove la parte difficile non è solo salvare i dati, ma rendere leggibile il diagramma mentre l'utente lo modifica.",[12,57,58],{},"Claude ha capito il problema generale. Ha iniziato a progettare la feature, ha scritto codice, ha iterato sulle modifiche. Il problema è emerso sulle frecce: più cercava di sistemarle, più il disegno diventava confuso. Linee sovrapposte, incroci poco controllati, layout difficile da seguire. Il risultato era il classico \"piatto di spaghetti\": formalmente c'erano tutti i collegamenti, ma visivamente il diagramma era inutilizzabile.",[12,60,61],{},"Dopo quasi due ore di prompt e interazioni, la situazione era peggiorata. Claude continuava a lavorare sullo stesso punto, ma ogni tentativo aggiungeva complessità senza risolvere il problema di fondo. A un certo punto ha iniziato a proporre librerie aggiuntive, astrazioni nuove, logica extra per gestire casi che in realtà erano sintomi della soluzione sbagliata. Il progetto diventava più pesante, ma il diagramma non diventava più leggibile.",[12,63,64],{},"Questo è uno dei failure mode più pericolosi degli assistenti AI: non falliscono sempre fermandosi. A volte falliscono continuando a lavorare. Producono codice, spiegano cosa stanno facendo, sembrano avere una strategia, ma in realtà stanno scavando più in profondità dentro una direzione sbagliata.",[12,66,67],{},"Alla fine ho passato il problema a Codex. Non gli ho chiesto di aggiungere un'altra pezza, ma di guardare il problema e risolverlo. In circa dieci minuti ha fatto la cosa che serviva: ha tolto dipendenze, ha semplificato il codice, ha riscritto un paio di metodi chiave e ha riportato il progetto alla forma desiderata.",[12,69,70],{},"La cosa importante non è che Codex abbia \"vinto\" quel task. La cosa importante è che ha riconosciuto una complessità inutile e l'ha tagliata. In quel momento serviva meno codice, non più codice. E Claude, dentro quel loop, non ci stava arrivando.",[30,72,74],{"id":73},"quando-codex-sbaglia-architettura-e-claude-risolve","Quando Codex sbaglia architettura e Claude risolve",[12,76,77],{},"Pochi giorni dopo è successo l'inverso.",[12,79,80],{},"Avevo quasi esaurito il piano Claude Max e ho deciso di affidare a Codex una task su un progetto Laravel e Vue. Anche qui niente esperimento astratto: una modifica reale dentro un flusso applicativo già esistente. Prompt chiaro, contesto sufficiente, obiettivo verificabile.",[12,82,83],{},"Dopo circa venticinque minuti e tre iterazioni, il risultato era tecnicamente inaccettabile. Non perché mancasse completamente l'idea, ma perché l'implementazione era una somma di scorciatoie: override di un flusso già previsto dal programma, condizioni speciali infilate nei punti sbagliati, hack per forzare il comportamento invece di integrarsi con il modello esistente. E, cosa ancora più importante, il codice non funzionava bene: c'erano bug logici e problemi infrastrutturali.",[12,85,86],{},"Probabilmente quel codice si sarebbe potuto sistemare a mano. Ma a quel punto la domanda interessante era un'altra: cosa sarebbe successo dando lo stesso task a Claude?",[12,88,89],{},"Ho revertito tutte le modifiche e ho passato a Claude Code lo stesso prompt, copiato e incollato. In sette minuti e due interazioni mi ha consegnato una soluzione funzionante. L'ho revisionata a mano, riga per riga. Il codice era pulito, coerente con il progetto, inserito nel flusso corretto. Non era solo \"funziona\": era una soluzione che avrei fatto fatica a scrivere meglio.",[12,91,92],{},"Qui il risultato è stato opposto al primo episodio. Dove Codex aveva cercato una strada laterale, Claude ha capito l'architettura del flusso e ci si è infilato dentro nel modo giusto.",[30,94,96],{"id":95},"quale-ai-per-programmare-dipende-da-come-sbaglia","Quale AI per programmare? Dipende da come sbaglia",[12,98,99,100,103],{},"Questi due episodi raccontano una cosa che nei discorsi sull'AI nello sviluppo software viene spesso semplificata troppo: non basta chiedersi quale modello \"scrive codice meglio\". Bisogna chiedersi ",[16,101,102],{},"come sbaglia",".",[12,105,106],{},"Claude, nella mia esperienza, tende a essere molto forte quando deve costruire un modello mentale del sistema. Legge bene l'intenzione, ragiona sui confini, propone soluzioni ordinate, spesso mantiene una coerenza architetturale migliore. Come sviluppatore e come architetto, quando prende la direzione giusta, è impressionante.",[12,108,109],{},"Il suo problema è che quando entra in un loop sbagliato può diventare difficile da fermare. Continua a raffinare la stessa direzione, aggiunge dettagli, moltiplica la struttura, propone dipendenze. Se non lo guidi con decisione, o se non hai voglia di intervenire a mano, rischi di ritrovarti con un sistema più complicato e ancora rotto.",[12,111,112],{},"Codex, invece, mi convince moltissimo come revisore. È molto bravo a guardare codice esistente, individuare punti fragili, togliere rumore, ridurre complessità. Nel primo episodio ha fatto esattamente questo: ha guardato una soluzione che stava collassando sotto il suo peso e l'ha resa semplice.",[12,114,115],{},"Come developer è assolutamente utilizzabile. Ma come architetto, almeno nei casi che ho visto, mi convince meno. Soprattutto quando il task richiede di rispettare un flusso applicativo già progettato e di inserirsi nel punto giusto, può cercare scorciatoie locali: codice che sembra risolvere il caso immediato, ma aggira il disegno del sistema. E quando succede, il costo arriva dopo, in manutenzione.",[30,117,119],{"id":118},"code-review-con-ai-la-revisione-manuale-resta-obbligatoria","Code review con AI: la revisione manuale resta obbligatoria",[12,121,122],{},"La prima lezione è banale, ma va detta perché è l'unica che conta davvero: il codice generato va sempre revisionato. Sempre.",[12,124,125],{},"Non importa se arriva da Claude, da Codex, da Cursor o dal modello migliore del momento. Non importa se ha passato i test. Non importa se la diff sembra piccola. Un assistente AI può produrre codice elegante e sbagliato, codice brutto e funzionante, codice pulito ma incoerente con il dominio, codice che risolve il task e danneggia l'architettura.",[12,127,128],{},"La review non serve solo a trovare bug. Serve a rispondere a domande più importanti: questa modifica rispetta il modello del progetto? Sta introducendo una dipendenza inutile? Sta mettendo logica nel posto giusto? Sta risolvendo il problema o sta nascondendo un sintomo? Tra sei mesi qualcuno capirà perché è stata fatta così?",[12,130,131,132,137],{},"È lo stesso punto che torna quando si parla di ",[133,134,136],"a",{"href":135},"/blog/sviluppare-con-ai","sviluppare con l'AI",": questi strumenti accelerano il lavoro, ma non eliminano il giudizio. Anzi, lo rendono più importante, perché producono materiale tecnico molto più velocemente di quanto un team medio riesca a valutarlo con attenzione.",[30,139,141],{"id":140},"quando-usare-claude-code-e-quando-usare-codex","Quando usare Claude Code e quando usare Codex",[12,143,144],{},"La seconda lezione è più pratica: non bisogna affezionarsi allo strumento. Claude non è \"il migliore\" in assoluto. Codex non è \"il migliore\" in assoluto. Sono strumenti diversi, con punti forti diversi e modi diversi di fallire.",[12,146,147],{},"Se Claude entra in un loop di complessità, può essere molto più efficiente fermarlo, salvare il contesto e chiedere a Codex una revisione radicale. Non per continuare ad aggiungere codice, ma per togliere quello che non serve.",[12,149,150],{},"Se Codex propone una soluzione che aggira il flusso del progetto, può avere senso fermarsi subito e passare il task a Claude, soprattutto quando serve una lettura più architetturale del sistema.",[12,152,153],{},"Questa è una competenza nuova ma concreta: saper capire quando un assistente sta ancora aiutando e quando sta solo producendo rumore. Prima lo capisci, meno tempo perdi. Il costo non è solo il tempo del modello: è il tempo che passerai tu a ripulire, debuggare, spiegare e magari revertire.",[30,155,157],{"id":156},"confronto-claude-code-vs-codex-cosa-mi-porto-a-casa","Confronto Claude Code vs Codex: cosa mi porto a casa",[12,159,160],{},"Da questi due episodi mi porto a casa tre cose.",[12,162,163],{},"La prima è che la review umana non è un rito finale, ma parte centrale del lavoro. Senza review, l'AI aumenta la velocità con cui entra codice nel progetto, ma non necessariamente la qualità del sistema.",[12,165,166],{},"La seconda è che Claude, quando non si perde, oggi mi sembra più forte sia come architetto sia come sviluppatore. Soprattutto su task dove bisogna capire il flusso applicativo e inserirsi nel disegno esistente. Però ha un failure mode molto riconoscibile: quando entra in un vicolo cieco, può continuare a produrre complessità invece di fermarsi e cambiare strada.",[12,168,169],{},"La terza è che Codex è un revisore eccellente e un buon sviluppatore, ma lo uso con più cautela quando la task richiede una decisione architetturale. Mi fido molto della sua capacità di criticare codice, semplificare, trovare problemi. Mi fido meno della sua tendenza a progettare il flusso giusto da zero o a rispettare un disegno implicito se il progetto non glielo rende evidente.",[12,171,172],{},"Naturalmente sono osservazioni empiriche, non una legge fisica. Versioni diverse dei modelli, prompt diversi, codebase diverse e stack diversi possono cambiare molto. Ma proprio per questo gli episodi reali sono utili: mostrano i punti in cui la teoria si sporca con il lavoro quotidiano.",[30,174,176],{"id":175},"entrambi-servono-ma-per-lavori-diversi","Entrambi servono, ma per lavori diversi",[12,178,179],{},"Il punto non è tifare Claude o Codex. Il punto è costruire un modo di lavorare che sfrutti entrambi senza delegare loro il giudizio.",[12,181,182],{},"Io oggi li uso così: Claude quando serve costruire o modificare una feature con forte componente di contesto; Codex quando serve revisionare, semplificare, smontare una soluzione che non mi convince. Se uno dei due inizia a girare a vuoto, non insisto per principio. Revert, cambio strumento, confronto le soluzioni, poi decido io cosa tenere.",[12,184,185],{},"In questo senso, Codex per me ha un valore molto pragmatico anche quando non è lo strumento principale di sviluppo: è il revisore che entra quando qualcosa non torna, l'assistente da chiamare nei momenti bui, il secondo paio di occhi quando il modello che stai usando ha iniziato a complicare invece di chiarire.",[12,187,188],{},"Se lavori seriamente con questi strumenti, mettere a budget circa 23 euro in più al mese per avere Codex disponibile non è una spesa difficile da giustificare. Non perché sostituisca Claude, e non perché sia sempre migliore. Perché copre un bisogno diverso: revisione, contrasto, semplificazione, recupero quando l'altro assistente si è incastrato.",[12,190,191],{},"È meno romantico del \"l'AI scrive tutto da sola\", ma è molto più vicino al lavoro reale.",[12,193,194],{},"Entrambi sono validi. In certi flussi, entrambi sono necessari. Ma nessuno dei due firma la pull request al posto tuo.",[12,196,197],{},"La responsabilità del codice resta sempre del developer: del codice che scrive, del codice che accetta, del codice che lascia entrare in produzione. L'AI può scrivere codice molto buono. Può anche scrivere codice pessimo con grande sicurezza. La differenza la fa ancora chi guarda la diff e decide se quel codice merita di entrare nel progetto.",{"title":199,"searchDepth":200,"depth":200,"links":201},"",2,[202,203,204,205,206,207,208,209],{"id":32,"depth":200,"text":33},{"id":51,"depth":200,"text":52},{"id":73,"depth":200,"text":74},{"id":95,"depth":200,"text":96},{"id":118,"depth":200,"text":119},{"id":140,"depth":200,"text":141},{"id":156,"depth":200,"text":157},{"id":175,"depth":200,"text":176},"Sviluppo","2026-05-21","Confronto reale tra Claude Code e Codex su due task: sviluppo, architettura e code review. Quando usare Claude, quando Codex, e perché la review resta umana.","md","/images/blog/claude-code-vs-codex-quale-scegliere.jpg",{},"/blog/2026-05-21-claude-code-vs-codex-quale-scegliere",{"title":7,"description":212},"Claude Code vs Codex: quale scegliere per programmare","claude-code-vs-codex-quale-scegliere","blog/2026-05-21-claude-code-vs-codex-quale-scegliere",[222,223,224,225,226,227,228],"ai","claude-code","codex","code-review","architettura","sviluppo-software","debito-tecnico",null,"9MPbXq1rsg88KQZQQuihnv9qvjedWAKx7vH824UYkqw",{"id":232,"title":233,"body":234,"category":210,"date":363,"description":364,"extension":213,"image":365,"meta":366,"navigation":3,"path":367,"published":3,"seo":368,"seoTitle":369,"slug":370,"stem":371,"tags":372,"updated":229,"__hash__":378},"blog/blog/2026-05-19-segnali-progetto-software-fallira.md","Segnali che un progetto software fallirà prima di iniziare",{"type":9,"value":235,"toc":353},[236,239,242,246,249,252,256,259,262,265,268,272,279,282,286,289,292,296,304,307,311,314,318,321,329,333,336,346],[12,237,238],{},"La maggior parte dei progetti software che finiscono male non lo fanno all'improvviso. I segnali c'erano già all'inizio, solo che nessuno li ha presi sul serio: all'inizio c'è entusiasmo, c'è voglia di partire, c'è la sensazione che \"poi sistemiamo strada facendo\". E invece quello che non sistemi all'inizio diventa strutturale.",[12,240,241],{},"Dopo un po', se lavori su questi progetti, inizi a riconoscerli subito. Si vede da come parte la conversazione, prima ancora di guardare il codice.",[30,243,245],{"id":244},"quando-il-problema-non-è-chiaro","Quando il problema non è chiaro",[12,247,248],{},"Il primo segnale è semplice: manca chiarezza su cosa si stia cercando di risolvere, in modo concreto, non astratto. \"Voglio automatizzare questo processo\" è un'intenzione, non ancora una definizione. Tra le due cose c'è un abisso fatto di dettagli, eccezioni, vincoli.",[12,250,251],{},"Se il problema non è definito, ogni soluzione sarà interpretata. E ogni interpretazione diversa diventa un potenziale conflitto.",[30,253,255],{"id":254},"quando-tutto-sembra-semplice","Quando tutto sembra semplice",[12,257,258],{},"Ci sono richieste che, raccontate a parole, sembrano banali.",[12,260,261],{},"\"Basta prendere questi dati e tirar fuori queste informazioni.\"",[12,263,264],{},"Poi guardi meglio e scopri che i dati non sono strutturati, che le regole cambiano caso per caso, che quello che sembra una regola è in realtà un'eccezione ricorrente.",[12,266,267],{},"Il vero ostacolo è la stabilità: senza una definizione abbastanza precisa, il sistema non può essere stabile, indipendentemente dalla difficoltà tecnica. E un sistema instabile genera aspettative instabili.",[30,269,271],{"id":270},"quando-una-demo-diventa-una-promessa","Quando una demo diventa una promessa",[12,273,274,275,103],{},"Un prototipo serve a validare una cosa: che una direzione è percorribile. Non serve a garantire che tutto funzionerà sempre, in ogni condizione, con qualsiasi input. È la stessa confusione che porta a ",[133,276,278],{"href":277},"/blog/cos-e-un-mvp-software","trattare l'MVP come un prodotto mal fatto",[12,280,281],{},"Se una demo viene letta come una promessa implicita — \"se qui funziona, funzionerà sempre\" — il progetto è già fuori asse. La realtà coincide con l'insieme di tutti i casi che ancora non hai visto, ben oltre il caso demo.",[30,283,285],{"id":284},"quando-i-limiti-non-vengono-accettati","Quando i limiti non vengono accettati",[12,287,288],{},"Ogni tecnologia ha limiti: alcuni tecnici, altri economici, altri semplicemente legati alla natura del problema. Se questi limiti vengono discussi, è normale; se vengono ignorati o trattati come dettagli secondari, no.",[12,290,291],{},"Un progetto funziona quando entrambe le parti accettano che esistono vincoli e lavorano dentro quei vincoli. Quando una delle due parti parte dal presupposto che i vincoli siano negoziabili, il progetto diventa una trattativa continua. E le trattative continue non producono buon software.",[30,293,295],{"id":294},"quando-il-costo-non-torna","Quando il costo \"non torna\"",[12,297,298,299,303],{},"Un altro segnale è la reazione ai costi. Il fatto che sembrino alti è normale: il software, visto da fuori, sembra sempre più semplice di quello che è — un tema su cui ho già scritto in ",[133,300,302],{"href":301},"/blog/stime-sviluppo-sbagliate-perche","perché le stime di sviluppo sembrano sempre sbagliate",". Il segnale arriva quando il costo viene percepito come \"sbagliato\" invece che come informazione nuova.",[12,305,306],{},"In quel momento la discussione, sotto i numeri, riguarda due realtà diverse di cosa sia il software. E se la realtà non è condivisa, il progetto non ha base su cui stare.",[30,308,310],{"id":309},"un-disallineamento-di-partenza","Un disallineamento di partenza",[12,312,313],{},"Questi segnali descrivono condizioni di partenza in cui il progetto non può funzionare, più che un \"cliente difficile\". È una distinzione importante: il giudizio sulle persone è secondario, quello che conta è capire quando il sistema che si sta creando non reggerà. E quando non regge, non c'è codice che tenga.",[30,315,317],{"id":316},"fermarsi-prima-costa-meno","Fermarsi prima costa meno",[12,319,320],{},"Il momento più economico per fermare un progetto è prima di iniziarlo. Dopo hai tempo investito, aspettative create, posizioni irrigidite, decisioni prese che diventano difficili da ritrattare. A quel punto, anche quando è evidente che qualcosa non funziona, si continua lo stesso. Perché fermarsi sembra una perdita.",[12,322,323,324,328],{},"E invece la perdita è andare avanti. È lo stesso meccanismo che porta tante ",[133,325,327],{"href":326},"/blog/agenzia-abbandona-progetto-software","agenzie a mollare a metà progetto",": il punto di rottura era già visibile mesi prima.",[30,330,332],{"id":331},"riconoscere-i-segnali-per-quello-che-sono","Riconoscere i segnali per quello che sono",[12,334,335],{},"Chi ha esperienza li riconosce quasi subito. Per esperienza accumulata, più che per bravura: li ha già visti. Il problema è che spesso vengono ignorati, minimizzati, razionalizzati.",[12,337,338,339,342,343,345],{},"\"Poi si sistema.\"",[340,341],"br",{},"\n\"Partiamo e vediamo.\"",[340,344],{},"\n\"Non sarà così complicato.\"",[12,347,348,349,103],{},"A volte va bene. Molto più spesso no. E quando no, la cosa più frustrante è che si poteva vedere prima: i segnali c'erano già. Bastava prenderli sul serio — e accettare che ",[133,350,352],{"href":351},"/blog/quando-dire-no-a-un-progetto-software","non tutti i progetti vanno iniziati",{"title":199,"searchDepth":200,"depth":200,"links":354},[355,356,357,358,359,360,361,362],{"id":244,"depth":200,"text":245},{"id":254,"depth":200,"text":255},{"id":270,"depth":200,"text":271},{"id":284,"depth":200,"text":285},{"id":294,"depth":200,"text":295},{"id":309,"depth":200,"text":310},{"id":316,"depth":200,"text":317},{"id":331,"depth":200,"text":332},"2026-05-19","Molti progetti software falliscono per segnali chiari fin dal primo incontro. Quali sono, come riconoscerli, perché quasi nessuno li prende sul serio.","/images/blog/segnali-progetto-software-fallira.jpg",{},"/blog/2026-05-19-segnali-progetto-software-fallira",{"title":233,"description":364},"Progetti software: come riconoscere i segnali di fallimento","segnali-progetto-software-fallira","blog/2026-05-19-segnali-progetto-software-fallira",[373,374,375,376,377],"segnali-fallimento","rischi-progetto","scelta-fornitore","valutazione-progetto","prevenzione","P2WIvcLcSRjXpL5G59BjMdFrp4DeVEnSAiP5ZYw2vmE",{"id":380,"title":381,"body":382,"category":210,"date":484,"description":485,"extension":213,"image":486,"meta":487,"navigation":3,"path":488,"published":3,"seo":489,"seoTitle":490,"slug":491,"stem":492,"tags":493,"updated":229,"__hash__":497},"blog/blog/2026-05-14-quando-dire-no-a-un-progetto-software.md","Quando dire no a un progetto software (e perché conviene a tutti)",{"type":9,"value":383,"toc":476},[384,390,393,397,400,403,407,410,413,420,424,427,430,437,441,444,452,456,459,462,466,473],[12,385,386,387,103],{},"C'è un equivoco che torna sempre, soprattutto quando si parla di sviluppo software: ",[16,388,389],{},"se una cosa si può fare, allora si deve fare",[12,391,392],{},"La realtà è un'altra. Un progetto può essere tecnicamente fattibile — magari anche relativamente semplice — e allo stesso tempo essere una pessima idea da iniziare: la tecnologia lo permette, il contesto intorno lo rende ingestibile. Ed è qui che si vede la differenza tra chi sviluppa e chi fa consulenza.",[30,394,396],{"id":395},"fattibile-non-significa-sostenibile","Fattibile non significa sostenibile",[12,398,399],{},"Costruire una demo è spesso facile. In poche ore puoi dimostrare che una certa cosa \"funziona\": estrai un dato, automatizzi un passaggio, fai vedere un risultato. Il problema è che quella demo viene quasi sempre interpretata come una promessa.",[12,401,402],{},"Una soluzione che gira una volta può non reggere alla seconda. Su un caso controllato può funzionare; davanti alla variabilità del mondo reale può crollare. Funzionare oggi non garantisce di essere mantenibile tra sei mesi, quando i casi limite iniziano a emergere. La distanza tra \"si può fare\" e \"funziona davvero in produzione\" è esattamente il posto dove nascono i problemi, e quella distanza è fatta soprattutto di aspettative.",[30,404,406],{"id":405},"lallineamento-conta-più-del-codice","L'allineamento conta più del codice",[12,408,409],{},"I progetti software non saltano perché il codice è difficile. Saltano perché chi lo commissiona e chi lo costruisce stanno risolvendo due problemi diversi senza accorgersene.",[12,411,412],{},"Succede quando il problema non è definito con chiarezza, quando i limiti tecnici vengono trattati come ostacoli negoziabili, quando il budget è scollegato dalla complessità reale, quando una prova diventa — nella percezione del cliente — una garanzia.",[12,414,415,416,103],{},"In queste condizioni, il progetto parte già disallineato, e più vai avanti, più l'allineamento peggiora. All'inizio sono piccole incomprensioni, poi diventano discussioni, poi diventano \"ma tu avevi detto che…\". E a quel punto il problema diventa relazionale, prima ancora che tecnico. È la stessa dinamica che porta a ",[133,417,419],{"href":418},"/blog/scope-creep-progetti-agile","scope creep continuo travestito da agilità",[30,421,423],{"id":422},"il-vero-lavoro-di-un-consulente","Il vero lavoro di un consulente",[12,425,426],{},"Chi è all'inizio della carriera tende a dire sì. È normale: vuoi lavorare, vuoi dimostrare che sei capace, vuoi portare a casa il progetto. Con il tempo, inizi a vedere pattern che si ripetono.",[12,428,429],{},"Non guardi più solo cosa ti stanno chiedendo di costruire. Guardi quanto è chiaro il problema, quanto sono realistiche le aspettative, quanto è disposto il cliente ad accettare vincoli e compromessi, quanto è probabile che a metà progetto il perimetro cambi.",[12,431,432,433,436],{},"E a un certo punto capisci che il tuo lavoro non si esaurisce nel costruire software: comprende anche ",[16,434,435],{},"decidere se vale la pena iniziare a costruirlo",". Dire sì a un progetto con presupposti sbagliati sposta il problema più avanti nel tempo, quando sarà più costoso per tutti — chiamarla flessibilità è un'illusione consolatoria.",[30,438,440],{"id":439},"il-costo-dei-progetti-sbagliati","Il costo dei progetti sbagliati",[12,442,443],{},"Accettare un progetto che nasce male ha sempre lo stesso finale. All'inizio sembra tutto normale. Poi arrivano le prime frizioni, il perimetro si allarga, le aspettative cambiano, il tempo non basta più. A quel punto qualcuno perde: a volte il cliente, che si ritrova con qualcosa che non corrisponde a quello che aveva in testa; a volte il fornitore, che lavora più del previsto per rimanere dentro a una promessa fatta troppo presto; spesso entrambi.",[12,445,446,447,451],{},"E nel mezzo c'è la cosa più costosa: tempo buttato. Tempo che non torna indietro, né per chi paga né per chi lavora. È lo stesso meccanismo per cui ",[133,448,450],{"href":449},"/blog/preventivo-software-partire-dal-budget","partire da una conversazione sul budget invece che da un preventivo"," salva entrambe le parti dal disastro.",[30,453,455],{"id":454},"il-no-come-atto-professionale","Il no come atto professionale",[12,457,458],{},"Dire no a un progetto, in molti casi, equivale a riconoscere un rischio prima che sia tardi — più che a rifiutare un'opportunità. È dire: in queste condizioni, con queste aspettative e questo livello di chiarezza, la probabilità che questo progetto finisca male è troppo alta. Più che una questione di volontà, è una questione di responsabilità.",[12,460,461],{},"Chi dice sì a tutto sembra più disponibile: spesso è solo meno esperto, o meno attento alle conseguenze. Chi si ferma prima evita di creare un problema che poi qualcuno dovrà risolvere.",[30,463,465],{"id":464},"il-segnale-da-leggere","Il segnale da leggere",[12,467,468,469,103],{},"Se un professionista ti dice di no, la lettura più semplice è che \"non ha voglia\" o \"non ha capito il progetto\". A volte è vero. Più spesso, però, sta vedendo qualcosa che tu, da dentro, non riesci ancora a vedere: un disallineamento che crescerà, una complessità nascosta, una combinazione di fattori che rende il progetto fragile prima ancora di iniziare. Per riconoscerli prima ho dedicato un articolo specifico ai ",[133,470,472],{"href":471},"/blog/segnali-progetto-software-fallira","segnali che un progetto software finirà male",[12,474,475],{},"Non tutti i progetti vanno iniziati. E una delle competenze più sottovalutate, in questo mestiere, è saperlo riconoscere prima.",{"title":199,"searchDepth":200,"depth":200,"links":477},[478,479,480,481,482,483],{"id":395,"depth":200,"text":396},{"id":405,"depth":200,"text":406},{"id":422,"depth":200,"text":423},{"id":439,"depth":200,"text":440},{"id":454,"depth":200,"text":455},{"id":464,"depth":200,"text":465},"2026-05-14","Un progetto può essere tecnicamente fattibile e comunque una pessima idea. Perché dire no al momento giusto conviene sia al cliente che al fornitore.","/images/blog/quando-dire-no-a-un-progetto-software.jpg",{},"/blog/2026-05-14-quando-dire-no-a-un-progetto-software",{"title":381,"description":485},"Quando dire no a un progetto software: i segnali da leggere","quando-dire-no-a-un-progetto-software","blog/2026-05-14-quando-dire-no-a-un-progetto-software",[376,494,495,375,496],"consulenza-tecnica","segnali-rischio","responsabilita","SfB_bs4o-G7b9tTMLR6IrDBtIDTPLdfh9UlIeWXVKDQ",{"id":499,"title":500,"body":501,"category":210,"date":647,"description":648,"extension":213,"image":649,"meta":650,"navigation":3,"path":651,"published":3,"seo":652,"seoTitle":653,"slug":654,"stem":655,"tags":656,"updated":229,"__hash__":664},"blog/blog/2026-05-12-successione-tecnica-conoscenza-tacita.md","Successione tecnica: cosa si può davvero trasferire a chi viene dopo",{"type":9,"value":502,"toc":637},[503,506,511,514,517,521,524,527,531,534,537,541,544,551,555,558,561,564,568,576,579,583,591,599,603,606,609,613,616,619,622,625,628,631,634],[12,504,505],{},"C’è una domanda che chi guida tecnicamente un team, prima o poi, si fa davvero.",[12,507,508],{},[16,509,510],{},"Se domani me ne vado, cosa resta?",[12,512,513],{},"Resta il codice, certo. Restano i processi, se li hai costruiti bene. Resta la documentazione, se non l’hai trattata come un favore da fare “quando c’è tempo”. Ma c’è una parte del tuo contributo che non resta: non resta il tuo gusto tecnico, non resta il tuo modo specifico di capire al volo che una strada è sbagliata e un’altra ha più possibilità di reggere, non resta quella combinazione di esperienza, intuito, errori fatti negli anni e sensibilità costruita caso dopo caso.",[12,515,516],{},"E non resta non perché hai delegato male. Non resta perché quella parte, semplicemente, non si trasferisce del tutto.",[30,518,520],{"id":519},"il-problema-non-è-la-documentazione","Il problema non è la documentazione",[12,522,523],{},"Quando ci si accorge di questa cosa, il primo istinto è sempre lo stesso: documentare di più, spiegare meglio, affiancare più a lungo, provare a trasformare il proprio giudizio in un insieme di regole. È un istinto sano, ma ha un limite.",[12,525,526],{},"Puoi trasferire il contesto di una decisione, i vincoli del sistema con cui hai lavorato, le alternative che hai scartato, i criteri con cui hai valutato un trade-off. Non puoi trasferire completamente il tuo modo di sentire che una soluzione “puzza” prima ancora di riuscire a spiegare bene perché. Quella parte nasce da anni di casi concreti compressi in pattern mentali. Funziona proprio perché è più veloce del ragionamento esplicito. E se è più veloce del ragionamento esplicito, per definizione non la formalizzerai mai tutta.",[30,528,530],{"id":529},"lerrore-è-voler-lasciare-una-copia-di-sé","L’errore è voler lasciare una copia di sé",[12,532,533],{},"Qui c’è un passaggio importante. Molte persone tecnicamente forti, quando iniziano a ragionare sulla successione, fanno lo stesso errore: cercano di lasciare dietro di sé una versione ridotta di se stesse. Vogliono formare qualcuno che prenda le stesse decisioni, che faccia le stesse review, che abbia gli stessi criteri, che continui il progetto “come l’avrebbero fatto loro”.",[12,535,536],{},"È una tentazione comprensibile. Ma è una strada sbagliata, perché se vuoi lasciare una copia di te stai ancora ragionando come se il sistema dovesse dipendere dalla tua persona, solo in forma differita. Un successore non è un avatar, e un team sano non ha bisogno di pensare come te: ha bisogno di poter funzionare bene senza di te.",[30,538,540],{"id":539},"quello-che-puoi-lasciare-davvero","Quello che puoi lasciare davvero",[12,542,543],{},"Questa è la distinzione che conta. Non puoi lasciare il tuo giudizio identico al tuo; puoi lasciare le condizioni in cui un altro giudizio ragionevole può emergere.",[12,545,546,547,550],{},"Puoi lasciare contesto chiaro e decisioni tracciate, standard condivisi e processi di review sensati, una cultura tecnica sana, un team capace di discutere senza dipendere da una sola voce. Questo sì che resta, e fa una differenza enorme. Perché chi viene dopo non prenderà le tue stesse decisioni: alcune saranno peggiori, alcune migliori, quasi tutte semplicemente diverse. Ma se il sistema è sano, saranno decisioni ",[16,548,549],{},"ragionevoli",". Ed è questo il punto: non perpetuare il tuo gusto, ma costruire un contesto in cui non serva.",[30,552,554],{"id":553},"come-capisci-se-hai-lasciato-un-sistema-o-solo-dipendenza","Come capisci se hai lasciato un sistema o solo dipendenza",[12,556,557],{},"C’è un test molto semplice. Entra una persona senior nuova nel team. Non formata da te, non cresciuta dentro il tuo progetto. Una persona forte, ma esterna. Cosa trova?",[12,559,560],{},"Se trova documentazione viva, decisioni architetturali tracciate, un team che sa spiegare il perché delle cose, un modo di lavorare leggibile, un repository che racconta qualcosa oltre al codice, allora hai lasciato un sistema.",[12,562,563],{},"Se invece trova codice che si capisce solo “parlandone con te”, motivi delle scelte noti soltanto a voce, parti del sistema che nessuno tocca senza chiederti, una cultura del “chiedi a tizio che sa”, allora non hai lasciato un sistema: hai lasciato un’estensione di te stesso. Ed è una differenza enorme.",[30,565,567],{"id":566},"il-bus-factor-qui-non-basta","Il bus factor qui non basta",[12,569,570,571,575],{},"Il ",[133,572,574],{"href":573},"/blog/bus-factor-developer-indispensabile","bus factor"," resta una metrica fondamentale. Ma qui non basta dire “abbiamo costruito un secondo” o “abbiamo distribuito la conoscenza”, perché puoi anche alzare il bus factor operativo e avere comunque una dipendenza forte sul piano del giudizio.",[12,577,578],{},"Magari il team sa fare deploy, sa gestire un bug in produzione, sa portare avanti il lavoro. Bene. Ma quando c’è una decisione veramente delicata — cambiare struttura, riscrivere un modulo, dire no a una feature, scegliere un compromesso — chi decide davvero? Se la risposta è ancora “sempre la stessa persona”, il problema è meno visibile, ma c’è ancora.",[30,580,582],{"id":581},"la-documentazione-serve-ma-non-fa-miracoli","La documentazione serve, ma non fa miracoli",[12,584,585,586,590],{},"Qui conviene essere onesti. ADR, explanation, reference ben scritta, commit message decenti: tutto questo aiuta moltissimo, e chi ha letto l’articolo su ",[133,587,589],{"href":588},"/blog/ai-codice-commodity-documentazione","il codice come commodity e il perché come asset"," sa già perché.",[12,592,593,594,598],{},"Ma la documentazione non sostituisce il giudizio: lo prepara, lo accelera, lo orienta. È una differenza importante. Chi arriva dopo di te non potrà diventare te leggendo una cartella ",[595,596,597],"code",{},"/docs",", ma potrà evitare mesi di archeologia inutile, potrà partire dal contesto giusto invece che ricostruirlo da zero, potrà sbagliare su problemi veri e non su cose che erano già state capite tre anni prima. E questo è già enorme.",[30,600,602],{"id":601},"il-passaggio-più-difficile-della-carriera-tecnica","Il passaggio più difficile della carriera tecnica",[12,604,605],{},"Secondo me, questo è uno dei passaggi più difficili per chi cresce tecnicamente. Per anni il tuo valore sta nel fatto che vedi cose che altri non vedono, che capisci prima, che decidi meglio, che sei quello che tiene insieme il sistema quando si piega. A un certo punto, però, se continui a giocarti tutto lì, diventi un collo di bottiglia di lusso: molto competente, molto prezioso, molto rispettato, ma sempre un collo di bottiglia.",[12,607,608],{},"La maturità vera arriva quando smetti di chiederti come rendere eterno il tuo contributo personale e inizi a chiederti come costruire un contesto che regga anche quando il tuo contributo personale manca. È un cambio di mestiere, non una rinuncia.",[30,610,612],{"id":611},"il-conforto-giusto","Il conforto giusto",[12,614,615],{},"C’è però una cosa che vale la pena dire, perché è vera. Il fatto che il tuo gusto tecnico non si trasferisca completamente non significa che il tuo lavoro sparisca: significa che il tuo lavoro non consiste nel lasciare una copia di te.",[12,617,618],{},"Consiste nel lasciare chiarezza dove prima c’era solo intuizione, criteri dove prima c’era solo abitudine, contesto dove prima c’era solo memoria, autonomia dove prima c’era solo dipendenza.",[12,620,621],{},"Chi verrà dopo non farà il lavoro come lo avresti fatto tu.",[12,623,624],{},"Meno male.",[12,626,627],{},"Se il sistema che lasci è buono, farà comunque buon lavoro. Non uguale al tuo, ma abbastanza buono da non dipendere più dal fatto che tu sia lì. Ed è probabilmente l’unica eredità professionale sensata che valga la pena costruire.",[629,630],"hr",{},[12,632,633],{},"Puoi trasferire molto, puoi documentare molto, puoi delegare molto. Puoi anche costruire un secondo vero, se fai il lavoro necessario. Quello che non puoi fare è lasciare in eredità il tuo cervello.",[12,635,636],{},"Puoi però lasciare qualcosa di più utile: un sistema che continui a prendere decisioni ragionevoli anche quando tu non ci sei più.",{"title":199,"searchDepth":200,"depth":200,"links":638},[639,640,641,642,643,644,645,646],{"id":519,"depth":200,"text":520},{"id":529,"depth":200,"text":530},{"id":539,"depth":200,"text":540},{"id":553,"depth":200,"text":554},{"id":566,"depth":200,"text":567},{"id":581,"depth":200,"text":582},{"id":601,"depth":200,"text":602},{"id":611,"depth":200,"text":612},"2026-05-12","Documentazione, delega e bus factor aiutano. Ma il gusto tecnico non si trasferisce del tutto. Cosa puoi davvero lasciare a chi viene dopo di te.","/images/blog/successione-tecnica-conoscenza-tacita.jpg",{},"/blog/2026-05-12-successione-tecnica-conoscenza-tacita",{"title":500,"description":648},"Conoscenza tacita: cosa resta quando te ne vai","successione-tecnica-conoscenza-tacita","blog/2026-05-12-successione-tecnica-conoscenza-tacita",[657,658,659,660,661,662,663],"conoscenza-tacita","gestione-team","leadership","documentazione","successione","cultura-tecnica","bus-factor","i6G1K-EzP4QlOmd81G3t8-jai6wQpyZl0OCUrSnwzrg",{"id":666,"title":667,"body":668,"category":210,"date":819,"description":820,"extension":213,"image":821,"meta":822,"navigation":3,"path":823,"published":3,"seo":824,"seoTitle":825,"slug":826,"stem":827,"tags":828,"updated":229,"__hash__":833},"blog/blog/2026-05-07-ai-codice-commodity-documentazione.md","Con l'AI il codice diventa commodity: la documentazione è l'asset",{"type":9,"value":669,"toc":808},[670,673,676,682,686,689,692,695,699,702,713,717,720,723,726,730,733,736,740,743,746,753,757,760,766,769,773,776,779,782,786,789,792,795,799,802,805],[12,671,672],{},"Per anni abbiamo trattato il codice come l’asset principale di un prodotto software. Lo misuravamo, lo difendevamo, lo versionavamo con cura, lo consideravamo il cuore del valore. Se un’azienda aveva tanto codice proprietario, sembrava avere un patrimonio. Se un team produceva tanto codice, sembrava stare costruendo qualcosa di solido.",[12,674,675],{},"Questa idea sta diventando rapidamente falsa. Con gli strumenti AI che ormai fanno parte del lavoro quotidiano — Claude Code, Codex, Cursor e tutto quello che arriverà dopo — il costo di scrivere codice sta scendendo in modo molto netto. Non a zero, ma abbastanza da cambiare la gerarchia delle cose che vale la pena proteggere.",[12,677,678,679,103],{},"Il codice non sparisce. Semplicemente, smette di essere la parte più rara del sistema. La parte rara si sposta altrove: si sposta sul ",[16,680,681],{},"perché",[30,683,685],{"id":684},"il-codice-non-è-più-la-cosa-costosa","Il codice non è più la cosa costosa",[12,687,688],{},"Per capire cosa sta cambiando, basta guardare come lavorava un team anche solo due anni fa. Una nuova feature significava analisi, implementazione, test, rifinitura, refactoring, magari qualche giorno perso su dettagli secondari. Il codice costava tempo, e il tempo costava soldi. Quindi quel codice diventava qualcosa da preservare, da ottimizzare, da non buttare.",[12,690,691],{},"Oggi la situazione è diversa. Un senior con strumenti AI produce in un’ora quello che fino a poco tempo fa richiedeva una giornata. Chi usa davvero questi strumenti lo vede tutti i giorni, e non serve farne una religione per riconoscere che la produttività sulla parte esecutiva è salita tantissimo.",[12,693,694],{},"Quando il costo marginale di produrre codice crolla, il codice si svaluta. Non nel senso che diventa inutile, ma nel senso che diventa meno raro. E quando una cosa diventa meno rara, smette di essere il centro del valore.",[30,696,698],{"id":697},"cosa-resta-raro","Cosa resta raro",[12,700,701],{},"Se il codice si può rigenerare, cosa non si può rigenerare facilmente? Non il repository, non la sintassi, non nemmeno la struttura superficiale del sistema. La cosa davvero difficile da ricostruire è il contesto che ha portato a una decisione: perché quel modulo è fatto così, perché quella dipendenza non è stata sostituita, perché quel flusso apparentemente brutto esiste, perché una soluzione più elegante è stata scartata, perché una certa stranezza non è un errore ma la risposta a un vincolo reale.",[12,703,704,705,708,709,712],{},"Questa roba non vive nel codice. Il codice mostra ",[16,706,707],{},"cosa hai fatto",", molto raramente spiega ",[16,710,711],{},"perché l’hai fatto",". Ed è proprio lì che sta l’asset.",[30,714,716],{"id":715},"il-problema-dei-sistemi-che-nessuno-capisce-più","Il problema dei sistemi che nessuno capisce più",[12,718,719],{},"Chiunque abbia lavorato su un software con qualche anno sulle spalle conosce la scena. Apri un modulo e trovi una scelta strana, e la prima reazione è: “questa cosa va rifatta”. Poi chiedi a chi c’era allora, e scopri che quella scelta era legata a un bug in produzione, a un cliente enorme, a un vincolo fiscale, a un’integrazione esterna assurda, a una limitazione del sistema di allora.",[12,721,722],{},"Quella informazione non era nel codice. Era nella testa di qualcuno. Se quella persona se ne va, il sistema perde valore anche se il repository resta identico.",[12,724,725],{},"Ed è qui che il discorso AI diventa serio: se domani rigeneri quel modulo da capo con un assistente che scrive codice meglio e più velocemente di te, ma non hai il contesto dietro quella scelta, rigeneri qualcosa di più pulito e probabilmente più sbagliato. Il rischio vero è perdere il motivo per cui il codice era fatto in quel modo, più che il codice stesso.",[30,727,729],{"id":728},"il-perché-è-lunica-cosa-che-sopravvive-alla-riscrittura","Il perché è l’unica cosa che sopravvive alla riscrittura",[12,731,732],{},"Questa è la vera inversione. Per anni abbiamo pensato: il codice è l’asset, la documentazione è un costo. Oggi il rapporto si sta ribaltando: il codice si può rigenerare, il perché no. O meglio: il perché si può ricostruire solo se qualcuno lo ha registrato mentre prendeva la decisione. Se non l’ha fatto, sparisce. E quando sparisce, il progetto entra in modalità archeologia.",[12,734,735],{},"Ogni modifica diventa più lenta, ogni refactoring è più rischioso, ogni nuovo ingresso nel team richiede mesi, ogni AI lavora su un sistema formalmente leggibile ma sostanzialmente muto. Il codice di oggi serve a produrre il software di oggi; il perché di oggi serve a produrre il software di domani.",[30,737,739],{"id":738},"ecco-perché-la-documentazione-smette-di-essere-overhead","Ecco perché la documentazione smette di essere “overhead”",[12,741,742],{},"Qui bisogna intendersi: non sto parlando della wiki aziendale piena di pagine morte che nessuno apre da mesi. Quella è arredamento, non documentazione.",[12,744,745],{},"Sto parlando di artefatti che catturano decisioni mentre sono ancora vive: un ADR scritto bene, che spiega quale scelta architetturale è stata fatta e perché; una sezione di explanation che chiarisce il contesto di un modulo; un commit message che non dice “fix bug”, ma spiega quale problema reale è stato corretto e cosa si è scelto di non fare. Queste cose sembrano piccole, in realtà sono l’unico modo per conservare il valore vero del sistema.",[12,747,748,749,752],{},"Diátaxis è utile proprio per questo: perché separa i tipi di documentazione e impedisce di mischiare tutto in un blob inutile. Ma il framework, in fondo, è secondario. Il punto è un altro: ",[16,750,751],{},"il contesto va estratto dalle teste e messo accanto al codice",". Altrimenti, alla prima riscrittura seria, lo perdi.",[30,754,756],{"id":755},"il-cambiamento-strategico-per-chi-decide","Il cambiamento strategico per chi decide",[12,758,759],{},"Se questa lettura è corretta, cambia anche il modo in cui un’azienda dovrebbe investire. Per anni il budget è andato quasi tutto nella produzione di codice; la documentazione, quando andava bene, era il 5% del lavoro. Il ragionamento era semplice: il codice è il prodotto, il resto è supporto.",[12,761,762,763,103],{},"Ora quel ragionamento non regge più. Il codice conta ancora, ovviamente: un codice scritto male resta un problema. Ma il punto non è se il codice conta. Il punto è ",[16,764,765],{},"cosa conviene proteggere di più",[12,767,768],{},"E oggi conviene proteggere il contesto decisionale, perché è quello che non puoi ricomprare dopo: non con un altro team, non con un assistente AI, non con una settimana di reverse engineering. Se un’azienda accumula per anni comprensione del dominio, eccezioni dei clienti, vincoli normativi, ragioni dietro le scelte, e lascia tutto dentro le teste dei senior, sta trattando come sottoprodotto il suo asset principale.",[30,770,772],{"id":771},"i-due-errori-ugualmente-pericolosi","I due errori ugualmente pericolosi",[12,774,775],{},"Qui vedo due estremi. Il primo è continuare come prima: trattare il codice come patrimonio duraturo, sottovalutare la documentazione, lasciare che le decisioni restino implicite. È l’errore più diffuso, e il più costoso nel medio periodo.",[12,777,778],{},"Il secondo è l’errore opposto: pensare che allora basti documentare tutto e lasciare il resto all’AI. Neanche questo funziona, perché il fatto che il codice si svaluti non significa che il gusto tecnico si svaluti. Anzi: se hai persone che non sanno riconoscere una buona decisione da una cattiva, documenteranno male, leggeranno male la documentazione, useranno male l’AI e produrranno rumore a velocità maggiore.",[12,780,781],{},"Il codice diventa commodity, il giudizio no. Il perché diventa asset, ma solo se c’è qualcuno capace di scriverlo, leggerlo e rimetterlo in discussione quando serve.",[30,783,785],{"id":784},"dove-conviene-investire-oggi","Dove conviene investire oggi",[12,787,788],{},"Se dovessi semplificarlo brutalmente, direi così: meno energia nel proteggere il codice come oggetto da museo, più energia nel catturare il contesto che permette di rigenerarlo bene.",[12,790,791],{},"Questo significa scrivere ADR per le decisioni che contano davvero, non per ogni dettaglio. Significa tenere una explanation documentata per i moduli strani o sensibili, e una reference accurata dove serve sul serio. Significa scrivere commit e pull request che spieghino il motivo del cambiamento, non solo il cambiamento; e fare review che valutino anche la qualità del ragionamento, non solo la qualità del codice.",[12,793,794],{},"Sembrano dettagli. In realtà sono la differenza tra un sistema che può essere rigenerato e uno che deve essere scavato.",[30,796,798],{"id":797},"la-scelta-si-fa-adesso","La scelta si fa adesso",[12,800,801],{},"Il modo in cui un team documenta oggi determina quanto sarà facile usare bene l’AI tra uno, due o tre anni. Chi avrà contesto ben catturato potrà rigenerare velocemente codice buono; chi avrà solo montagne di codice e poco perché dovrà prima ricostruire la storia del sistema, e quella parte sarà lenta, costosa e piena di errori.",[12,803,804],{},"La scelta, in fondo, è molto semplice. Puoi continuare a trattare il codice come il bene da proteggere, oppure puoi iniziare a proteggere quello che rende il codice sostituibile senza perdere il sistema.",[12,806,807],{},"Il codice è il cosa di oggi. Il perché è il capitale che ti permette di ricostruire il cosa domani.",{"title":199,"searchDepth":200,"depth":200,"links":809},[810,811,812,813,814,815,816,817,818],{"id":684,"depth":200,"text":685},{"id":697,"depth":200,"text":698},{"id":715,"depth":200,"text":716},{"id":728,"depth":200,"text":729},{"id":738,"depth":200,"text":739},{"id":755,"depth":200,"text":756},{"id":771,"depth":200,"text":772},{"id":784,"depth":200,"text":785},{"id":797,"depth":200,"text":798},"2026-05-07","Con l'AI il costo di scrivere codice crolla. Quello che resta davvero raro è il perché delle decisioni: architettura, trade-off, vincoli, contesto.","/images/blog/ai-codice-commodity-documentazione.jpg",{},"/blog/2026-05-07-ai-codice-commodity-documentazione",{"title":667,"description":820},"AI e sviluppo software: il codice si svaluta, il contesto no","ai-codice-commodity-documentazione","blog/2026-05-07-ai-codice-commodity-documentazione",[222,660,829,226,830,831,228,832],"strategia","adr","diataxis","futuro-del-software","3G6lTUKmqd5iGfk6RX9n17tR1qo8G8g5qqa6ZZlyquQ",{"id":835,"title":836,"body":837,"category":210,"date":1014,"description":1015,"extension":213,"image":1016,"meta":1017,"navigation":3,"path":1018,"published":3,"seo":1019,"seoTitle":1020,"slug":1021,"stem":1022,"tags":1023,"updated":229,"__hash__":1027},"blog/blog/2026-05-05-bus-factor-reale-come-misurarlo-e-alzarlo.md","Bus factor reale: come misurarlo davvero e costruire un secondo",{"type":9,"value":838,"toc":1003},[839,850,853,857,860,867,870,873,877,880,886,898,901,905,908,911,915,918,921,925,928,931,937,940,943,947,950,953,964,968,971,974,977,981,984,987,990,994,997,1000],[12,840,841,842,845,846,849],{},"In un articolo precedente ho spiegato perché il ",[133,843,844],{"href":573},"bus factor è una delle metriche di rischio più ignorate nello sviluppo software",". Questo articolo parte da lì, ma va un passo oltre: non tanto perché il bus factor conta — quello ormai dovrebbe essere chiaro — ma ",[16,847,848],{},"come si misura davvero",". Perché il numero che quasi tutti hanno in testa è quasi sempre falso.",[12,851,852],{},"Il motivo è semplice. Quando un team guarda sé stesso da dentro, tende a sovrastimare quanto la conoscenza sia distribuita. Quattro sviluppatori che lavorano sullo stesso progetto sembrano un bus factor di quattro. Sulla carta è rassicurante. Nella pratica, spesso è uno.",[30,854,856],{"id":855},"il-bus-factor-che-racconti-e-quello-che-hai-davvero","Il bus factor che racconti e quello che hai davvero",[12,858,859],{},"Il bus factor apparente è facile da raccontare. Si calcola così: quante persone lavorano sul progetto? Quante sanno aprire il repository, fare una modifica, chiudere un bug, scrivere una feature? Se la risposta è “quattro”, allora ci si convince che il rischio sia basso.",[12,861,862,863,866],{},"Il bus factor reale è un’altra cosa. La domanda giusta non è “quante persone sanno contribuire?”, ma ",[16,864,865],{},"quante persone possono tenere in piedi il progetto da sole quando succede qualcosa di non previsto?"," Non eseguire task già definiti, non fare il compitino assegnato, non portare avanti il lavoro finché tutto fila liscio. Sto parlando di decidere: che trade-off fare, dove mettere mano, cosa sacrificare, come spiegare la scelta allo stakeholder, come tenere insieme il tutto quando il progetto si piega sotto un problema vero. Lì il numero si abbassa brutalmente.",[12,868,869],{},"Nella maggior parte dei team c’è una persona che tiene in testa il sistema intero. Le altre conoscono bene le parti su cui lavorano, abbastanza quelle adiacenti, poco o nulla il resto. Finché il lavoro è ordinario, sembra che tutto funzioni. Quando arriva l’imprevisto, tutti tornano da quella persona.",[12,871,872],{},"Quella persona è il tuo bus factor reale.",[30,874,876],{"id":875},"il-test-che-non-perdona","Il test che non perdona",[12,878,879],{},"Il modo migliore per capire se ti stai raccontando una favola è molto semplice: sparisci per una settimana. Non ferie vere, non “scrivimi se succede qualcosa di grave”. Proprio una settimana in cui, su quel progetto, tu non ci sei, e le decisioni vanno prese senza di te.",[12,881,882,883],{},"Il punto non è se qualcuno ti cerca — quello succederà comunque. Il punto è un altro: ",[16,884,885],{},"al tuo ritorno trovi decisioni già prese oppure una pila di cose lasciate in sospeso perché “dovevi vederle tu”?",[12,887,888,889,891,892,894,895,897],{},"Se trovi la seconda, il tuo bus factor è 1.",[340,890],{},"\nAnche se il team è di cinque persone.",[340,893],{},"\nAnche se tutti sono bravi.",[340,896],{},"\nAnche se il progetto “va bene”.",[12,899,900],{},"Questo è il test che separa la ridondanza reale dalla semplice sensazione di avere una squadra.",[30,902,904],{"id":903},"il-bug-notturno-è-sempre-più-sincero-dei-processi","Il bug notturno è sempre più sincero dei processi",[12,906,907],{},"C’è un altro momento in cui il bus factor smette di mentire: il problema notturno. Se alle due di notte succede qualcosa in produzione, quante persone possono davvero diagnosticare il problema e risolverlo? Non alzare il telefono e farsi guidare, non “tamponare finché domani si vede”. Risolverlo.",[12,909,910],{},"È lì che capisci quanta conoscenza del sistema è superficiale e quanta invece è strutturale. Molti team scoprono in quel momento che il loro progetto è, di fatto, una monarchia tecnica travestita da organizzazione distribuita.",[30,912,914],{"id":913},"il-sintomo-più-sottovalutato-lonboarding","Il sintomo più sottovalutato: l’onboarding",[12,916,917],{},"C’è poi un test ancora più subdolo, perché non ha il pathos del bug in produzione ma dice la verità con la stessa precisione: il tempo che serve a una persona senior per diventare operativa.",[12,919,920],{},"Se domani entra qualcuno molto bravo, quanto ci mette a muoversi sul progetto senza appoggiarsi continuamente alla stessa persona? Se la risposta vera è “mesi”, allora la conoscenza è ancora quasi tutta in una testa sola. Se invece in due settimane riesce a orientarsi leggendo, facendo qualche domanda e prendendo mano ai moduli giusti, vuol dire che una parte della conoscenza è stata esternalizzata. Ed è lì che entra in gioco la documentazione fatta bene.",[30,922,924],{"id":923},"la-documentazione-aiuta-quella-finta-no","La documentazione aiuta. Quella finta no.",[12,926,927],{},"Qui serve una distinzione brutale. La documentazione non alza il bus factor solo perché esiste una wiki: quella roba, nella maggior parte dei casi, serve solo a far sentire il team più ordinato di quanto sia davvero. La documentazione utile è quella che permette a qualcuno di entrare, capire e fare, non quella che spiega genericamente il sistema con belle parole e diagrammi dimenticati da sei mesi.",[12,929,930],{},"Il principio giusto è semplice: una documentazione sana separa le cose per quello che sono. C’è la parte che ti aiuta a capire il perché, quella che ti dice come fare una cosa specifica, quella che ti serve da riferimento quando cerchi un dettaglio preciso. Mischiare tutto nello stesso documento produce solo confusione.",[12,932,933,934,103],{},"Il nome del framework conta relativamente. Il punto vero è un altro: ",[16,935,936],{},"la conoscenza deve uscire dalle teste e finire in artefatti che qualcuno può usare davvero",[12,938,939],{},"Il problema è che la documentazione decade. Sempre. Oggi è corretta, tra diciotto mesi no. E decade nel modo peggiore: in silenzio. Nessuno se ne accorge finché qualcuno prova a seguirla e si schianta.",[12,941,942],{},"Per questo la documentazione non va trattata come un progetto a parte da fare “quando c’è tempo”. Va trattata come parte del lavoro normale. Se cambi il sistema e non aggiorni la documentazione che serve a capirlo, stai solo spostando il problema in avanti.",[30,944,946],{"id":945},"perché-il-bus-factor-resta-basso-anche-nei-team-forti","Perché il bus factor resta basso anche nei team forti",[12,948,949],{},"Questo è il punto che confonde più persone. Puoi avere un team bravo, serio, capace, e avere comunque un bus factor reale di 1. Perché contribuire bene non significa poter sostituire davvero: sono due cose diverse.",[12,951,952],{},"Un team funziona quando ognuno sa fare bene il proprio pezzo. Il bus factor sale quando almeno un’altra persona sa fare anche il tuo. E questo richiede un investimento esplicito, che spesso non si fa perché sembra inefficiente: in apparenza è uno spreco, stai chiedendo a qualcuno di imparare cose che già un altro sa fare. In realtà è esattamente il contrario. Stai pagando ridondanza oggi per non trovarti paralizzato domani.",[12,954,955,956,963],{},"Il problema è che questo investimento andrebbe fatto proprio dalla persona più sovraccarica del sistema. E quella persona, quasi sempre, non ha tempo. È lo stesso meccanismo che ho raccontato in ",[133,957,959],{"href":958},"/blog/troppi-ruoli-una-persona-rischio",[960,961,962],"em",{},"Quando una persona copre troppi ruoli, l’organizzazione è fragile",": il sistema dipende da qualcuno proprio perché quel qualcuno non ha mai avuto il margine per costruire un’alternativa.",[30,965,967],{"id":966},"costruire-un-secondo-non-significa-passare-task","Costruire un secondo non significa passare task",[12,969,970],{},"Qui c’è l’errore più comune. Molti pensano che costruire un secondo significhi iniziare a distribuire lavoro. Non basta: passare task produce supporto operativo, non ridondanza reale.",[12,972,973],{},"Se vuoi costruire un secondo, devi dare a qualcuno un pezzo intero di sistema. Un’area con responsabilità vera. Qualcosa su cui quella persona debba decidere, sbagliare, capire, difendere scelte e portarne il peso. Se continui a dare compiti singoli, il modello mentale resta nel tuo cervello: l’altra persona impara a eseguire, non a sostituire.",[12,975,976],{},"Poi c’è il passaggio più difficile: smettere di correggere tutto. All’inizio la review serve. Poi arriva un punto in cui tu continui a rivedere tutto solo per rassicurarti, e lì la review smette di essere uno strumento di qualità e diventa una tassa sulla crescita dell’altro. Il momento in cui capisci che stai facendo sul serio è questo: l’altra persona prende una decisione diversa da quella che avresti preso tu, ma ragionevole. Se la tua reazione è correggerla comunque, non stai costruendo un secondo. Stai costruendo una copia minore di te.",[30,978,980],{"id":979},"da-1-a-2-cambia-quasi-tutto","Da 1 a 2 cambia quasi tutto",[12,982,983],{},"Non serve inseguire la perfezione. Non serve un bus factor di 5 ovunque. Nella maggior parte dei casi, la vera soglia è passare da 1 a 2 sulle parti critiche.",[12,985,986],{},"Con una sola persona, l’indisponibilità è un rischio costante. Con due, la resilienza cambia drasticamente. Non in modo lineare: proprio di ordine di grandezza.",[12,988,989],{},"È qui che molte aziende sbagliano. Vedono la costruzione del “secondo” come un lusso organizzativo. In realtà è una forma di assicurazione. Costa prima, salva dopo.",[30,991,993],{"id":992},"il-punto-di-partenza-se-il-tuo-bus-factor-è-1","Il punto di partenza, se il tuo bus factor è 1",[12,995,996],{},"Se leggendo questo articolo ti sei reso conto che il tuo progetto gira davvero intorno a una sola persona, non serve fare teorie. Serve iniziare da qualcosa di estremamente concreto.",[12,998,999],{},"Scegli una persona specifica. Non “il team”, non “nei prossimi mesi distribuiremo meglio la conoscenza”. Una persona con nome e cognome. Dagli un’area precisa. Lasciale prendere decisioni. Lasciale sbagliare in modo controllato. Costringiti a non intervenire su tutto. Poi pianifica la settimana in cui non ci sarai.",[12,1001,1002],{},"Perché finché non fai quel test, puoi raccontarti quello che vuoi. Il bus factor, come la sicurezza o il debito tecnico, sembra sotto controllo finché non lo metti davvero alla prova. E quando cede, di solito cede tutto insieme.",{"title":199,"searchDepth":200,"depth":200,"links":1004},[1005,1006,1007,1008,1009,1010,1011,1012,1013],{"id":855,"depth":200,"text":856},{"id":875,"depth":200,"text":876},{"id":903,"depth":200,"text":904},{"id":913,"depth":200,"text":914},{"id":923,"depth":200,"text":924},{"id":945,"depth":200,"text":946},{"id":966,"depth":200,"text":967},{"id":979,"depth":200,"text":980},{"id":992,"depth":200,"text":993},"2026-05-05","Il bus factor apparente quasi sempre inganna: nella maggior parte dei team è 1. Come capire quello reale e alzarlo senza allargare il team.","/images/blog/bus-factor-reale-come-misurarlo-e-alzarlo.jpg",{},"/blog/2026-05-05-bus-factor-reale-come-misurarlo-e-alzarlo",{"title":836,"description":1015},"Come calcolare e alzare il bus factor nello sviluppo software","bus-factor-reale-come-misurarlo-e-alzarlo","blog/2026-05-05-bus-factor-reale-come-misurarlo-e-alzarlo",[663,658,1024,660,1025,1026],"rischio","delega","organizzazione","8jZciW65ZitXOJQ89-xTYOZSttNrjOaHsSPvVsXQAQY",{"id":1029,"title":1030,"body":1031,"category":210,"date":1124,"description":1125,"extension":213,"image":1126,"meta":1127,"navigation":3,"path":1128,"published":3,"seo":1129,"seoTitle":1130,"slug":1131,"stem":1132,"tags":1133,"updated":229,"__hash__":1135},"blog/blog/2026-04-30-codice-funziona-non-significa-buona-idea.md","Il codice funziona. Non significa che sia una buona idea.",{"type":9,"value":1032,"toc":1117},[1033,1039,1043,1046,1049,1052,1056,1059,1062,1065,1069,1076,1084,1092,1096,1099,1107,1111,1114],[12,1034,1035,1038],{},[16,1036,1037],{},"Uno sviluppatore di medio livello entra in un progetto nuovo."," Invece di passare le prime settimane a capire il codice esistente e come funziona il dominio, apre un assistente AI e inizia a produrre feature. I ticket si chiudono, le pull request arrivano, i test passano. Tutto sembra ottimo. Dopo un mese, i numeri parlano: questa persona produce il doppio di chi è entrato con lo stesso ruolo un anno fa. Un anno fa sarebbe stato un mezzo disastro, oggi sembra una notizia entusiasmante. Non lo è, e la differenza tra le due cose si paga in produzione.",[30,1040,1042],{"id":1041},"una-scena-che-si-ripete","Una scena che si ripete",[12,1044,1045],{},"In un punto del prodotto c'è un'operazione che, quando l'utente salva, deve aspettare un calcolo in background prima di aggiornare una parte della pagina. Ci sono due modi ovvi di farlo. Il primo: aspettare qualche decimo di secondo in più, salvare, rileggere il dato, mostrarlo. Venti righe di codice. Il secondo: salvare subito, far girare il calcolo in modo asincrono, notificare la pagina quando il calcolo finisce e aggiornare il DOM in tempo reale. Un sistema di code, un canale di notifica real-time al browser, logica di reconnect, gestione degli stati intermedi. È anche molto più interessante da scrivere.",[12,1047,1048],{},"Lo sviluppatore sceglie il secondo. L'AI lo aiuta, il codice esce pulito, ordinato, testato, e la PR passa la review. Arriva in produzione e non succede nulla. Per qualche settimana.",[12,1050,1051],{},"Il problema emerge dopo: il calcolo in background, nel sistema reale, non dura mezzo secondo. Dura minuti, a volte ore — il backend lo gestisce in una coda che dipende dal carico. Nel frattempo l'utente ha cambiato pagina, aperto altro, riaperto lo stesso schermo in un'altra scheda. Quando finalmente la notifica arriva, trova un DOM che non esiste più, o peggio ne aggiorna uno che non doveva aggiornare. L'utente vede la pagina rompersi in modo incomprensibile. A volte perde dati.",[30,1053,1055],{"id":1054},"lerrore-non-era-nel-codice","L'errore non era nel codice",[12,1057,1058],{},"Il codice era scritto decentemente. La review non ha trovato nulla perché tecnicamente era tutto corretto. L'errore era una scelta architetturale che nessuno ha mai discusso esplicitamente: non serviva un sistema real-time per un problema che si risolveva aspettando mezzo secondo al salvataggio. La soluzione semplice era anche quella giusta, la soluzione sofisticata ha introdotto una classe di bug che nel modello banale non poteva nemmeno esistere.",[12,1060,1061],{},"Lo sviluppatore non l'ha visto perché non conosceva ancora il prodotto — era da poco sul progetto e aveva saltato la fase di studio. Non sapeva che quei calcoli potevano durare ore, non aveva osservato come gli utenti usavano davvero quella pagina. L'AI non poteva vederlo: ha risposto alla domanda \"come aggiorno una pagina in modo asincrono\" con la risposta più sofisticata disponibile, non con quella più adatta al contesto. Nessuno dei due aveva il contesto, e il contesto è l'unica cosa che l'AI non può ricostruire da sola.",[12,1063,1064],{},"La review non l'ha intercettato per un motivo strutturale: una PR review guarda il codice, non l'architettura. Controlla che i test passino, che lo stile sia giusto, che non ci siano errori evidenti. Raramente chiede \"ma serviva davvero fare così?\". Quando il codice è pulito e viene da qualcuno che usa l'AI, la review diventa ancora meno sensibile, perché quel codice è indistinguibile da qualsiasi altro codice dello stesso tipo.",[30,1066,1068],{"id":1067},"velocità-di-produzione-superficie-di-decisioni","Velocità di produzione, superficie di decisioni",[12,1070,1071,1072,1075],{},"Questa non è una scena isolata. È quello che sta succedendo in tantissimi team che hanno adottato l'AI senza ripensare come lavorano. ",[133,1073,1074],{"href":135},"La produttività sale"," ed è facilmente misurabile: più PR, più ticket chiusi, più codice in arrivo. Sotto la superficie si accumulano scelte architetturali che nessuno ha mai vagliato, e ognuna di quelle scelte è una piccola bomba a tempo.",[12,1077,1078,1079,1083],{},"La bomba non esplode nelle settimane di sviluppo. Esplode in produzione, mesi dopo, quando gli utenti iniziano a segnalare ",[133,1080,1082],{"href":1081},"/blog/software-fragile-regressioni","bug che si moltiplicano quando tocchi qualcosa",", data loss a bassa frequenza ma alto impatto, comportamenti strani che in ambiente di test non si riproducono. Casi limite che non corrispondono mai alla documentazione, perché la documentazione non esiste: chi ha scritto il codice non aveva tempo, e l'AI lo ha seguito sulla velocità.",[12,1085,1086,1087,1091],{},"Il costo lo paga chi ha commissionato il software. Lo paga nel crescere dei ticket di produzione, nei tempi di risposta del team su problemi che \"non capiamo da dove vengano\", nel momento in cui qualcuno deve ",[133,1088,1090],{"href":1089},"/blog/riscrivere-software-da-zero","smantellare un'architettura inutilmente complicata e rimetterla semplice"," — una seconda volta, con un altro team.",[30,1093,1095],{"id":1094},"lai-amplifica-quello-che-già-cè","L'AI amplifica quello che già c'è",[12,1097,1098],{},"L'AI nelle mani di uno sviluppatore senior amplifica il giudizio: chi già sa riconoscere quando una soluzione semplice batte una soluzione impressionante usa l'AI per andare più veloce su quella strada. L'AI nelle mani di uno sviluppatore meno esperto amplifica l'ottimismo: la fiducia che, siccome il codice funziona nei test, allora la soluzione è giusta. Più aumenta la velocità con cui il team produce, più aumenta la superficie di decisioni non controllate.",[12,1100,1101,1102,1106],{},"La contromisura non è togliere l'AI al team, cosa che nessuna azienda con un minimo di senso farà. È cambiare il criterio con cui si valuta il lavoro. Il mestiere oggi non è produrre codice: quello l'AI lo fa in fretta, pulito, spesso meglio di un umano. Il mestiere è capire il problema, scegliere la ",[133,1103,1105],{"href":1104},"/blog/semplicita-nel-software","soluzione più semplice che risolve davvero",", proteggere le scelte architetturali nei momenti in cui conta farlo.",[30,1108,1110],{"id":1109},"la-domanda-da-fare-al-team","La domanda da fare al team",[12,1112,1113],{},"Chi guida o commissiona un team che usa l'AI dovrebbe smettere di chiedere \"quanto producete in uno sprint?\" e iniziare a chiedere \"quanto di quello che avete prodotto negli ultimi tre mesi pensate di tenere tra un anno?\". È la domanda che filtra la velocità utile dalla velocità pericolosa. Oggi molti team non sanno rispondere, o peggio rispondono \"tutto\" senza averci pensato sopra.",[12,1115,1116],{},"Il fatto che il codice funzioni non significa che sia una buona idea. È una distinzione che l'AI ha reso molto più importante, perché il codice che funziona ma è una cattiva idea oggi si produce dieci volte più in fretta di prima. In produzione si paga esattamente uguale.",{"title":199,"searchDepth":200,"depth":200,"links":1118},[1119,1120,1121,1122,1123],{"id":1041,"depth":200,"text":1042},{"id":1054,"depth":200,"text":1055},{"id":1067,"depth":200,"text":1068},{"id":1094,"depth":200,"text":1095},{"id":1109,"depth":200,"text":1110},"2026-04-30","Con l'AI i team chiudono più ticket e producono più PR. Ma 'funziona nei test' non dice se la decisione architetturale era quella giusta — e il conto arriva in produzione.","/images/blog/codice-funziona-non-significa-buona-idea.jpg",{},"/blog/2026-04-30-codice-funziona-non-significa-buona-idea",{"title":1030,"description":1125},"Codice che funziona ma è sbagliato: il rischio dell'AI nei team","codice-funziona-non-significa-buona-idea","blog/2026-04-30-codice-funziona-non-significa-buona-idea",[222,226,1134,225,228,658],"qualita-codice","S9dwvPH4gBOQB7bWM_hOf_UjWPuDhtH69y7hZihINoA",{"id":1137,"title":1138,"body":1139,"category":210,"date":1237,"description":1238,"extension":213,"image":1239,"meta":1240,"navigation":3,"path":1241,"published":3,"seo":1242,"seoTitle":1243,"slug":1244,"stem":1245,"tags":1246,"updated":229,"__hash__":1252},"blog/blog/2026-04-28-ai-progetta-software-costo-reale-sviluppo.md","L'AI progetta il software in cinque minuti. Costruirlo richiede ancora sei mesi.",{"type":9,"value":1140,"toc":1229},[1141,1147,1151,1154,1157,1161,1164,1167,1171,1177,1180,1184,1187,1195,1198,1202,1205,1212,1219,1223,1226],[12,1142,1143,1146],{},[16,1144,1145],{},"Hai un'idea di prodotto."," La racconti a ChatGPT, Claude o al modello di turno. Dopo qualche scambio ottieni un documento tecnico: architettura a box, database vettoriale, pipeline di ingestion dei dati, i nomi di ogni tecnologia al posto giusto. Sembra un deliverable da studio di consulenza. Arrivi con quel documento a chiedere un preventivo, con un budget di qualche migliaio di euro in testa. E qualcuno ti deve spiegare che il progetto descritto in quel documento costa uno zero in più. È la scena più comune degli ultimi mesi, e quella che due anni fa non esisteva.",[30,1148,1150],{"id":1149},"il-pattern-si-ripete","Il pattern si ripete",[12,1152,1153],{},"Negli anni 2000 bastavano 3.000 euro per chiedere \"un sito come Amazon\" anzi, a dire il vero \"un sito come eBay\", senza nessuna idea di cosa significasse costruire un e-commerce a quella scala. Poi è toccato a \"un'app come Airbnb\" con WordPress e plugin, poi a \"una piattaforma no-code in un weekend\". Oggi la cifra richiesta è simile — tipicamente tra i 2 e i 5K — ma l'idea coinvolge tecnologie che fino a ieri richiedevano mezza Silicon Valley per essere tenute in piedi: database vettoriali, modelli linguistici in API, pipeline di OCR, crawler distribuiti.",[12,1155,1156],{},"Ogni generazione di astrazioni produce lo stesso effetto: la superficie diventa accessibile, il sotto resta un casino. Chi sta sopra non lo vede finché non ci sbatte la testa. L'AI ha semplicemente spinto l'astrazione un piano più in alto, e il divario tra aspettativa e realtà di sviluppo è diventato più grande di quanto sia mai stato.",[30,1158,1160],{"id":1159},"cosa-fa-davvero-lai-quando-progetta-un-software","Cosa fa davvero l'AI quando \"progetta un software\"",[12,1162,1163],{},"Un modello linguistico mette in fila nomi che sembrano pertinenti. Prende la descrizione del tuo problema, la associa a pattern visti in miliardi di documenti tecnici, produce un diagramma plausibile. Postgres con pgvector, crawler headless, modelli in API, microservizi dove servono, pipeline di OCR per i documenti. Frecce giuste, box giusti. A colpo d'occhio è indistinguibile dal lavoro di un professionista con anni di esperienza alle spalle.",[12,1165,1166],{},"Il problema è che il modello non ha mai messo un sistema del genere in produzione. Non sa che l'OCR su un documento sporco rende una volta su tre. Non sa che fare web scraping è complesso perchè il sito può cambiare struttura senza preavviso, o mettere una protezione antibot. Non sa che il 70% del costo di un sistema come quello che ha disegnato non è nel codice: è nella pulizia dei dati, nella manutenzione continua delle regole di business, nella difficoltà quotidiana di tenere aggiornato un database che descrive un mondo che cambia.",[30,1168,1170],{"id":1169},"lottimismo-strutturale-dei-modelli","L'ottimismo strutturale dei modelli",[12,1172,1173,1174,103],{},"C'è un'altra caratteristica importante di come rispondono questi modelli. L'AI dice quasi sempre che si può fare. La domanda \"è fattibile?\" riceve una risposta ottimistica perché il modello non ha mai pagato un mese di debug in produzione, non ha mai visto un cliente abbandonare per un bug ricorrente, non ha mai dovuto coordinare quattro persone che parlano linguaggi diversi del progetto. Risponde \"ottima idea, iniziamo lo sviluppo\" con la stessa fiducia con cui ti darebbe una ricetta di cucina. Poi inizi a costruire e scopri che il 10% del progetto occupa il 90% del tempo, e ",[133,1175,1176],{"href":301},"le stime diventano imprecise proprio per questo",[12,1178,1179],{},"A questo si somma un secondo fenomeno: le allucinazioni. Il modello cita librerie che non esistono, API che non fanno quello che dice, pattern che sembrano standard ma nessuno ha mai davvero usato in quel modo. Nel documento iniziale non si vedono. Si vedono dopo, in sviluppo, quando per ogni pezzo dell'architettura tocca verificare che esista e funzioni come promesso.",[30,1181,1183],{"id":1182},"larchitettura-è-diventata-gratis-la-costruzione-no","L'architettura è diventata gratis. La costruzione no.",[12,1185,1186],{},"Fino a poco tempo fa, un documento tecnico di quel tipo richiedeva giornate di lavoro a qualcuno che lo stack lo aveva usato davvero. Oggi chiunque lo ottiene in cinque minuti. Questa parte si è commoditizzata, ed è giusto riconoscerlo.",[12,1188,1189,1190,1194],{},"Il lavoro di costruzione, invece, non si è ridotto nella stessa proporzione. Chi sa far girare quei box in produzione, con dati reali e sporchi, con sistemi esterni che si comportano male, con eccezioni che emergono solo dopo il lancio, non è stato sostituito. È diventato meno visibile, perché la patina del documento AI fa sembrare che il lavoro sia quasi finito quando in realtà non è ancora iniziato. ",[133,1191,1193],{"href":1192},"/blog/quanto-costa-un-software-custom","Il grosso del costo nello sviluppo software si nasconde proprio lì",", e nessun documento generato in cinque minuti può raccontarlo.",[12,1196,1197],{},"Un architetto che non sa quanto costa davvero costruire un muro è un architetto inutile: disegna palazzi che non stanno in piedi. L'AI oggi produce esattamente questo genere di architetti, e tantissime aziende si trovano in mano progetti elegantissimi sulla carta e infattibili nella sostanza.",[30,1199,1201],{"id":1200},"il-confronto-utile-per-chi-deve-commissionare","Il confronto utile per chi deve commissionare",[12,1203,1204],{},"Chi arriva a un colloquio con un documento generato dall'AI ha bisogno di una cosa nuova, anche se sembra vecchia: qualcuno che quel documento lo sappia leggere e dire dove si romperà in produzione. Qualcuno che sappia distinguere l'idea fattibile con questo budget da quella che richiede dieci volte tanto o che semplicemente non può esistere in quella forma.",[12,1206,1207,1208,1211],{},"Il confronto economico utile è diverso da quello che l'AI suggerisce implicitamente. Il costo di un software custom non si paragona al costo di un software pronto: si paragona al costo del lavoro tecnico senior necessario per costruirlo. Mesi di qualcuno che ha visto cosa succede quando un box diventa codice, quando una freccia diventa un'integrazione, quando un nome di tecnologia diventa un mese di debug. ",[133,1209,1210],{"href":449},"Partire dal budget reale, non dall'ambizione del documento, rende la conversazione utile",": si decide cosa costruire prima, cosa rimandare, cosa non fare.",[12,1213,1214,1215,1218],{},"Chi commissiona software oggi dovrebbe diffidare del primo che risponde \"partiamo subito\" al documento AI. È il segnale che sta leggendo quel documento con lo stesso sguardo con cui l'AI l'ha scritto. Chi vale davvero fa domande fastidiose sul processo, sui dati veri, sulle eccezioni, sui volumi. Propone fasi e trade-off espliciti invece di una versione \"completa\". ",[133,1216,1217],{"href":418},"Fa emergere lo scope prima che esploda"," a metà progetto. Presenta numeri che sembrano alti confrontati alle promesse dell'AI, e sono solo realistici.",[30,1220,1222],{"id":1221},"il-gap-lavora-a-favore-di-chi-sa-costruire","Il gap lavora a favore di chi sa costruire",[12,1224,1225],{},"La parte interessante è che l'asimmetria di oggi lavora a favore di chi costruisce davvero. Più l'AI rende facile produrre documenti impressionanti, più sottostime cresceranno, più progetti partiranno con premesse sbagliate, più chi riesce a portarli a casa diventerà raro.",[12,1227,1228],{},"Il valore, come succede a ogni salto di astrazione, si sposta un piano più giù — sul muratore, non sull'architetto. Sul mestiere che nessuno vede finché non c'è più.",{"title":199,"searchDepth":200,"depth":200,"links":1230},[1231,1232,1233,1234,1235,1236],{"id":1149,"depth":200,"text":1150},{"id":1159,"depth":200,"text":1160},{"id":1169,"depth":200,"text":1170},{"id":1182,"depth":200,"text":1183},{"id":1200,"depth":200,"text":1201},{"id":1221,"depth":200,"text":1222},"2026-04-28","Farsi progettare un software dall'AI oggi costa cinque minuti. Perché il costo di sviluppo non è sceso con la stessa proporzione del costo di disegnarne l'architettura.","/images/blog/ai-progetta-software-costo-reale-sviluppo.jpg",{},"/blog/2026-04-28-ai-progetta-software-costo-reale-sviluppo",{"title":1138,"description":1238},"AI che progetta software: quanto costa davvero svilupparlo","ai-progetta-software-costo-reale-sviluppo","blog/2026-04-28-ai-progetta-software-costo-reale-sviluppo",[222,226,1247,1248,1249,1250,1251],"budget","preventivi","chatgpt","scope-creep","software-custom","mY036ZKkGvlx6OtGElHue_WsUut7WgYIkPc9Nqm1W00",{"id":1254,"title":1255,"body":1256,"category":210,"date":1405,"description":1406,"extension":213,"image":1407,"meta":1408,"navigation":3,"path":1409,"published":3,"seo":1410,"seoTitle":1411,"slug":1412,"stem":1413,"tags":1414,"updated":229,"__hash__":1417},"blog/blog/2026-04-23-troppi-ruoli-una-persona-rischio.md","Troppi ruoli su una persona: il rischio organizzativo nascosto",{"type":9,"value":1257,"toc":1396},[1258,1261,1267,1271,1274,1280,1283,1287,1294,1297,1313,1316,1320,1323,1326,1329,1340,1343,1347,1350,1353,1356,1360,1363,1366,1369,1371,1377,1383,1387,1390,1393],[12,1259,1260],{},"Nelle aziende che sviluppano software c’è una situazione molto comune che viene spesso scambiata per un punto di forza: una persona sola tiene insieme tutto. Parla con lo stakeholder, decide cosa costruire, tiene il piano, guida le scelte tecniche, mette mano al codice quando serve. Se c’è un problema, lo risolve. Se serve decidere, decide.",[12,1262,1263,1264,1266],{},"Dall’esterno sembra una fortuna.",[340,1265],{},"\nDall’interno, è una fragilità.",[30,1268,1270],{"id":1269},"non-è-un-problema-di-talento","Non è un problema di talento",[12,1272,1273],{},"La lettura più comoda è: “è una persona molto brava”. Quella meno comoda è: l’azienda non ha costruito le funzioni di cui ha bisogno e le ha scaricate tutte su chi riesce a reggerle. Quasi sempre è la seconda.",[12,1275,1276,1277],{},"C’è un modo semplice per capirlo: se quella persona sparisce per una settimana, cosa succede? Non se qualcuno la chiama — quello succede sempre. La domanda è: ",[16,1278,1279],{},"le decisioni vanno avanti o si fermano?",[12,1281,1282],{},"Se si fermano, non hai una risorsa preziosa. Hai un collo di bottiglia.",[30,1284,1286],{"id":1285},"il-problema-non-è-il-carico-di-lavoro","Il problema non è il carico di lavoro",[12,1288,1289,1290,103],{},"Chi vive questa situazione spesso regge. Lavora tanto, si organizza, trova il tempo. Il problema è il tipo di attenzione richiesta, più che il numero di ore. Pensare al prodotto richiede un certo tipo di testa, gestire il progetto un altro, prendere decisioni architetturali un altro ancora, scrivere codice richiede concentrazione profonda. Non sono attività che convivono bene nella stessa giornata, e ogni volta che cambi contesto paghi un costo: non in tempo, ma in qualità. È lo stesso problema delle interruzioni: ",[133,1291,1293],{"href":1292},"/blog/ogni-interruzione-costa-23-minuti","ogni cambio di contesto costa più di quanto pensi",[12,1295,1296],{},"Quando tutto passa da una persona, succede questo:",[1298,1299,1300,1304,1307,1310],"ul",{},[1301,1302,1303],"li",{},"il codice si scrive di corsa",[1301,1305,1306],{},"le decisioni si prendono a metà",[1301,1308,1309],{},"il prodotto si capisce superficialmente",[1301,1311,1312],{},"la visione di lungo periodo sparisce",[12,1314,1315],{},"Non perché la persona non sia capace, ma perché sta facendo cinque lavori insieme.",[30,1317,1319],{"id":1318},"il-tentativo-che-peggiora-le-cose","Il tentativo che peggiora le cose",[12,1321,1322],{},"A un certo punto l’azienda se ne accorge, e prova a “scaricare un po’ di lavoro”: arriva qualcuno a fare project management, oppure qualcuno sul prodotto. Sulla carta, il problema è risolto. Nella pratica, no.",[12,1324,1325],{},"Le riunioni si fanno, i report girano, i task sono tracciati. Ma le decisioni continuano a passare dalla stessa persona di prima, perché chi è entrato non ha mandato reale: gestisce la superficie, non la sostanza.",[12,1327,1328],{},"Risultato:",[1298,1330,1331,1334,1337],{},[1301,1332,1333],{},"la persona centrale continua a decidere tutto",[1301,1335,1336],{},"in più deve aggiornare qualcun altro",[1301,1338,1339],{},"chi è entrato capisce di non contare davvero e si adatta o se ne va",[12,1341,1342],{},"È peggio di prima. Hai aggiunto overhead senza togliere il collo di bottiglia.",[30,1344,1346],{"id":1345},"delegare-davvero-è-scomodo","Delegare davvero è scomodo",[12,1348,1349],{},"Uscire da questa situazione è difficile per un motivo semplice: richiede fare cose contro-intuitive.",[12,1351,1352],{},"La prima è smettere di delegare quello che pesa di più e iniziare da quello che è più visibile. Molti partono dal codice, ed è un errore: il codice è ciò che ti tiene agganciato alla realtà. Le prime cose da lasciare sono le funzioni di coordinamento: gestione progetto, comunicazione, parte operativa del prodotto.",[12,1354,1355],{},"La seconda è accettare che chi prende in carico una funzione la farà diversamente. È qui che la maggior parte delle deleghe fallisce: se continui a correggere ogni decisione, non hai delegato, hai solo creato un passaggio in più. La delega inizia quando qualcuno prende una decisione che tu non avresti preso — ma è comunque sensata — e tu la lasci passare.",[30,1357,1359],{"id":1358},"il-punto-vero-cosa-tieni-e-cosa-molli","Il punto vero: cosa tieni e cosa molli",[12,1361,1362],{},"Non devi distribuire tutto. Devi scegliere cosa tenere. Per chi ha costruito un prodotto tecnico, la cosa più difficile da delegare è quasi sempre la guida tecnica sul core. È normale.",[12,1364,1365],{},"Tienila.",[12,1367,1368],{},"Ma tutto il resto — progetto, coordinamento, parte di prodotto — deve uscire. Altrimenti non stai proteggendo il sistema: stai solo rallentando il punto in cui smetterà di reggere.",[30,1370,876],{"id":875},[12,1372,1373,1374],{},"C’è un modo semplice per capire se hai davvero risolto il problema: per una settimana, sparisci. Non completamente — non è quello il punto. La domanda è: ",[16,1375,1376],{},"quali decisioni verrebbero rimandate al tuo ritorno?",[12,1378,1379,1380,1382],{},"Se la risposta è “quasi tutte”, sei esattamente dove eri prima. Se sono poche, stai migliorando. Se tutto va avanti tranne quello che hai deciso consapevolmente di tenere, allora l’organizzazione sta funzionando. È il ",[133,1381,574],{"href":573}," applicato alle decisioni, non solo al codice.",[30,1384,1386],{"id":1385},"il-punto-scomodo","Il punto scomodo",[12,1388,1389],{},"Se stai guidando un’azienda e hai una persona che copre tre o quattro ruoli, non sei fortunato. Sei esposto.",[12,1391,1392],{},"Finché quella persona regge, sembra tutto sotto controllo. Poi succede qualcosa di normale — ferie, stanchezza, cambio lavoro — e lì scopri che non avevi costruito un sistema: avevi costruito una dipendenza.",[12,1394,1395],{},"Il costo per sistemarlo è reale: assunzioni, affiancamento, un periodo in cui le cose rallentano. Il costo di non farlo arriva tutto insieme, e quando arriva non hai margine per gestirlo.",{"title":199,"searchDepth":200,"depth":200,"links":1397},[1398,1399,1400,1401,1402,1403,1404],{"id":1269,"depth":200,"text":1270},{"id":1285,"depth":200,"text":1286},{"id":1318,"depth":200,"text":1319},{"id":1345,"depth":200,"text":1346},{"id":1358,"depth":200,"text":1359},{"id":875,"depth":200,"text":876},{"id":1385,"depth":200,"text":1386},"2026-04-23","Se una persona sola tiene insieme tecnica, progetto e prodotto, l'organizzazione accumula un rischio che non si vede finché non esplode.","/images/blog/troppi-ruoli-una-persona-rischio.jpg",{},"/blog/2026-04-23-troppi-ruoli-una-persona-rischio",{"title":1255,"description":1406},"Troppi ruoli su una persona sola: il rischio nascosto","troppi-ruoli-una-persona-rischio","blog/2026-04-23-troppi-ruoli-una-persona-rischio",[658,659,1025,663,1415,1026,1416],"burnout","ruoli","CmlSLXqSh8HZW2B1aHBu1T9turx2H7asgaUU47sY-Vs",{"id":1419,"title":1420,"body":1421,"category":210,"date":1605,"description":1606,"extension":213,"image":1607,"meta":1608,"navigation":3,"path":1609,"published":3,"seo":1610,"seoTitle":1611,"slug":1612,"stem":1613,"tags":1614,"updated":229,"__hash__":1618},"blog/blog/2026-04-21-outsourcing-software-low-cost.md","Outsourcing software in India: perché finisce quasi sempre male",{"type":9,"value":1422,"toc":1594},[1423,1428,1431,1437,1440,1444,1451,1458,1462,1465,1468,1472,1475,1478,1484,1488,1491,1497,1507,1510,1514,1517,1520,1528,1532,1535,1539,1542,1548,1551,1554,1568,1572,1579,1583,1586,1591],[12,1424,1425],{},[16,1426,1427],{},"\"Abbiamo trovato un team in India che fa lo stesso lavoro a un terzo del costo.\"",[12,1429,1430],{},"L'outsourcing software low-cost — con l'India in testa, ma non solo — è una tentazione ricorrente: negli ultimi vent'anni, questa frase ha dato il via a centinaia di progetti. Molti sono partiti con entusiasmo. Molti, dopo un anno, si sono ritrovati con codice che \"funziona\" ma che nessuno riesce più a toccare senza rompere qualcosa.",[12,1432,1433,1434,103],{},"È un problema di ",[16,1435,1436],{},"modello organizzativo",[12,1438,1439],{},"Il modello delle software farm low-cost è costruito per produrre tanto codice, in poco tempo, al costo più basso possibile. Funziona bene quando il problema è scrivere task. Funziona molto meno quando il problema è rappresentare fedelmente il tuo business, far evolvere il software nel tempo e mantenerlo sano per anni.",[30,1441,1443],{"id":1442},"come-funziona-davvero-il-modello","Come funziona davvero il modello",[12,1445,1446,1447,1450],{},"Lo schema è quasi sempre lo stesso. L'azienda vuole ridurre i costi di sviluppo, si affida a una software farm con molti sviluppatori, la comunicazione passa attraverso uno o due project manager, il team tecnico è numeroso, junior e intercambiabile, e l'incentivo principale diventa ",[16,1448,1449],{},"chiudere ticket velocemente",", non capire il problema a fondo.",[12,1452,1453,1454,1457],{},"Questo modello ha senso industriale. È pensato per scalare. Ma ha un effetto collaterale enorme: il codice prodotto è ",[16,1455,1456],{},"scollegato dal contesto reale del tuo business",". E quando il codice è scollegato dal contesto, diventa fragile.",[30,1459,1461],{"id":1460},"il-vero-ostacolo-è-la-comunicazione","Il vero ostacolo è la comunicazione",[12,1463,1464],{},"Quando lavori con un team a migliaia di chilometri di distanza, con poche ore di sovrapposizione e una comunicazione mediata da documenti e task, succede una cosa prevedibile: le sfumature si perdono. Le conversazioni veloci diventano thread di email, i chiarimenti immediati diventano messaggi che ricevono risposta il giorno dopo, i requisiti vengono interpretati alla lettera e non nel loro intento. Nessuna malafede: è la conseguenza naturale del contesto.",[12,1466,1467],{},"Nel software, però, un requisito frainteso non produce una piccola differenza. Produce un comportamento completamente diverso da quello che ti aspettavi.",[30,1469,1471],{"id":1470},"il-fuso-orario-impedisce-la-collaborazione-vera","Il fuso orario impedisce la collaborazione vera",[12,1473,1474],{},"Quando il tuo team lavora mentre tu dormi, e tu lavori mentre loro dormono, la collaborazione diventa asincrona forzata.",[12,1476,1477],{},"Scompaiono le sessioni di analisi fatte bene, le discussioni architetturali spontanee e i chiarimenti rapidi sulle decisioni ambigue. Resta uno scambio di documenti e ticket. Il software, però, nasce bene dal confronto continuo, non da una catena di passaggi intermedi.",[12,1479,1480,1481,103],{},"Questo non rallenta solo il progetto. Peggio: ",[16,1482,1483],{},"impedisce al team di capire davvero cosa sta costruendo",[30,1485,1487],{"id":1486},"il-vero-problema-nessuno-possiede-il-codice","Il vero problema: nessuno possiede il codice",[12,1489,1490],{},"Nelle software farm low-cost, il turnover è spesso alto. Le persone cambiano progetto, cliente, azienda. Dopo sei mesi, chi ha scritto quel modulo potrebbe non esserci più. Dopo un anno, può capitare che nessuno del team originale sia ancora sul progetto.",[12,1492,1493,1494,1496],{},"Il codice resta. La conoscenza no. È il problema del ",[133,1495,574],{"href":573}," portato all'estremo.",[12,1498,1499,1500,1506],{},"È una versione amplificata del problema descritto in ",[133,1501,1503],{"href":1502},"/blog/aggiungere-sviluppatori-progetto",[960,1504,1505],{},"The Mythical Man-Month",": aggiungere persone non crea comprensione, crea frammentazione.",[12,1508,1509],{},"Quando quel software passa in mano a un nuovo team — interno o esterno — sembra scritto da qualcuno che non conosceva il tuo business. Perché, di fatto, è così.",[30,1511,1513],{"id":1512},"perché-allinizio-sembra-funzionare","Perché all'inizio sembra funzionare",[12,1515,1516],{},"Nei primi mesi tutto fila liscio: le feature arrivano, i ticket si chiudono, il costo è contenuto. Sembra una scelta brillante.",[12,1518,1519],{},"Il problema emerge dopo, quando devi fare modifiche non previste, il business cambia oppure serve aggiungere una logica nuova che interagisce con quelle esistenti. È lì che scopri che il codice è una somma di task chiusi, non un sistema pensato per evolvere. E ogni modifica diventa un rischio.",[12,1521,1522,1523],{},"È il momento in cui inizi a dire:\n",[133,1524,1525],{"href":1081},[16,1526,1527],{},"\"Ogni volta che tocchiamo qualcosa, si rompe qualcos'altro.\"",[30,1529,1531],{"id":1530},"un-problema-di-incentivi-non-di-geografia","Un problema di incentivi, non di geografia",[12,1533,1534],{},"Il modello non è esclusivo dell'India: esiste ovunque il lavoro venga organizzato con tanti sviluppatori intercambiabili, poca ownership, comunicazione filtrata e focus sulla velocità più che sulla comprensione — dall'Europa dell'est al Sud-est asiatico. Il risultato tende a essere sempre lo stesso: codice che fa quello che c'è scritto nel ticket, ma non quello che serve davvero al business.",[30,1536,1538],{"id":1537},"perché-oggi-questo-modello-ha-ancora-meno-senso","Perché oggi questo modello ha ancora meno senso",[12,1540,1541],{},"Per vent'anni, il vantaggio competitivo delle software farm low-cost era semplice:",[1543,1544,1545],"blockquote",{},[12,1546,1547],{},"tanto codice a basso prezzo.",[12,1549,1550],{},"Anche accettando inefficienze e fragilità architetturale, il conto tornava. Perché il collo di bottiglia era sempre lo stesso: servivano tante ore uomo per scrivere codice.",[12,1552,1553],{},"Oggi questo presupposto sta saltando: strumenti come Claude Code o Codex producono codice in minuti, senza fuso orario, senza incomprensioni linguistiche e a un costo marginale quasi nullo.",[12,1555,1556,1557,1560,1561,1567],{},"Il valore si è spostato: da ",[16,1558,1559],{},"chi scrive il codice al prezzo più basso"," a ",[133,1562,1564],{"href":1563},"/blog/ai-impatto-business-software",[16,1565,1566],{},"chi sa decidere cosa scrivere, come strutturarlo e come farlo evolvere",". Ed è esattamente la parte che il modello low-cost non copre.",[30,1569,1571],{"id":1570},"il-paradosso-umano","Il paradosso umano",[12,1573,1574,1575,1578],{},"C'è un paradosso che vale la pena riconoscere. Per anni questo modello ha funzionato perché il mercato chiedeva quantità di codice, e moltissimi sviluppatori hanno lavorato esattamente per soddisfare quella richiesta. Oggi la richiesta è cambiata — da \"scrivi questo ticket\" a \"capisci questo sistema\" — e la cosa ",[16,1576,1577],{},"per cui vengono pagati"," sta perdendo valore molto velocemente.",[30,1580,1582],{"id":1581},"la-lezione-per-chi-commissiona-software","La lezione per chi commissiona software",[12,1584,1585],{},"Alla base di questo modello c'è un'idea pericolosa:",[1543,1587,1588],{},[12,1589,1590],{},"che il software sia un problema di manodopera.",[12,1592,1593],{},"Finché sembrava vera, l'outsourcing low-cost in India aveva senso economico. Oggi si vede chiaramente che il valore non era lì. Il software riguarda comprensione del business, decisioni architetturali, comunicazione continua e responsabilità sul sistema nel tempo: cose che non si possono spacchettare in ticket da mandare dall'altra parte del mondo, e oggi non si possono nemmeno delegare a un'AI.",{"title":199,"searchDepth":200,"depth":200,"links":1595},[1596,1597,1598,1599,1600,1601,1602,1603,1604],{"id":1442,"depth":200,"text":1443},{"id":1460,"depth":200,"text":1461},{"id":1470,"depth":200,"text":1471},{"id":1486,"depth":200,"text":1487},{"id":1512,"depth":200,"text":1513},{"id":1530,"depth":200,"text":1531},{"id":1537,"depth":200,"text":1538},{"id":1570,"depth":200,"text":1571},{"id":1581,"depth":200,"text":1582},"2026-04-21","Outsourcing software in India a un terzo del costo: il modello produce codice scollegato dal business, con incentivi sbagliati. E con l'AI ha ancora meno senso.","/images/blog/outsourcing-software-low-cost.jpg",{},"/blog/2026-04-21-outsourcing-software-low-cost",{"title":1420,"description":1606},"Outsourcing software India: rischi e costi nascosti","outsourcing-software-low-cost","blog/2026-04-21-outsourcing-software-low-cost",[1615,375,1616,1617,222],"outsourcing","rischi-software","qualita","AEWykOP8KGCSfFP_ZVMsctJkUIzP64BE-2BzD5c4QtU",{"id":1620,"title":1621,"body":1622,"category":1784,"date":1785,"description":1786,"extension":213,"image":1787,"meta":1788,"navigation":3,"path":1789,"published":3,"seo":1790,"seoTitle":1791,"slug":1792,"stem":1793,"tags":1794,"updated":229,"__hash__":1798},"blog/blog/2026-04-16-quanto-costa-un-software-custom.md","Quanto costa un software custom? Differenze tra 5K, 18K e 50K",{"type":9,"value":1623,"toc":1763},[1624,1630,1641,1645,1648,1653,1656,1660,1663,1666,1670,1673,1676,1679,1682,1689,1692,1696,1699,1705,1709,1712,1716,1720,1723,1727,1730,1734,1737,1741,1749,1753,1756,1760],[12,1625,1626,1629],{},[16,1627,1628],{},"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.",[12,1631,1632,1633,1636,1637,1640],{},"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 ",[16,1634,1635],{},"cosa stai comprando davvero",". E come ho scritto parlando di ",[133,1638,1639],{"href":449},"preventivo software e budget",", partire dal vincolo economico rende la conversazione molto più utile.",[30,1642,1644],{"id":1643},"cosa-compri-con-un-preventivo-da-5000-euro","Cosa compri con un preventivo da 5.000 euro",[12,1646,1647],{},"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.",[1649,1650,1652],"h3",{"id":1651},"vantaggi","Vantaggi",[12,1654,1655],{},"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.",[1649,1657,1659],{"id":1658},"limiti","Limiti",[12,1661,1662],{},"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.",[12,1664,1665],{},"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.",[30,1667,1669],{"id":1668},"cosa-compri-con-un-preventivo-da-50000-euro","Cosa compri con un preventivo da 50.000 euro",[12,1671,1672],{},"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.",[1649,1674,1652],{"id":1675},"vantaggi-1",[12,1677,1678],{},"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.",[1649,1680,1659],{"id":1681},"limiti-1",[12,1683,1684,1685,1688],{},"Naturalmente aumentano costi e tempi, cresce la dipendenza dalla qualità del fornitore e, se ",[133,1686,1687],{"href":326},"il fornitore si sfila a metà progetto",", il rischio diventa alto. Inoltre serve una fase di analisi molto più approfondita.",[12,1690,1691],{},"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.",[30,1693,1695],{"id":1694},"la-fascia-intermedia-18000-euro","La fascia intermedia: 18.000 euro",[12,1697,1698],{},"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.",[12,1700,1701,1702],{},"La domanda chiave qui è: ",[16,1703,1704],{},"quanto del tuo processo rientra davvero nello standard?",[30,1706,1708],{"id":1707},"perché-i-numeri-sono-così-diversi","Perché i numeri sono così diversi",[12,1710,1711],{},"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.",[30,1713,1715],{"id":1714},"le-domande-da-farsi-prima-di-scegliere","Le domande da farsi prima di scegliere",[1649,1717,1719],{"id":1718},"il-tuo-processo-è-standard-o-specifico","Il tuo processo è standard o specifico?",[12,1721,1722],{},"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.",[1649,1724,1726],{"id":1725},"quanto-cambierà-il-tuo-business-nei-prossimi-due-anni","Quanto cambierà il tuo business nei prossimi due anni?",[12,1728,1729],{},"Se prevedi cambiamenti frequenti, la flessibilità diventa un fattore importante. Se il tuo modello è stabile, puoi privilegiare rapidità e costo.",[1649,1731,1733],{"id":1732},"quanto-valore-genera-questo-software","Quanto valore genera questo software?",[12,1735,1736],{},"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.",[1649,1738,1740],{"id":1739},"quanto-ti-costerà-cambiare-soluzione-in-futuro","Quanto ti costerà cambiare soluzione in futuro?",[12,1742,1743,1744,1748],{},"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 ",[133,1745,1747],{"href":1746},"/blog/costi-manutenzione-software","i costi di manutenzione software"," pesano spesso più del costo iniziale.",[30,1750,1752],{"id":1751},"lerrore-più-comune","L’errore più comune",[12,1754,1755],{},"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.",[30,1757,1759],{"id":1758},"in-sintesi","In sintesi",[12,1761,1762],{},"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":199,"searchDepth":200,"depth":200,"links":1764},[1765,1770,1774,1775,1776,1782,1783],{"id":1643,"depth":200,"text":1644,"children":1766},[1767,1769],{"id":1651,"depth":1768,"text":1652},3,{"id":1658,"depth":1768,"text":1659},{"id":1668,"depth":200,"text":1669,"children":1771},[1772,1773],{"id":1675,"depth":1768,"text":1652},{"id":1681,"depth":1768,"text":1659},{"id":1694,"depth":200,"text":1695},{"id":1707,"depth":200,"text":1708},{"id":1714,"depth":200,"text":1715,"children":1777},[1778,1779,1780,1781],{"id":1718,"depth":1768,"text":1719},{"id":1725,"depth":1768,"text":1726},{"id":1732,"depth":1768,"text":1733},{"id":1739,"depth":1768,"text":1740},{"id":1751,"depth":200,"text":1752},{"id":1758,"depth":200,"text":1759},"Architettura","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.","/images/blog/quanto-costa-un-software-custom.jpg",{},"/blog/2026-04-16-quanto-costa-un-software-custom",{"title":1621,"description":1786},"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",[1247,1248,1795,1796,1797],"software custom","scelta fornitore","costi","cWV8i-T8qBWycy0ceo7FtACkcigSDcNvqSi0LdZmXdc",{"id":1800,"title":1801,"body":1802,"category":1784,"date":1916,"description":1917,"extension":213,"image":1918,"meta":1919,"navigation":3,"path":1920,"published":3,"seo":1921,"seoTitle":1922,"slug":1923,"stem":1924,"tags":1925,"updated":229,"__hash__":1930},"blog/blog/2026-04-14-digitalizzare-processi-aziendali.md","Digitalizzare i processi aziendali: prima fai ordine, poi il software",{"type":9,"value":1803,"toc":1903},[1804,1810,1813,1817,1823,1826,1829,1833,1837,1840,1844,1847,1851,1854,1858,1864,1870,1874,1881,1884,1888,1891,1895,1898,1900],[12,1805,1806,1809],{},[16,1807,1808],{},"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.",[12,1811,1812],{},"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.",[30,1814,1816],{"id":1815},"il-software-è-uno-specchio","Il software è uno specchio",[12,1818,1819,1820],{},"C’è una verità poco comoda: ",[16,1821,1822],{},"il software amplifica i problemi organizzativi, rendendoli più evidenti e più rigidi.",[12,1824,1825],{},"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.",[12,1827,1828],{},"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.",[30,1830,1832],{"id":1831},"segnali-che-il-problema-sta-a-monte-del-software","Segnali che il problema sta a monte del software",[1649,1834,1836],{"id":1835},"ci-servono-molte-eccezioni","“Ci servono molte eccezioni”",[12,1838,1839],{},"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.",[1649,1841,1843],{"id":1842},"non-riesco-a-spiegarti-come-funziona","“Non riesco a spiegarti come funziona”",[12,1845,1846],{},"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.",[1649,1848,1850],{"id":1849},"ogni-cliente-è-un-caso-a-sé","“Ogni cliente è un caso a sé”",[12,1852,1853],{},"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.",[30,1855,1857],{"id":1856},"cosa-succede-quando-digitalizzi-il-caos","Cosa succede quando digitalizzi il caos",[12,1859,1860,1861,103],{},"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 ",[133,1862,1863],{"href":1081},"fragile e ogni deploy, cioè ogni rilascio di una nuova versione, diventa fonte di tensione",[12,1865,1866,1867,103],{},"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 ",[133,1868,1869],{"href":1104},"costruire qualcosa di semplice è già di per sé la cosa più difficile",[30,1871,1873],{"id":1872},"prima-organizzi-poi-digitalizzi","Prima organizzi, poi digitalizzi",[12,1875,1876,1877,1880],{},"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 ",[133,1878,1879],{"href":301},"le stime di sviluppo sono spesso sbagliate",": senza regole chiare, non si può stimare nulla con precisione.",[12,1882,1883],{},"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.",[30,1885,1887],{"id":1886},"il-ruolo-di-chi-progetta-il-software","Il ruolo di chi progetta il software",[12,1889,1890],{},"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.",[30,1892,1894],{"id":1893},"una-checklist-pratica","Una checklist pratica",[12,1896,1897],{},"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.",[30,1899,1759],{"id":1758},[12,1901,1902],{},"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":199,"searchDepth":200,"depth":200,"links":1904},[1905,1906,1911,1912,1913,1914,1915],{"id":1815,"depth":200,"text":1816},{"id":1831,"depth":200,"text":1832,"children":1907},[1908,1909,1910],{"id":1835,"depth":1768,"text":1836},{"id":1842,"depth":1768,"text":1843},{"id":1849,"depth":1768,"text":1850},{"id":1856,"depth":200,"text":1857},{"id":1872,"depth":200,"text":1873},{"id":1886,"depth":200,"text":1887},{"id":1893,"depth":200,"text":1894},{"id":1758,"depth":200,"text":1759},"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":1801,"description":1917},"Digitalizzazione processi aziendali: prima ordine, poi software","digitalizzare-processi-aziendali","blog/2026-04-14-digitalizzare-processi-aziendali",[1926,1927,1928,1026,1929],"digitalizzazione","processi-aziendali","analisi-requisiti","preparazione-progetto","yS3XLcEhoT8qwIQP2OktjN1AoFGaxANf3rhw23_5vq4",{"id":1932,"title":1933,"body":1934,"category":1784,"date":2047,"description":2048,"extension":213,"image":2049,"meta":2050,"navigation":3,"path":2051,"published":3,"seo":2052,"seoTitle":2053,"slug":2054,"stem":2055,"tags":2056,"updated":229,"__hash__":2060},"blog/blog/2026-04-09-semplicita-nel-software.md","Semplicità nel software: perché costa più di quanto sembri",{"type":9,"value":1935,"toc":2036},[1936,1942,1945,1949,1953,1960,1963,1967,1970,1973,1980,1984,1990,1993,1997,2000,2008,2012,2015,2018,2021,2024,2028,2031,2033],[12,1937,1938,1941],{},[16,1939,1940],{},"\"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.",[12,1943,1944],{},"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.",[30,1946,1948],{"id":1947},"perché-semplice-è-una-richiesta-costosa","Perché “semplice” è una richiesta costosa",[1649,1950,1952],{"id":1951},"dietro-ogni-click-ci-sono-molte-decisioni","Dietro ogni click ci sono molte decisioni",[12,1954,1955,1956,1959],{},"Quando l’utente preme un bottone e “succede tutto”, la complessità è stata spostata dietro le quinte. Ogni scelta che l’utente ",[16,1957,1958],{},"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à.",[12,1961,1962],{},"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.",[1649,1964,1966],{"id":1965},"togliere-richiede-capire-aggiungere-richiede-soprattutto-implementare","Togliere richiede capire. Aggiungere richiede soprattutto implementare.",[12,1968,1969],{},"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.",[12,1971,1972],{},"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.",[12,1974,1975,1976,1979],{},"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 ",[133,1977,1978],{"href":301},"le stime di sviluppo sono spesso imprecise",": la complessità sta nelle decisioni, prima che nel codice.",[30,1981,1983],{"id":1982},"il-paradosso-della-semplicità","Il paradosso della semplicità",[12,1985,1986,1987,103],{},"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 ",[133,1988,1989],{"href":418},"scope creep",[12,1991,1992],{},"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.",[30,1994,1996],{"id":1995},"semplice-e-subito-raramente-convivono","“Semplice” e “subito” raramente convivono",[12,1998,1999],{},"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.",[12,2001,2002,2003,2007],{},"La soluzione più onesta, di solito, è: partire con poco, farlo funzionare bene, e semplificare in iterazioni successive. È la logica del ",[133,2004,2006],{"href":2005},"/blog/quando-lanciare-un-prodotto","lanciare presto e migliorare",", applicata alla UX: le prime versioni devono essere affidabili, poi diventano davvero semplici.",[30,2009,2011],{"id":2010},"come-si-costruisce-davvero-la-semplicità","Come si costruisce davvero la semplicità",[12,2013,2014],{},"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?",[12,2016,2017],{},"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.",[12,2019,2020],{},"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.",[12,2022,2023],{},"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.",[30,2025,2027],{"id":2026},"euristiche-pratiche-per-chi-commissiona-software","Euristiche pratiche per chi commissiona software",[12,2029,2030],{},"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.",[30,2032,1759],{"id":1758},[12,2034,2035],{},"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":199,"searchDepth":200,"depth":200,"links":2037},[2038,2042,2043,2044,2045,2046],{"id":1947,"depth":200,"text":1948,"children":2039},[2040,2041],{"id":1951,"depth":1768,"text":1952},{"id":1965,"depth":1768,"text":1966},{"id":1982,"depth":200,"text":1983},{"id":1995,"depth":200,"text":1996},{"id":2010,"depth":200,"text":2011},{"id":2026,"depth":200,"text":2027},{"id":1758,"depth":200,"text":1759},"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":1933,"description":2048},"Semplicità nel software: perché costa più di quanto pensi","semplicita-nel-software","blog/2026-04-09-semplicita-nel-software",[2057,2058,2059,829,227],"prodotto","user-experience","analisi","TEJb1i3ts1_Al_dhaBaqgVW-fJLS-IubVFL0YUe22Ak",{"id":2062,"title":2063,"body":2064,"category":1784,"date":2188,"description":2189,"extension":213,"image":2190,"meta":2191,"navigation":3,"path":2192,"published":3,"seo":2193,"seoTitle":2194,"slug":2195,"stem":2196,"tags":2197,"updated":229,"__hash__":2199},"blog/blog/2026-04-07-codice-perfetto-vs-pragmatico.md","Codice perfetto vs pragmatico: quando migliorare il codice ha senso",{"type":9,"value":2065,"toc":2175},[2066,2072,2075,2079,2082,2085,2088,2092,2099,2103,2106,2109,2113,2117,2120,2123,2127,2135,2139,2142,2146,2149,2153,2161,2165,2172],[12,2067,2068,2071],{},[16,2069,2070],{},"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.",[12,2073,2074],{},"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.",[30,2076,2078],{"id":2077},"il-software-è-uno-strumento","Il software è uno strumento",[12,2080,2081],{},"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.",[12,2083,2084],{},"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.",[12,2086,2087],{},"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.",[30,2089,2091],{"id":2090},"quando-la-qualità-diventa-un-costo","Quando la qualità diventa un costo",[12,2093,2094,2095,2098],{},"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 ",[133,2096,2097],{"href":1089},"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.",[30,2100,2102],{"id":2101},"il-punto-non-è-scrivere-codice-brutto","Il punto non è scrivere codice brutto",[12,2104,2105],{},"“Meglio un codice brutto che funziona” è una frase pericolosa se presa alla lettera.",[12,2107,2108],{},"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.",[30,2110,2112],{"id":2111},"le-situazioni-in-cui-si-sbaglia-più-spesso","Le situazioni in cui si sbaglia più spesso",[1649,2114,2116],{"id":2115},"il-refactoring-non-richiesto","Il refactoring non richiesto",[12,2118,2119],{},"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.",[12,2121,2122],{},"Il codice che funziona in produzione da tempo è già stato testato dal caso reale. Cambiarlo senza una motivazione di business è spesso un rischio inutile.",[1649,2124,2126],{"id":2125},"lastrazione-prematura","L’astrazione prematura",[12,2128,2129,2130,2134],{},"Si introduce un pattern o un livello di astrazione pensando a futuri scenari che, nella pratica, non si presentano. I ",[133,2131,2133],{"href":2132},"/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.",[1649,2136,2138],{"id":2137},"le-ottimizzazioni-premature","Le ottimizzazioni premature",[12,2140,2141],{},"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.",[30,2143,2145],{"id":2144},"le-euristiche-pratiche-quando-fermarsi-e-quando-no","Le euristiche pratiche: quando fermarsi e quando no",[12,2147,2148],{},"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.",[30,2150,2152],{"id":2151},"il-concetto-di-abbastanza-buono","Il concetto di “abbastanza buono”",[12,2154,2155,2156,2160],{},"“Abbastanza buono” non significa mediocrità. Significa proporzionare lo sforzo al valore: nomi chiari anche se non impeccabili, una struttura leggibile senza rigidità accademiche, ",[133,2157,2159],{"href":2158},"/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.",[30,2162,2164],{"id":2163},"per-chi-decide","Per chi decide",[12,2166,2167,2168,2171],{},"Se il tuo team consegna in ritardo ma il codice è sempre “impeccabile”, vale la pena fare una domanda semplice: ",[16,2169,2170],{},"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.",[12,2173,2174],{},"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":199,"searchDepth":200,"depth":200,"links":2176},[2177,2178,2179,2180,2185,2186,2187],{"id":2077,"depth":200,"text":2078},{"id":2090,"depth":200,"text":2091},{"id":2101,"depth":200,"text":2102},{"id":2111,"depth":200,"text":2112,"children":2181},[2182,2183,2184],{"id":2115,"depth":1768,"text":2116},{"id":2125,"depth":1768,"text":2126},{"id":2137,"depth":1768,"text":2138},{"id":2144,"depth":200,"text":2145},{"id":2151,"depth":200,"text":2152},{"id":2163,"depth":200,"text":2164},"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":2063,"description":2189},"Codice perfetto vs pragmatico: trovare il giusto equilibrio","codice-perfetto-vs-pragmatico","blog/2026-04-07-codice-perfetto-vs-pragmatico",[226,2198,2057,1617,829],"pragmatismo","r6lmHuh9TqImpTGbMQQBzMNV8n5_bHdw2n8vAmFFwA4",{"id":2201,"title":2202,"body":2203,"category":210,"date":2341,"description":2342,"extension":213,"image":2343,"meta":2344,"navigation":3,"path":2345,"published":3,"seo":2346,"seoTitle":2347,"slug":2348,"stem":2349,"tags":2350,"updated":229,"__hash__":2356},"blog/blog/2026-04-02-budget-software-go-to-market.md","Hai speso tutto il budget nel prodotto. E nessuno sa che esiste",{"type":9,"value":2204,"toc":2328},[2205,2211,2214,2218,2221,2224,2227,2231,2237,2240,2247,2251,2254,2258,2264,2271,2275,2282,2286,2293,2297,2300,2304,2307,2311,2314,2317,2321],[12,2206,2207,2210],{},[16,2208,2209],{},"Il prodotto è pronto. Funziona, è curato, è stato testato. Mesi di sviluppo, budget importante investito."," Poi arriva il momento del lancio e ci si rende conto che non esiste un vero piano per farlo conoscere. Concentrare tutto il budget nello sviluppo software e trascurare il go-to-market, cioè tutto ciò che serve per portare il prodotto davanti alle persone giuste, è un errore comune: il risultato è un prodotto valido che non genera utenti, perché nessuno sa che esiste.",[12,2212,2213],{},"È un errore molto comune per chi ha un background tecnico: concentrare quasi tutto il budget sullo sviluppo e considerare il go-to-market come qualcosa da affrontare “dopo”. Il problema è che, quando arriva il “dopo”, spesso le risorse sono finite.",[30,2215,2217],{"id":2216},"il-prodotto-non-si-vende-da-solo","Il prodotto non si vende da solo",[12,2219,2220],{},"C’è un’idea diffusa nella cultura tech: se il prodotto è buono, prima o poi i clienti arrivano. Nella pratica succede raramente.",[12,2222,2223],{},"Un prodotto compete per attenzione in un mercato saturo. Le persone non stanno aspettando che tu lanci qualcosa: stanno già usando alternative, magari peggiori, ma che conoscono. Farsi trovare, spiegare il valore, portare traffico qualificato richiede tempo, competenze e budget.",[12,2225,2226],{},"Se tutto il budget è stato assorbito dallo sviluppo, questa fase diventa improvvisata. Ed è qui che molti progetti si fermano.",[30,2228,2230],{"id":2229},"la-regola-controintuitiva","La regola controintuitiva",[12,2232,2233,2234,103],{},"Se non hai ancora clienti, ",[16,2235,2236],{},"il budget per far conoscere il prodotto è strategicamente più importante del budget per aggiungere nuove feature",[12,2238,2239],{},"Un prodotto con poche funzionalità ma con un piano di acquisizione utenti può iniziare a generare feedback e ricavi. Quei ricavi finanziano l’evoluzione del prodotto.",[12,2241,2242,2243,2246],{},"Un prodotto ricco di funzionalità ma senza utenti genera solo ",[133,2244,2245],{"href":1746},"costi di manutenzione"," e nessun apprendimento dal mercato.",[30,2248,2250],{"id":2249},"come-ragionare-sulla-divisione-del-budget","Come ragionare sulla divisione del budget",[12,2252,2253],{},"Non esiste una formula universale, ma questo schema funziona in molti contesti digitali.",[1649,2255,2257],{"id":2256},"quando-non-hai-ancora-clienti","Quando non hai ancora clienti",[12,2259,2260,2261,103],{},"Indicativamente: ",[16,2262,2263],{},"40% prodotto, 60% go-to-market e validazione",[12,2265,2266,2267,2270],{},"In questa fase l’obiettivo è dimostrare che qualcuno è disposto a usare (o pagare) ciò che stai costruendo, anche con poche feature. Il prodotto deve essere ",[133,2268,2269],{"href":2005},"piccolo ma solido",". Il resto del budget serve a raggiungere le persone giuste e capire se il problema che vuoi risolvere è reale.",[1649,2272,2274],{"id":2273},"quando-hai-già-clienti-interessati","Quando hai già clienti interessati",[12,2276,2277,2278,2281],{},"Puoi spostarti verso ",[16,2279,2280],{},"60% prodotto, 40% go-to-market",". Hai già un segnale di domanda, quindi ha senso investire di più nel soddisfarla, continuando però a mantenere attenzione su comunicazione e acquisizione.",[1649,2283,2285],{"id":2284},"quando-hai-già-traction","Quando hai già traction",[12,2287,2288,2289,2292],{},"Un punto di partenza ragionevole è ",[16,2290,2291],{},"50/50",", poi la distribuzione si adatta in base ai dati. Qui traction significa che il prodotto ha già mostrato segnali concreti di risposta dal mercato: utenti, richieste, vendite, interesse reale. Se il traffico è poco ma chi arriva converte, conviene investire di più nel marketing; se il traffico è alto ma pochi convertono, significa che il lavoro da fare è soprattutto sul prodotto.",[30,2294,2296],{"id":2295},"il-segnale-che-stai-sbagliando-allocazione","Il segnale che stai sbagliando allocazione",[12,2298,2299],{},"Ci sono alcuni segnali ricorrenti: hai molte feature ma pochi utenti attivi, nessuno nel team si occupa in modo strutturato di acquisizione e comunicazione, il lancio è stato un post sui social e poco altro, oppure stai pensando di aggiungere nuove funzionalità prima ancora di aver capito perché le persone non usano quelle che già ci sono. In questi casi il problema riguarda quasi sempre visibilità e comprensione del mercato, molto prima di una feature mancante.",[30,2301,2303],{"id":2302},"validare-prima-di-costruire","Validare prima di costruire",[12,2305,2306],{},"Spesso si può fare molto prima ancora di scrivere codice. Una landing page chiara con una proposta di valore e un piccolo budget in advertising permette già di capire se il messaggio genera interesse. Una lista d’attesa raccoglie email e dà un primo segnale di domanda. Una pre-vendita o anche solo una demo ben condotta ti dice qualcosa di ancora più importante: se qualcuno è disposto a pagare o a impegnarsi prima che il prodotto sia completo. Tutte queste attività costano molto meno dello sviluppo e riducono il rischio di costruire qualcosa che il mercato non sta cercando.",[30,2308,2310],{"id":2309},"il-bias-di-chi-viene-dal-tech","Il bias di chi viene dal tech",[12,2312,2313],{},"Per chi viene dallo sviluppo, investire nel prodotto è naturale: è la zona di comfort. Ogni nuova feature è un risultato tangibile. Il marketing invece è incerto, meno misurabile nel breve periodo e quindi spesso rimandato.",[12,2315,2316],{},"Ma una feature senza utenti non genera valore. Un esperimento di acquisizione, anche se non funziona, genera dati utili per decidere meglio cosa costruire.",[30,2318,2320],{"id":2319},"una-scelta-strategica-non-operativa","Una scelta strategica, non operativa",[12,2322,2323,2324,2327],{},"Ogni euro speso in sviluppo è un euro non speso in acquisizione: è a tutti gli effetti una decisione di business. ",[133,2325,2326],{"href":1563},"L’AI sta riducendo il costo di sviluppo",", e questo rende ancora più evidente un punto: costruire è sempre meno il collo di bottiglia, raggiungere le persone giuste lo è sempre di più. Un prodotto valido che nessuno conosce resta un progetto ben fatto, ma isolato dal mercato.",{"title":199,"searchDepth":200,"depth":200,"links":2329},[2330,2331,2332,2337,2338,2339,2340],{"id":2216,"depth":200,"text":2217},{"id":2229,"depth":200,"text":2230},{"id":2249,"depth":200,"text":2250,"children":2333},[2334,2335,2336],{"id":2256,"depth":1768,"text":2257},{"id":2273,"depth":1768,"text":2274},{"id":2284,"depth":1768,"text":2285},{"id":2295,"depth":200,"text":2296},{"id":2302,"depth":200,"text":2303},{"id":2309,"depth":200,"text":2310},{"id":2319,"depth":200,"text":2320},"2026-04-02","Un prodotto ottimo che nessuno conosce resta isolato dal mercato. Come distribuire il budget tra sviluppo e go-to-market a seconda della fase del prodotto.","/images/blog/budget-software-go-to-market.jpg",{},"/blog/2026-04-02-budget-software-go-to-market",{"title":2202,"description":2342},"Budget sviluppo software vs go-to-market: come distribuirlo","budget-software-go-to-market","blog/2026-04-02-budget-software-go-to-market",[2351,2352,2353,2354,2355],"budget-startup","go-to-market","lancio-prodotto","validazione-mercato","pianificazione","JJkXzGwl1y64IBMDLH3xXPjQsVlNUjmv1K6Pk_KeO9U",{"id":2358,"title":2359,"body":2360,"category":210,"date":2507,"description":2508,"extension":213,"image":2509,"meta":2510,"navigation":3,"path":2511,"published":3,"seo":2512,"seoTitle":2513,"slug":2514,"stem":2515,"tags":2516,"updated":229,"__hash__":2520},"blog/blog/2026-03-31-quando-lanciare-un-prodotto.md","Quando lanciare un prodotto: meglio piccolo e funzionante che perfetto",{"type":9,"value":2361,"toc":2497},[2362,2368,2372,2382,2388,2395,2398,2402,2405,2408,2412,2415,2418,2421,2424,2428,2436,2440,2450,2457,2464,2468,2471,2475,2478,2484,2488,2491,2494],[12,2363,2364,2367],{},[16,2365,2366],{},"Capita spesso di vedere team che costruiscono per mesi un prodotto \"completo\", aggiungendo funzionalità una dopo l'altra, prima di mostrarlo a utenti reali."," Lanciare un MVP, cioè una prima versione piccola ma già usabile, prima di avere tutto pronto sembra rischioso, ma è l'opposto: il vero rischio è scoprire troppo tardi che il mercato voleva altro. Poi arriva il lancio e la realtà è brutale: alcune cose vengono ignorate, e le parti più usate non sono quelle su cui era stato investito di più. Il problema è costruire troppo a lungo senza verificare se il problema è davvero quello giusto, per le persone giuste.",[30,2369,2371],{"id":2370},"la-perfezione-è-il-nemico-del-lancio","La perfezione è il nemico del lancio",[12,2373,2374,2375,2378,2379,103],{},"C’è una differenza fondamentale tra un prodotto ",[16,2376,2377],{},"incompleto"," e un prodotto ",[16,2380,2381],{},"difettoso",[12,2383,2384,2385,103],{},"Un prodotto difettoso è lento, instabile, perde dati, ha bug nei flussi principali. Questo non va bene, indipendentemente dalla fase. E infatti ",[133,2386,2387],{"href":277},"un MVP non è una scusa per rilasciare software rotto",[12,2389,2390,2391,2394],{},"Un prodotto incompleto fa poche cose, ma le fa ",[16,2392,2393],{},"bene",". Mancano feature, manca personalizzazione, manca “comodità”. Ma il nucleo del valore è usabile, affidabile e comprensibile.",[12,2396,2397],{},"Molti team confondono le due cose: temono di essere giudicati per ciò che manca e finiscono per rimandare il lancio. Il rischio vero però è un altro: scoprire troppo tardi di aver costruito qualcosa che non corrisponde a un bisogno reale.",[30,2399,2401],{"id":2400},"il-feedback-è-utile-solo-se-arriva-presto","Il feedback è utile solo se arriva presto",[12,2403,2404],{},"Interviste, benchmark e analisi competitor aiutano. Ma non sostituiscono ciò che succede quando un utente reale prova il prodotto nel suo contesto.",[12,2406,2407],{},"Quando lanci presto, purché il nucleo abbia qualità, scopri cose che raramente emergono in fase di pianificazione. Ti accorgi che la funzionalità considerata “secondaria” è quella che genera davvero valore, che un passaggio del flusso è confuso e blocca la conversione, che l’utente descrive il problema in modo diverso da come lo avevi modellato e che la priorità reale non era aggiungere feature ma semplificare il percorso. Sono scoperte che cambiano la roadmap, e più arrivano presto meno lavoro rischi di buttare via.",[30,2409,2411],{"id":2410},"il-ciclo-lancia-misura-impara-migliora","Il ciclo: lancia, misura, impara, migliora",[12,2413,2414],{},"È un modo pratico di ridurre il rischio e di sostituire le ipotesi con segnali reali. La prima mossa è lanciare la versione minima che porta valore: “minima” non vuol dire “tirata via”, vuol dire identificare il nucleo del valore. Se stai costruendo un tool di prenotazione, il nucleo è che un utente possa prenotare e tu riceva la prenotazione in modo affidabile; reportistica avanzata, automazioni e personalizzazioni possono arrivare dopo.",[12,2416,2417],{},"Subito dopo devi mettere utenti veri davanti al prodotto. Meglio pochi utenti reali e coinvolti, che pagano o avrebbero un motivo concreto per usarlo, che cento curiosi. Il feedback di chi non ha nulla in gioco tende a essere rumoroso.",[12,2419,2420],{},"Poi conviene misurare cosa fanno, non solo cosa dicono. Le richieste del tipo “ci serve la feature X” spesso sono una soluzione proposta dall’utente, non il problema. Le metriche comportamentali dicono molto di più: dove si blocca il flusso, dove abbandonano, quali schermate usano davvero, quali passaggi richiedono supporto.",[12,2422,2423],{},"Infine si migliora in base a evidenze. Ogni iterazione dovrebbe rispondere a qualcosa che hai osservato, che sia un dato o un feedback ripetuto, e non a un’ipotesi non verificata o a un confronto estetico con il competitor.",[30,2425,2427],{"id":2426},"il-costo-del-costruiamo-tutto-e-poi-vediamo","Il costo del “costruiamo tutto e poi vediamo”",[12,2429,2430,2431,2435],{},"Un prodotto costruito per mesi senza feedback tende a produrre due costi tipici. Il primo è l’accumulo di feature inutilizzate, che però vanno mantenute, testate, supportate e spiegate: un classico caso di ",[133,2432,2434],{"href":2433},"/blog/budget-software-go-to-market","budget speso tutto nel prodotto"," senza vera validazione. Il secondo è un’architettura, insieme a una UX, modellate su ipotesi che diventano difficili da cambiare quando finalmente arriva la realtà. Il risultato è spesso una roadmap già pesante al day one, con molte parti in movimento, troppe dipendenze e poca capacità di adattamento.",[30,2437,2439],{"id":2438},"ma-il-mio-settore-vuole-un-prodotto-completo","“Ma il mio settore vuole un prodotto completo”",[12,2441,2442,2443,2446,2447,2449],{},"È un’obiezione legittima. La risposta è che dipende da ",[960,2444,2445],{},"come"," definisci “completo” e da ",[960,2448,2445],{}," gestisci le aspettative.",[12,2451,2452,2453,2456],{},"Puoi lanciare una ",[16,2454,2455],{},"versione 1"," che fa poche cose essenziali molto bene, e comunicare in modo trasparente cosa è incluso e cosa arriverà dopo. La trasparenza, in molti contesti B2B, aumenta la fiducia perché segnala che stai costruendo con metodo e ascolto, non “a intuito”.",[12,2458,2459,2460,2463],{},"Il punto è lanciare qualcosa di ",[16,2461,2462],{},"limitato ma affidabile",", con la qualità concentrata sui flussi principali.",[30,2465,2467],{"id":2466},"euristiche-pratiche-quando-sei-pronto-a-lanciare","Euristiche pratiche: quando sei pronto a lanciare",[12,2469,2470],{},"Se vuoi una regola operativa, guarda alcuni elementi minimi. Il flusso principale deve funzionare end-to-end, senza workaround e senza interventi manuali. Devi avere strumenti minimi di osservabilità, come error tracking, log e almeno una metrica di uso o attivazione. Devi sapere qual è la domanda a cui vuoi rispondere con il lancio, avere un canale di feedback e un modo ordinato per raccogliere richieste, e infine un piano semplice per iterare con una cadenza, delle priorità e qualcuno che decida. Se mancano questi punti, c’è ancora preparazione da fare.",[30,2472,2474],{"id":2473},"le-feature-che-non-sviluppi-sono-un-vantaggio","Le feature che non sviluppi sono un vantaggio",[12,2476,2477],{},"Ogni feature che non costruisci basandoti su ipotesi è codice che non devi mantenere e che non può rompersi. È complessità evitata.",[12,2479,2480,2483],{},[133,2481,2482],{"href":301},"Le stime sono spesso imprecise"," proprio perché il futuro cambia. Il ciclo iterativo non elimina l’incertezza: la rende gestibile, trasformando una scommessa grande in una serie di scommesse piccole.",[30,2485,2487],{"id":2486},"il-prodotto-si-definisce-fuori-dal-tuo-ufficio","Il prodotto si definisce fuori dal tuo ufficio",[12,2489,2490],{},"È normale avere un’idea precisa di come “dovrebbe” essere, ma finché non lo metti nelle mani di utenti reali stai indovinando.",[12,2492,2493],{},"Lancia piccolo. Lancia bene. Ascolta. Migliora. Ripeti.",[12,2495,2496],{},"È meno “epico” di un grande lancio dopo mesi di lavoro nascosto, ma riduce drasticamente il rischio di costruire la cosa sbagliata e ti evita di scoprire troppo tardi che stai andando nella direzione sbagliata.",{"title":199,"searchDepth":200,"depth":200,"links":2498},[2499,2500,2501,2502,2503,2504,2505,2506],{"id":2370,"depth":200,"text":2371},{"id":2400,"depth":200,"text":2401},{"id":2410,"depth":200,"text":2411},{"id":2426,"depth":200,"text":2427},{"id":2438,"depth":200,"text":2439},{"id":2466,"depth":200,"text":2467},{"id":2473,"depth":200,"text":2474},{"id":2486,"depth":200,"text":2487},"2026-03-31","Aspettare che il prodotto sia completo aumenta il rischio di costruire la cosa sbagliata. Come lanciare piccolo ma solido, raccogliere feedback e iterare.","/images/blog/quando-lanciare-un-prodotto.jpg",{},"/blog/2026-03-31-quando-lanciare-un-prodotto",{"title":2359,"description":2508},"Quando lanciare un prodotto: perché il lancio presto riduce il rischio","quando-lanciare-un-prodotto","blog/2026-03-31-quando-lanciare-un-prodotto",[2353,2517,2354,2518,2519],"mvp","feedback-utenti","iterazioni","5BVlCMJYeJqQlQ3Rhju5O6ZeKPdwaZWVv5Q3BRB2km4",{"id":2522,"title":2523,"body":2524,"category":210,"date":2634,"description":2635,"extension":213,"image":2636,"meta":2637,"navigation":3,"path":2638,"published":3,"seo":2639,"seoTitle":2640,"slug":2641,"stem":2642,"tags":2643,"updated":229,"__hash__":2648},"blog/blog/2026-03-26-come-assumere-sviluppatori-bravi.md","Come assumere sviluppatori bravi: perché non rispondono al tuo annuncio",{"type":9,"value":2525,"toc":2621},[2526,2532,2536,2539,2542,2546,2550,2558,2562,2569,2573,2576,2580,2583,2587,2590,2594,2597,2604,2608,2611,2614,2618],[12,2527,2528,2531],{},[16,2529,2530],{},"\"Non si trovano sviluppatori.\""," È una frase che si sente spesso. In realtà assumere sviluppatori è possibile: quelli bravi esistono, lavorano e cambiano lavoro. Molto semplicemente scelgono di andare altrove, e il motivo sta quasi sempre nella tua offerta più che nel mercato.",[30,2533,2535],{"id":2534},"il-mercato-è-competitivo-non-impossibile","Il mercato è competitivo, non impossibile",[12,2537,2538],{},"È vero: la domanda di sviluppatori supera l’offerta da anni. Ma competitivo non significa impossibile. Significa che non puoi pubblicare un annuncio generico e aspettare che arrivino curriculum qualificati.",[12,2540,2541],{},"Le aziende che assumono bene non hanno segreti particolari. Hanno offerte chiare, processi sensati e condizioni di lavoro che uno sviluppatore competente considera ragionevoli. Se una posizione resta aperta per mesi, è un segnale che qualcosa nell’offerta non funziona.",[30,2543,2545],{"id":2544},"cosa-tende-ad-allontanare-gli-sviluppatori","Cosa tende ad allontanare gli sviluppatori",[1649,2547,2549],{"id":2548},"stack-tecnologico-trascurato","Stack tecnologico trascurato",[12,2551,2552,2553,2557],{},"Uno sviluppatore competente vuole lavorare con strumenti mantenuti e con un futuro. Non serve inseguire ogni moda — farlo porta ad altri problemi, come nel caso del ",[133,2554,2556],{"href":2555},"/blog/quale-framework-javascript-scegliere","resume-driven development"," — ma c’è una differenza evidente tra uno stack stabile e moderno e uno stack lasciato indietro negli anni. Uno stack trascurato comunica che la tecnologia non è una priorità, e questo, per uno sviluppatore, è un segnale molto forte.",[1649,2559,2561],{"id":2560},"nessuna-flessibilità-presenza-obbligatoria","Nessuna flessibilità, presenza obbligatoria",[12,2563,2564,2565,2568],{},"Chiedere presenza fissa in ufficio cinque giorni su cinque è oggi un filtro che esclude molti candidati validi, per una ragione concreta: il lavoro di sviluppo richiede concentrazione profonda, e l’ufficio open space è spesso l’opposto. Ogni interruzione ha un costo cognitivo elevato, come spiegato parlando di ",[133,2566,2567],{"href":1292},"quanto costano le interruzioni",", e la richiesta di lavorare in remoto, almeno in parte, è spesso una richiesta di poter lavorare meglio.",[1649,2570,2572],{"id":2571},"processi-di-selezione-poco-realistici","Processi di selezione poco realistici",[12,2574,2575],{},"Cinque round di colloqui, test tecnici lunghi, esercizi su problemi lontani dal lavoro reale: questo tipo di processo tende a selezionare chi ha più tempo libero, non chi è più competente. Uno sviluppatore senior con un lavoro stabile spesso non partecipa a questi processi, e l’azienda non si accorge nemmeno di aver perso candidati di valore.",[1649,2577,2579],{"id":2578},"nessun-percorso-di-crescita","Nessun percorso di crescita",[12,2581,2582],{},"“Qui facciamo tutti un po’ di tutto” può sembrare positivo, ma spesso significa mancanza di specializzazione, mentoring e prospettive di crescita. Gli sviluppatori più bravi cercano contesti in cui possano migliorare nel tempo, non restare fermi allo stesso livello per anni.",[1649,2584,2586],{"id":2585},"cultura-poco-sostenibile","Cultura poco sostenibile",[12,2588,2589],{},"Frasi come “siamo una famiglia” o aspettative implicite di disponibilità continua vengono percepite come segnali di confini poco chiari tra lavoro e vita privata. Per molti sviluppatori questo è un motivo sufficiente per non candidarsi.",[30,2591,2593],{"id":2592},"cosa-attrae-gli-sviluppatori-competenti","Cosa attrae gli sviluppatori competenti",[12,2595,2596],{},"Spesso non è qualcosa di costoso. Gli sviluppatori bravi cercano problemi interessanti da risolvere, sistemi da progettare e lavori con un impatto concreto: se il tuo prodotto ha queste caratteristiche, vale la pena comunicarlo chiaramente. Cercano anche autonomia e tempo per lavorare bene, e un ambiente che protegge la concentrazione, limita le riunioni inutili e riduce le interruzioni è spesso più attrattivo di uno stipendio leggermente più alto.",[12,2598,2599,2600,2603],{},"Contano molto anche le pratiche tecniche. Non serve lo stack più trendy; serve uno stack mantenuto, con versionamento serio, code review, cioè revisione del codice da parte di altri sviluppatori, pipeline di deploy automatizzate e un minimo di ",[133,2601,2602],{"href":2158},"test automatici",". Infine c’è la trasparenza: range di stipendio, stack tecnologico, modalità di lavoro e composizione del team. Quando queste informazioni mancano dall’annuncio, molti candidati preferiscono non perdere tempo.",[30,2605,2607],{"id":2606},"cambiamenti-pratici-che-non-costano-nulla","Cambiamenti pratici che non costano nulla",[12,2609,2610],{},"Il primo cambiamento utile è riscrivere l’annuncio, sostituendo le frasi generiche con informazioni concrete: tecnologie usate, modalità di lavoro, range retributivo, tipo di prodotto, dimensione del team. Subito dopo conviene semplificare il processo di selezione: due step sono spesso sufficienti, con un colloquio tecnico conversazionale e un confronto con il team. Se ci sono test, devono essere brevi, realistici e rispettosi del tempo del candidato.",[12,2612,2613],{},"Anche il modo in cui chiudi i colloqui conta. Un rifiuto tempestivo e cortese è sempre meglio del silenzio, soprattutto in un mondo come quello tech dove il passaparola è molto veloce. E naturalmente pesa la flessibilità reale: già due o tre giorni a settimana da remoto, orari flessibili e meno interruzioni cambiano radicalmente la percezione dell’azienda.",[30,2615,2617],{"id":2616},"va-oltre-il-budget","Va oltre il budget",[12,2619,2620],{},"Stipendi competitivi aiutano, ma non sono l’unico fattore. Molte aziende che faticano ad assumere non hanno un problema di soldi: hanno un problema di proposta complessiva — ambiente, processi e cultura del lavoro. Prima di concludere che “il mercato è vuoto”, può essere utile guardare la propria offerta con gli occhi di chi dovrebbe sceglierla.",{"title":199,"searchDepth":200,"depth":200,"links":2622},[2623,2624,2631,2632,2633],{"id":2534,"depth":200,"text":2535},{"id":2544,"depth":200,"text":2545,"children":2625},[2626,2627,2628,2629,2630],{"id":2548,"depth":1768,"text":2549},{"id":2560,"depth":1768,"text":2561},{"id":2571,"depth":1768,"text":2572},{"id":2578,"depth":1768,"text":2579},{"id":2585,"depth":1768,"text":2586},{"id":2592,"depth":200,"text":2593},{"id":2606,"depth":200,"text":2607},{"id":2616,"depth":200,"text":2617},"2026-03-26","Assumere sviluppatori bravi è possibile anche in un mercato competitivo. Il problema spesso è nell'offerta: stack, flessibilità, processo di selezione.","/images/blog/come-assumere-sviluppatori-bravi.jpg",{},"/blog/2026-03-26-come-assumere-sviluppatori-bravi",{"title":2523,"description":2635},"Come assumere sviluppatori: perché non trovi i candidati giusti","come-assumere-sviluppatori-bravi","blog/2026-03-26-come-assumere-sviluppatori-bravi",[2644,2645,2646,2647,662],"assumere-sviluppatori","hiring","attrarre-talenti","processi-selezione","RBH-OY2CSlIeDkDhEjNfvyGN4VweH3E0nrv8BSfRuIY",{"id":2650,"title":2651,"body":2652,"category":210,"date":2801,"description":2802,"extension":213,"image":2803,"meta":2804,"navigation":3,"path":2805,"published":3,"seo":2806,"seoTitle":2807,"slug":2808,"stem":2809,"tags":2810,"updated":229,"__hash__":2815},"blog/blog/2026-03-24-team-tecnico-business-due-lingue.md","Comunicazione tra team tecnico e business: come ridurre le incomprensioni",{"type":9,"value":2653,"toc":2782},[2654,2660,2663,2667,2670,2674,2677,2681,2684,2688,2691,2695,2701,2705,2708,2711,2715,2726,2730,2733,2737,2740,2744,2747,2751,2754,2758,2761,2765,2768,2772,2775,2779],[12,2655,2656,2659],{},[16,2657,2658],{},"\"Basta aggiungere un bottone.\""," Cinque parole che per chi le pronuncia significano una piccola modifica, e per chi deve realizzarla significano giorni di lavoro. La comunicazione tra team tecnico e business è una delle sfide più sottovalutate nello sviluppo software.",[12,2661,2662],{},"Questa scena si ripete continuamente. Il business chiede qualcosa che sembra semplice. Il team tecnico sa che non lo è. Ma tra i due c’è un muro fatto di modelli mentali diversi, che nessuno ha davvero interesse a rendere visibile. E il costo di quel muro si misura in sprint buttati, rework e frustrazione da entrambe le parti.",[30,2664,2666],{"id":2665},"le-incomprensioni-tipiche","Le incomprensioni tipiche",[12,2668,2669],{},"Ci sono frasi che generano sempre lo stesso cortocircuito.",[1649,2671,2673],{"id":2672},"è-una-cosa-semplice","“È una cosa semplice”",[12,2675,2676],{},"Per il business significa: il comportamento è chiaro. Per lo sviluppatore significa: non è chiaro cosa comporta a livello di sistema. Dietro a quel “bottone” ci sono validazioni, permessi, gestione errori, casi limite. Ma spiegare tutto questo richiede tempo, e spesso chi ascolta perde interesse.",[1649,2678,2680],{"id":2679},"è-urgente","“È urgente”",[12,2682,2683],{},"Quando tutto è urgente, le priorità perdono significato. Ogni urgenza sposta qualcos’altro, interrompe il lavoro in corso e genera context switch continui. Il risultato è che alla fine della giornata non si è concluso nulla, pur avendo lavorato tutto il giorno.",[1649,2685,2687],{"id":2686},"lo-facciamo-e-poi-miglioriamo","“Lo facciamo e poi miglioriamo”",[12,2689,2690],{},"Per il business è velocità. Per lo sviluppatore è l’inizio di un debito tecnico che probabilmente non verrà mai ripagato. Entrambi hanno una logica corretta, ma stanno parlando di due effetti diversi nel tempo.",[1649,2692,2694],{"id":2693},"quanto-ci-vuole","“Quanto ci vuole?”",[12,2696,2697,2698,103],{},"Il business vuole pianificare. Lo sviluppatore sa che ci sono troppe variabili sconosciute. Ma un numero viene comunque dato, diventa una promessa implicita, e quando non viene rispettato nasce sfiducia. È la dinamica tipica delle ",[133,2699,2700],{"href":301},"stime che non tornano",[30,2702,2704],{"id":2703},"perché-il-gap-esiste","Perché il gap esiste",[12,2706,2707],{},"Il gap nasce dai modelli mentali, più che dalle competenze. Chi lavora sul business pensa in termini di risultati, tempi e valore economico, e il software è un mezzo; chi sviluppa pensa in termini di sistemi, complessità e manutenibilità, e il software è il centro del lavoro. Entrambi gli approcci hanno senso, ma senza un ponte tra loro producono attrito costante.",[12,2709,2710],{},"In più, c’è un’asimmetria informativa profonda: il business non vede il costo tecnico delle decisioni e il team tecnico non vede il valore economico delle richieste. Le priorità finiscono così per diventare un confronto tra percezioni, non una decisione davvero informata.",[30,2712,2714],{"id":2713},"quanto-costa-davvero","Quanto costa davvero",[12,2716,2717,2718,2720,2721,2725],{},"Queste incomprensioni hanno effetti molto concreti. Si sprecano sprint interi su feature sviluppate a partire da requisiti capiti male, cresce uno ",[133,2719,1989],{"href":418}," silenzioso fatto di dettagli aggiunti a voce e mai pianificati, il rework continuo trasforma il ciclo “fai, mostra, rifai” nella normalità e, alla lunga, arrivano frustrazione e turnover. Le persone migliori si stancano di lavorare in un contesto dove il lavoro viene spesso rifatto, e ",[133,2722,2724],{"href":2723},"/blog/come-assumere-sviluppatori-bravi","trovarle è già un problema",". Una parte significativa del tempo di sviluppo viene assorbita non dalla complessità tecnica, ma dalle incomprensioni.",[30,2727,2729],{"id":2728},"come-costruire-un-linguaggio-comune","Come costruire un linguaggio comune",[12,2731,2732],{},"Non servono grandi teorie. Servono pratiche semplici e ripetute.",[1649,2734,2736],{"id":2735},"mostrare-invece-di-descrivere","Mostrare invece di descrivere",[12,2738,2739],{},"Un prototipo cliccabile chiarisce più di qualsiasi documento. Mostrare presto riduce drasticamente il rischio di fraintendimenti.",[1649,2741,2743],{"id":2742},"coinvolgere-uno-sviluppatore-nelle-riunioni-chiave","Coinvolgere uno sviluppatore nelle riunioni chiave",[12,2745,2746],{},"Quando il PM è l’unico ponte tra cliente e team tecnico, il messaggio si distorce. La presenza di uno sviluppatore senior nelle riunioni importanti evita settimane di lavoro sbagliato.",[1649,2748,2750],{"id":2749},"definire-un-vocabolario-condiviso","Definire un vocabolario condiviso",[12,2752,2753],{},"Termini come “deploy”, “staging”, “pronto”, “completo” devono avere un significato chiaro e condiviso. Molti malintesi nascono proprio da parole usate con significati diversi.",[1649,2755,2757],{"id":2756},"rendere-visibili-i-trade-off","Rendere visibili i trade-off",[12,2759,2760],{},"A ogni richiesta, il team tecnico dovrebbe spiegare non solo il tempo stimato, ma anche le conseguenze: cosa viene spostato, che debito tecnico si crea, che rischi si introducono. Dare al business elementi per decidere in modo consapevole.",[1649,2762,2764],{"id":2763},"il-ruolo-del-product-owner-come-traduttore","Il ruolo del product owner come traduttore",[12,2766,2767],{},"Un buon product owner, cioè la figura che tiene insieme obiettivi di business e lavoro del team, capisce entrambi i mondi e traduce continuamente tra i due. È una delle figure con il maggiore impatto sulla qualità dei progetti, proprio perché evita che il significato si perda nel passaggio.",[1649,2769,2771],{"id":2770},"retrospettive-orientate-alle-incomprensioni","Retrospettive orientate alle incomprensioni",[12,2773,2774],{},"Vale la pena analizzare a fine sprint dove ci si è fraintesi, non solo cosa è andato storto tecnicamente. Molto spesso il problema nasce nel modo in cui ci si è parlati, prima ancora che nel codice.",[30,2776,2778],{"id":2777},"è-un-problema-di-comunicazione","È un problema di comunicazione",[12,2780,2781],{},"Molti problemi attribuiti alla complessità del software nascono in realtà da una comunicazione inefficace tra chi decide e chi realizza. Il codice più costoso è quello che risolve il problema sbagliato perché nessuno si è fermato a verificare di aver capito davvero la domanda.",{"title":199,"searchDepth":200,"depth":200,"links":2783},[2784,2790,2791,2792,2800],{"id":2665,"depth":200,"text":2666,"children":2785},[2786,2787,2788,2789],{"id":2672,"depth":1768,"text":2673},{"id":2679,"depth":1768,"text":2680},{"id":2686,"depth":1768,"text":2687},{"id":2693,"depth":1768,"text":2694},{"id":2703,"depth":200,"text":2704},{"id":2713,"depth":200,"text":2714},{"id":2728,"depth":200,"text":2729,"children":2793},[2794,2795,2796,2797,2798,2799],{"id":2735,"depth":1768,"text":2736},{"id":2742,"depth":1768,"text":2743},{"id":2749,"depth":1768,"text":2750},{"id":2756,"depth":1768,"text":2757},{"id":2763,"depth":1768,"text":2764},{"id":2770,"depth":1768,"text":2771},{"id":2777,"depth":200,"text":2778},"2026-03-24","La comunicazione tra team tecnico e business è piena di equivoci che costano sprint interi. Le frasi ricorrenti e come costruire un linguaggio comune.","/images/blog/team-tecnico-business-due-lingue.jpg",{},"/blog/2026-03-24-team-tecnico-business-due-lingue",{"title":2651,"description":2802},"Comunicazione team tecnico e business: come migliorarla","team-tecnico-business-due-lingue","blog/2026-03-24-team-tecnico-business-due-lingue",[2811,2812,2813,2814,659],"comunicazione","product-management","team","produttività","Kvo8EhiXrd4P9KH8VFps3tboZGtGF6BZaKrXkoUBvIk",{"id":2817,"title":2818,"body":2819,"category":210,"date":2981,"description":2982,"extension":213,"image":2983,"meta":2984,"navigation":3,"path":2985,"published":3,"seo":2986,"seoTitle":2987,"slug":2988,"stem":2989,"tags":2990,"updated":229,"__hash__":2994},"blog/blog/2026-03-19-agenzia-abbandona-progetto-software.md","Agenzia che abbandona il progetto: come proteggersi e ripartire",{"type":9,"value":2820,"toc":2959},[2821,2827,2831,2834,2838,2841,2845,2851,2855,2858,2862,2865,2869,2872,2876,2879,2883,2886,2890,2893,2897,2900,2904,2910,2914,2917,2921,2928,2932,2935,2939,2942,2946,2949,2953,2956],[12,2822,2823,2826],{},[16,2824,2825],{},"Ricevere una mail dal fornitore che dice \"non riusciamo più a seguire il progetto\" è meno raro di quanto si pensi."," Quando un'agenzia abbandona un progetto software, il problema va ben oltre il ritardo: ti ritrovi con codice che non conosci, processi che non controlli e un prodotto che dipende da conoscenze non più disponibili. Il vendor lock-in, cioè la dipendenza da un fornitore che rende difficile cambiare strada, tocca persone, organizzazione e controllo, ben oltre la sola tecnologia.",[30,2828,2830],{"id":2829},"perché-succede","Perché succede",[12,2832,2833],{},"Nella maggior parte dei casi ci sono dinamiche molto concrete, senza cattiva fede.",[1649,2835,2837],{"id":2836},"le-priorità-dellagenzia-cambiano","Le priorità dell’agenzia cambiano",[12,2839,2840],{},"Arrivano clienti più grandi o più urgenti. Il tuo progetto scivola in fondo alla lista. Le consegne rallentano, l’attenzione cala, finché diventa evidente che non riescono più a seguirti come prima.",[1649,2842,2844],{"id":2843},"le-persone-chiave-se-ne-vanno","Le persone chiave se ne vanno",[12,2846,2847,2848,2850],{},"Lo sviluppatore che conosceva il progetto cambia lavoro. Chi lo sostituisce non ha lo stesso contesto. È lo stesso problema del ",[133,2849,574],{"href":573},", ma fuori dalla tua azienda.",[1649,2852,2854],{"id":2853},"le-tensioni-economiche-aumentano","Le tensioni economiche aumentano",[12,2856,2857],{},"Il budget iniziale si rivela insufficiente, le trattative diventano difficili, la collaborazione si logora. A un certo punto, continuare non conviene più a una delle parti.",[30,2859,2861],{"id":2860},"il-danno-vero-non-è-il-ritardo","Il danno vero non è il ritardo",[12,2863,2864],{},"Il ritardo è solo l’effetto visibile. Il problema più grande è che spesso non esiste documentazione utile, il codice segue convenzioni interne all’agenzia, il processo di deploy è noto solo a loro, l’infrastruttura è configurata in modo opaco e le dipendenze non sono tracciate chiaramente. In pratica, perdi la conoscenza operativa del tuo stesso prodotto.",[30,2866,2868],{"id":2867},"come-proteggersi-prima-che-succeda","Come proteggersi prima che succeda",[12,2870,2871],{},"Alcune regole, se stabilite dall’inizio, riducono drasticamente il rischio.",[1649,2873,2875],{"id":2874},"il-repository-deve-essere-tuo","Il repository deve essere tuo",[12,2877,2878],{},"Il codice deve stare su un repository di tua proprietà: l’agenzia ha accesso, ma tu sei il proprietario. Se il rapporto finisce, il codice resta a te senza discussioni.",[1649,2880,2882],{"id":2881},"la-cicd-deve-essere-trasparente","La CI/CD deve essere trasparente",[12,2884,2885],{},"Il processo di deploy deve essere automatizzato, documentato e comprensibile: non può dipendere da una procedura manuale che solo loro conoscono.",[1649,2887,2889],{"id":2888},"documentazione-minima-ma-continua","Documentazione minima ma continua",[12,2891,2892],{},"Ci sono almeno tre cose che devono restare sempre aggiornate: come avviare il progetto in locale, come funziona il deploy e quali sono state le principali decisioni architetturali. Se questa documentazione viene rimandata “alla fine”, di solito non verrà mai fatta.",[1649,2894,2896],{"id":2895},"sessioni-periodiche-di-allineamento","Sessioni periodiche di allineamento",[12,2898,2899],{},"Una volta al mese qualcuno della tua azienda dovrebbe capire cosa è cambiato, come è evoluto il progetto e quali sono i punti critici. Questo riduce la dipendenza totale dal fornitore.",[1649,2901,2903],{"id":2902},"tecnologie-standard-non-framework-proprietari","Tecnologie standard, non framework proprietari",[12,2905,2906,2907,103],{},"Soluzioni troppo personalizzate rendono molto difficile il passaggio a un altro fornitore. La velocità iniziale può trasformarsi in un ",[133,2908,2909],{"href":1746},"costo di manutenzione molto alto nel tempo",[30,2911,2913],{"id":2912},"cosa-fare-quando-è-già-successo","Cosa fare quando è già successo",[12,2915,2916],{},"Se ti trovi già in questa situazione, l’ordine delle azioni conta.",[1649,2918,2920],{"id":2919},"evita-la-tentazione-di-riscrivere-tutto","Evita la tentazione di riscrivere tutto",[12,2922,2923,2924,2927],{},"L’istinto è buttare via tutto. Spesso è un errore, come spiegato parlando del ",[133,2925,2926],{"href":1089},"perché riscrivere da zero è rischioso",". Il codice esistente contiene mesi di lavoro e casi limite già risolti.",[1649,2929,2931],{"id":2930},"fai-un-audit-tecnico-indipendente","Fai un audit tecnico indipendente",[12,2933,2934],{},"Un developer senior esterno può analizzare il codice in pochi giorni e darti una mappa chiara: cosa è recuperabile, cosa è rischioso, cosa va sistemato subito.",[1649,2936,2938],{"id":2937},"metti-in-sicurezza-linfrastruttura","Metti in sicurezza l’infrastruttura",[12,2940,2941],{},"Verifica e prendi controllo di dominio, hosting, database, certificati e accessi ai servizi esterni. Questa è la priorità assoluta, perché senza questi elementi il progetto resta esposto indipendentemente da quanto il codice sia recuperabile.",[1649,2943,2945],{"id":2944},"valuta-con-calma-il-passo-successivo","Valuta con calma il passo successivo",[12,2947,2948],{},"Solo dopo aver capito la situazione reale puoi decidere se cambiare fornitore, internalizzare o fare una soluzione mista. Ma questa volta con regole più chiare.",[30,2950,2952],{"id":2951},"la-lezione-da-portare-a-casa","La lezione da portare a casa",[12,2954,2955],{},"La dipendenza da un fornitore è un rischio di business, non tecnico.",[12,2957,2958],{},"Ogni mese in cui il tuo progetto vive su repository che non controlli, con processi che non conosci e decisioni che non sono documentate, stai accumulando un debito di autonomia. E quando arriva il momento di pagarlo, il costo è molto più alto di quanto immagini.",{"title":199,"searchDepth":200,"depth":200,"links":2960},[2961,2966,2967,2974,2980],{"id":2829,"depth":200,"text":2830,"children":2962},[2963,2964,2965],{"id":2836,"depth":1768,"text":2837},{"id":2843,"depth":1768,"text":2844},{"id":2853,"depth":1768,"text":2854},{"id":2860,"depth":200,"text":2861},{"id":2867,"depth":200,"text":2868,"children":2968},[2969,2970,2971,2972,2973],{"id":2874,"depth":1768,"text":2875},{"id":2881,"depth":1768,"text":2882},{"id":2888,"depth":1768,"text":2889},{"id":2895,"depth":1768,"text":2896},{"id":2902,"depth":1768,"text":2903},{"id":2912,"depth":200,"text":2913,"children":2975},[2976,2977,2978,2979],{"id":2919,"depth":1768,"text":2920},{"id":2930,"depth":1768,"text":2931},{"id":2937,"depth":1768,"text":2938},{"id":2944,"depth":1768,"text":2945},{"id":2951,"depth":200,"text":2952},"2026-03-19","Quando un fornitore software si ferma a metà progetto, il danno va oltre il ritardo: è la perdita di controllo. Come proteggersi prima e cosa fare quando succede.","/images/blog/agenzia-abbandona-progetto-software.jpg",{},"/blog/2026-03-19-agenzia-abbandona-progetto-software",{"title":2818,"description":2982},"Agenzia abbandona progetto software: come proteggersi e ripartire","agenzia-abbandona-progetto-software","blog/2026-03-19-agenzia-abbandona-progetto-software",[2991,2992,2993,1616,660],"cambiare-fornitore","vendor-lock-in","continuita-progetto","AGGxkYZ823cjUdfJxnqa76qEfYMuavsOpOjizaLf0QU",{"id":2996,"title":2997,"body":2998,"category":210,"date":3106,"description":3107,"extension":213,"image":3108,"meta":3109,"navigation":3,"path":3110,"published":3,"seo":3111,"seoTitle":3112,"slug":3113,"stem":3114,"tags":3115,"updated":229,"__hash__":3120},"blog/blog/2026-03-17-software-fragile-regressioni.md","Software fragile: ogni modifica rompe qualcos'altro. Come uscirne",{"type":9,"value":2999,"toc":3095},[3000,3006,3010,3013,3020,3023,3025,3028,3032,3039,3043,3046,3050,3053,3057,3068,3072,3075,3082,3085,3089,3092],[12,3001,3002,3005],{},[16,3003,3004],{},"Il tuo team evita di deployare il venerdì. E spesso anche il giovedì."," Ogni rilascio, cioè ogni pubblicazione di una nuova versione del software, è preceduto da test manuali, mail di avvertimento e qualcuno che resta collegato \"per sicurezza\". È il segnale di un software fragile, dove ogni modifica rischia di causare una regressione. E quella fragilità ha un costo che stai pagando ogni giorno.",[30,3007,3009],{"id":3008},"i-segnali-del-software-fragile","I segnali del software fragile",[12,3011,3012],{},"Si riconoscono anche senza essere tecnici. Correggi un bug nel carrello e si rompe la fatturazione. Aggiungi un campo al form di registrazione e smette di funzionare il reset password. Alcune parti del codice vengono evitate perché “funzionano, meglio non toccarle”.",[12,3014,3015,3016,3019],{},"Questi sono ",[16,3017,3018],{},"bug di regressione",": modifiche in un punto che causano rotture in punti apparentemente non collegati.",[12,3021,3022],{},"I segnali concreti sono abbastanza chiari: deploy che richiedono ore di test manuali prima di andare in produzione, moduli che nessuno vuole modificare, bug segnalati su funzionalità che non sono state toccate, hotfix che generano altri hotfix e tempi molto lunghi anche per modifiche che in teoria sembrano semplici. Se riconosci diversi di questi sintomi, il sistema sta diventando fragile.",[30,3024,2830],{"id":2829},[12,3026,3027],{},"Il software raramente nasce fragile. Lo diventa nel tempo.",[1649,3029,3031],{"id":3030},"pochi-test-automatici-sui-flussi-critici","Pochi test automatici sui flussi critici",[12,3033,3034,3035,3038],{},"Senza test automatici, ogni modifica diventa un azzardo: nessuno sa con certezza cosa si romperà finché qualcuno non se ne accorge in produzione. Come ho scritto parlando di ",[133,3036,3037],{"href":2158},"test coverage",", non serve testare tutto, ma serve testare i percorsi che contano davvero per il business.",[1649,3040,3042],{"id":3041},"alto-accoppiamento-tra-le-parti-del-sistema","Alto accoppiamento tra le parti del sistema",[12,3044,3045],{},"Quando ogni modulo dipende da molti altri, toccare un punto significa rischiare di avere effetti collaterali altrove. Questo succede quando il codice cresce senza una separazione chiara delle responsabilità.",[1649,3047,3049],{"id":3048},"debito-tecnico-accumulato","Debito tecnico accumulato",[12,3051,3052],{},"Le scorciatoie ripetute nel tempo rendono il sistema sempre più difficile da modificare. Il debito tecnico non si vede nei report, ma si manifesta in lentezza, bug e timore di intervenire.",[30,3054,3056],{"id":3055},"il-costo-per-il-business","Il costo per il business",[12,3058,3059,3060,3063,3064,3067],{},"La fragilità ha un impatto economico molto concreto. Se ogni deploy è rischioso, si rilascia meno spesso e le funzionalità arrivano ai clienti più lentamente. I bug che sfuggono in produzione costano fiducia, supporto e reputazione. Nel frattempo il team entra in un blocco psicologico: chi ha paura di modificare il codice smette di proporre miglioramenti, e le persone migliori tendono a cercare contesti meno stressanti. Quando ",[133,3061,3062],{"href":573},"perdi persone chiave",", la situazione peggiora ancora. Anche il costo delle modifiche cresce: un intervento che in un sistema sano richiederebbe due giorni, in un sistema fragile può richiederne dieci. A questo punto spesso nasce la tentazione di ",[133,3065,3066],{"href":1089},"riscrivere tutto da zero",": raramente è la scelta migliore.",[30,3069,3071],{"id":3070},"come-migliorare-senza-fermare-lo-sviluppo","Come migliorare senza fermare lo sviluppo",[12,3073,3074],{},"Non serve bloccare il progetto per mesi: conviene intervenire in modo graduale e continuo, partendo dai flussi critici — registrazione, login, pagamento, operazioni core. Anche pochi test ben scritti su questi percorsi riducono drasticamente le regressioni. Poi si lavora un modulo alla volta: ogni volta che si interviene su un pezzo di codice, lo si lascia un po’ più ordinato e indipendente di come lo si è trovato. È un miglioramento progressivo, non un refactoring massivo.",[12,3076,3077,3078,3081],{},"Ha molto valore anche automatizzare la pipeline di rilascio. Build automatiche, test automatici e un ambiente di staging affidabile riducono il rischio e trasformano il deploy in un’operazione ordinaria. Anche ",[133,3079,3080],{"href":135},"l’AI può aiutare",", ma solo se le fondamenta sono abbastanza sane da permetterlo.",[12,3083,3084],{},"Infine conviene misurare la fragilità con pochi indicatori chiari: numero di bug di regressione al mese, tempo medio tra commit e deploy, numero di rollback, cioè ritorni rapidi alla versione precedente, dopo un rilascio. Se questi numeri migliorano, la fragilità sta davvero diminuendo.",[30,3086,3088],{"id":3087},"la-regola-pratica","La regola pratica",[12,3090,3091],{},"Se il tuo team ha paura di deployare, il problema è nel sistema.",[12,3093,3094],{},"E il sistema tende a peggiorare nel tempo se non si interviene. Basta iniziare: qualche test mirato, una pipeline più solida, una conversazione chiara sulle parti più rischiose del codice. Un sistema sano permette di rilasciare spesso, con serenità; quando questo non succede, è un segnale che vale la pena ascoltare.",{"title":199,"searchDepth":200,"depth":200,"links":3096},[3097,3098,3103,3104,3105],{"id":3008,"depth":200,"text":3009},{"id":2829,"depth":200,"text":2830,"children":3099},[3100,3101,3102],{"id":3030,"depth":1768,"text":3031},{"id":3041,"depth":1768,"text":3042},{"id":3048,"depth":1768,"text":3049},{"id":3055,"depth":200,"text":3056},{"id":3070,"depth":200,"text":3071},{"id":3087,"depth":200,"text":3088},"2026-03-17","Software dove ogni modifica rompe qualcosa: il team evita di deployare e lo sviluppo rallenta. Perché succede e come ridurre gradualmente la fragilità senza bloccare il progetto.","/images/blog/software-fragile-regressioni.jpg",{},"/blog/2026-03-17-software-fragile-regressioni",{"title":2997,"description":3107},"Software fragile: perché ogni modifica rompe qualcosa","software-fragile-regressioni","blog/2026-03-17-software-fragile-regressioni",[3116,3117,3118,1134,3119],"software-fragile","regressioni","deploy","manutenzione","vUbjyjc1V1RERmkE5DFXN8S6zHu_BSEPjFAxVbqUIIY",{"id":3122,"title":3123,"body":3124,"category":210,"date":3228,"description":3229,"extension":213,"image":3230,"meta":3231,"navigation":3,"path":3232,"published":3,"seo":3233,"seoTitle":3234,"slug":3235,"stem":3236,"tags":3237,"updated":229,"__hash__":3239},"blog/blog/2026-03-12-costi-manutenzione-software.md","Costi di manutenzione software: quanto mettere a budget ogni anno",{"type":9,"value":3125,"toc":3220},[3126,3132,3136,3139,3147,3154,3157,3161,3164,3167,3171,3174,3177,3181,3187,3191,3194,3197,3204,3207,3211,3214],[12,3127,3128,3131],{},[16,3129,3130],{},"Il giorno in cui il software va in produzione, inizia una fase diversa di costi."," I costi di manutenzione software sono spesso sottovalutati: la maggior parte dei business plan prevede una voce \"sviluppo\" con un importo e una data di fine, come se dopo quella data il problema economico fosse risolto. In realtà i costi si trasformano, e spesso, nel tempo, quello che spendi dopo il lancio supera quello che hai speso per costruire. Se non lo sai prima di iniziare, ti ritrovi con un prodotto che funziona ma che non hai previsto di mantenere.",[30,3133,3135],{"id":3134},"perché-il-software-non-è-mai-davvero-finito","Perché il software non è mai davvero “finito”",[12,3137,3138],{},"Un edificio, una volta costruito, sta in piedi da solo. Il software no. Vive in un ecosistema che cambia continuamente, e se non cambia insieme a quell’ecosistema, inizia a degradarsi.",[12,3140,3141,3142,3146],{},"Gli aggiornamenti di sicurezza sono il primo fattore da considerare. Framework, linguaggi, sistemi operativi e database ricevono patch continue; ignorarle significa accumulare vulnerabilità nel tempo. Come ho scritto parlando di ",[133,3143,3145],{"href":3144},"/blog/sicurezza-backend-produzione","sicurezza nel backend",", un sistema non aggiornato diventa progressivamente più esposto.",[12,3148,3149,3150,103],{},"Poi ci sono dipendenze e librerie. Il tuo codice si appoggia a decine di componenti esterni: alcuni si evolvono, altri vengono deprecati, altri ancora vengono abbandonati. Quando una dipendenza cambia o smette di essere supportata, qualcuno deve intervenire. Ed è qui che emerge il ",[133,3151,3153],{"href":3152},"/blog/dipendenze-open-source-costo-nascosto","costo nascosto delle dipendenze open source",[12,3155,3156],{},"Lo stesso vale per l’infrastruttura. Certificati che scadono, database che crescono, costi cloud che cambiano, monitoraggio da mantenere attivo: nulla resta fermo da solo. Infine arrivano i bug e i comportamenti inattesi, che emergono con l’uso reale, con utenti veri, volumi veri e casi d’uso che nessuno aveva previsto in fase di sviluppo.",[30,3158,3160],{"id":3159},"il-numero-che-spesso-sorprende-la-maggior-parte-del-costo-è-dopo","Il numero che spesso sorprende: la maggior parte del costo è dopo",[12,3162,3163],{},"In molti studi sul ciclo di vita del software, si osserva che la parte più consistente del costo totale non è nello sviluppo iniziale ma negli anni successivi, tra manutenzione, aggiornamenti e adeguamenti.",[12,3165,3166],{},"Tradotto in pratica: un software che è costato 100.000 euro per essere sviluppato può richiedere, nei cinque anni successivi, un investimento simile o superiore solo per rimanere sicuro, compatibile e funzionante — solo per mantenere ciò che esiste, senza aggiungere nulla di nuovo. Se nel business plan la voce “software” è considerata una spesa una tantum, quel piano è incompleto.",[30,3168,3170],{"id":3169},"il-paragone-con-gli-asset-fisici","Il paragone con gli asset fisici",[12,3172,3173],{},"Quando compri un immobile, prevedi manutenzione, rifacimenti, adeguamenti. Con il software spesso questo non succede perché è invisibile: non vedi il degrado finché qualcosa non smette di funzionare.",[12,3175,3176],{},"La differenza è che un immobile si degrada lentamente. Un software può rompersi all’improvviso: un aggiornamento del browser, una vulnerabilità, un’API esterna che cambia comportamento.",[30,3178,3180],{"id":3179},"il-costo-di-non-mantenere","Il costo di non mantenere",[12,3182,3183,3184,3186],{},"Ignorare la manutenzione non elimina il costo: lo rimanda, moltiplicandolo. Il debito tecnico cresce con il tempo e, dopo anni senza aggiornamenti, un upgrade diventa complesso e rischioso. A volte si arriva alla tentazione di ",[133,3185,3066],{"href":1089},", che raramente è la scelta più economica. Intanto le vulnerabilità restano aperte, i problemi di compatibilità aumentano, e il giorno in cui qualcosa si rompe l’intervento d’emergenza costa molto più di una manutenzione costante.",[30,3188,3190],{"id":3189},"come-pianificare-in-modo-realistico","Come pianificare in modo realistico",[12,3192,3193],{},"Prevedere un budget annuo di manutenzione è il primo passo. Una regola pratica diffusa è considerare ogni anno una cifra nell’ordine del 15–20% del costo iniziale di sviluppo. Non è un numero esatto, ma è un riferimento utile per evitare sorprese.",[12,3195,3196],{},"Aiuta molto anche distinguere manutenzione da evoluzione. Bug fix, sicurezza, aggiornamenti e compatibilità appartengono alla prima categoria; nuove funzionalità appartengono alla seconda. Mescolare le due voci porta quasi sempre a piani confusi, perché finisci per trattare come “novità” anche il semplice costo di tenere in piedi ciò che già esiste.",[12,3198,3199,3200,3203],{},"Dove possibile conviene automatizzare. Test automatici, deploy automatici e monitoraggio riducono il costo delle attività ripetitive nel tempo. Anche l’",[133,3201,3202],{"href":135},"uso dell’AI nello sviluppo"," può velocizzare una parte della manutenzione ordinaria, ma solo se il progetto ha fondamenta abbastanza sane da permetterlo.",[12,3205,3206],{},"Conta anche la scelta delle tecnologie. Framework maturi e con cicli di rilascio prevedibili tendono a costare meno nel tempo rispetto a tecnologie emergenti con un futuro incerto. Infine, ogni piattaforma ha il suo ciclo di vita: pianificare gli aggiornamenti importanti con anticipo riduce drasticamente il rischio e il costo degli interventi urgenti.",[30,3208,3210],{"id":3209},"il-cambio-di-mentalità","Il cambio di mentalità",[12,3212,3213],{},"Il software funziona più come un servizio continuo che come un acquisto una tantum. Puoi ottimizzare i costi con scelte architetturali corrette e buone pratiche, ma non puoi eliminarli: ignorarli è il modo più rapido per trasformare un investimento in un problema.",[12,3215,3216,3217],{},"Vale la pena chiedersi: ",[16,3218,3219],{},"stiamo spendendo abbastanza per proteggere l’investimento che abbiamo già fatto?",{"title":199,"searchDepth":200,"depth":200,"links":3221},[3222,3223,3224,3225,3226,3227],{"id":3134,"depth":200,"text":3135},{"id":3159,"depth":200,"text":3160},{"id":3169,"depth":200,"text":3170},{"id":3179,"depth":200,"text":3180},{"id":3189,"depth":200,"text":3190},{"id":3209,"depth":200,"text":3210},"2026-03-12","Il software non è un acquisto una tantum. Sicurezza, aggiornamenti, bug e compatibilità costano. Come quantificare il budget annuale di manutenzione e perché 15-20% è realistico.","/images/blog/costi-manutenzione-software.jpg",{},"/blog/2026-03-12-costi-manutenzione-software",{"title":3123,"description":3229},"Costi manutenzione software: il budget annuale (15-20%)","costi-manutenzione-software","blog/2026-03-12-costi-manutenzione-software",[1797,3119,1247,2355,3238],"gestione-software","mHVD_vp2ujqkCsdSgPBz2MIf7mxtYJm_411jHPIDuFA",{"id":3241,"title":3242,"body":3243,"category":210,"date":3391,"description":3392,"extension":213,"image":3393,"meta":3394,"navigation":3,"path":3395,"published":3,"seo":3396,"seoTitle":3397,"slug":3398,"stem":3399,"tags":3400,"updated":229,"__hash__":3404},"blog/blog/2026-03-10-scope-creep-progetti-agile.md","Scope creep nei progetti agile: come riconoscerlo e contenerlo",{"type":9,"value":3244,"toc":3376},[3245,3251,3254,3258,3261,3270,3273,3276,3280,3283,3287,3293,3300,3304,3307,3311,3314,3318,3322,3325,3329,3332,3336,3342,3345,3349,3352,3356,3363,3367,3370,3373],[12,3246,3247,3250],{},[16,3248,3249],{},"\"Tanto siamo agili, possiamo cambiare.\""," Ripetuta sprint dopo sprint, questa frase spesso nasconde lo scope creep in un progetto software: la difficoltà di prendere decisioni e mantenerle nel tempo.",[12,3252,3253],{},"Il problema è farlo ogni due settimane senza rendersi conto del costo reale. Ogni cambio di priorità ha un prezzo che si paga in lavoro buttato, stime che perdono di senso e team che smette di credere nel processo.",[30,3255,3257],{"id":3256},"cosè-davvero-lo-scope-creep","Cos'è davvero lo scope creep",[12,3259,3260],{},"Lo scope creep è l'espansione progressiva dei requisiti di un progetto, cioè il continuo allargarsi delle richieste mentre il lavoro è già in corso. Non arriva tutto insieme. Arriva a piccole dosi:",[12,3262,3263,3264,3266,3267,3269],{},"\"aggiungiamo anche questo campo\",",[340,3265],{},"\n\"già che ci siamo integriamo anche questo sistema\",",[340,3268],{},"\n\"il cliente ha chiesto una cosa in più, dovrebbe essere veloce\".",[12,3271,3272],{},"Ogni richiesta singola sembra ragionevole. Ma la somma di molte richieste ragionevoli trasforma un progetto da tre mesi in uno da otto. E spesso nessuno riesce a spiegare dove sia finito il tempo.",[12,3274,3275],{},"La forma più insidiosa di scope creep è quella che si traveste da agilità. Agile significa poter cambiare direzione quando serve. Non significa cambiare idea continuamente senza una valutazione dell’impatto.",[30,3277,3279],{"id":3278},"pivot-o-indecisione-la-differenza-è-misurabile","Pivot o indecisione? La differenza è misurabile",[12,3281,3282],{},"Un cambio di direzione sano nasce da dati o feedback reali, viene comunicato con trasparenza al team e include una valutazione esplicita di tempi e costi. Quando invece tutto parte da opinioni non validate, viene presentato come “piccolo aggiustamento” e nessuno misura l’impatto sul lavoro già fatto, si sta semplicemente navigando a vista. E navigare a vista con un team di sviluppo è molto costoso.",[30,3284,3286],{"id":3285},"il-costo-reale-del-rework","Il costo reale del rework",[12,3288,3289,3290,103],{},"Cambiare priorità a metà sprint non significa perdere solo il lavoro non completato. Significa ritrovarsi con codice già scritto che viene congelato o rimosso, tempo pagato che non produce valore, stime che perdono credibilità e sviluppatori costretti a continui cambi di contesto, ognuno dei quali ",[133,3291,3292],{"href":1292},"costa circa 23 minuti di recupero",[12,3294,3295,3296,3299],{},"Un team di quattro sviluppatori che butta via anche solo il 25-30% del lavoro di ogni sprint sta bruciando, di fatto, l’equivalente di uno sviluppatore a tempo pieno all’anno. E quando ",[133,3297,3298],{"href":301},"le stime non funzionano",", la pianificazione diventa impossibile.",[30,3301,3303],{"id":3302},"leffetto-sul-team-che-poi-diventa-un-costo","L’effetto sul team (che poi diventa un costo)",[12,3305,3306],{},"Quando il lavoro viene sistematicamente cambiato o abbandonato, le persone smettono di investire energia. Per realismo: perché impegnarsi al massimo su qualcosa che potrebbe essere scartato tra due settimane? Il risultato è un team che lavora in modo difensivo, propone meno soluzioni e si limita a eseguire, e nel tempo i profili migliori tendono a cercare contesti più stabili.",[30,3308,3310],{"id":3309},"dire-no-è-parte-del-lavoro","Dire \"no\" è parte del lavoro",[12,3312,3313],{},"Il ruolo del Product Owner è filtrare le richieste e stabilire cosa ha senso fare adesso: ogni sì è un impegno di risorse, e le risorse sono limitate. Un buon Product Owner filtra, prioritizza e spiega perché qualcosa non entra nello sprint corrente. Questo richiede una visione chiara del prodotto; senza visione, si finisce per inseguire l’ultima richiesta arrivata.",[30,3315,3317],{"id":3316},"regole-pratiche-per-contenere-lo-scope-creep","Regole pratiche per contenere lo scope creep",[1649,3319,3321],{"id":3320},"definisci-il-risultato-dello-sprint-non-solo-i-task","Definisci il risultato dello sprint, non solo i task",[12,3323,3324],{},"Alla fine dello sprint deve essere chiaro cosa può fare l’utente in più rispetto a prima. Questo rende più evidente cosa è fuori perimetro.",[1649,3326,3328],{"id":3327},"usa-un-backlog-separato-per-le-nuove-richieste","Usa un backlog separato per le nuove richieste",[12,3330,3331],{},"Le idee che arrivano durante lo sprint si raccolgono, ma non si discutono fino alla pianificazione successiva.",[1649,3333,3335],{"id":3334},"rendi-visibile-il-costo-del-cambio","Rendi visibile il costo del cambio",[12,3337,3338,3339,3341],{},"Quando qualcuno propone di cambiare priorità, la risposta non dovrebbe essere un sì o un no immediato. Dovrebbe essere questa:",[340,3340],{},"\n\"Possiamo farlo, ma significa fermare X e spostare la consegna di Y.\"",[12,3343,3344],{},"Quando il costo è visibile, le decisioni migliorano.",[1649,3346,3348],{"id":3347},"tratta-lo-sprint-come-un-impegno","Tratta lo sprint come un impegno",[12,3350,3351],{},"Per la durata dello sprint, il team lavora su quanto concordato. Questa stabilità è ciò che rende il lavoro prevedibile.",[1649,3353,3355],{"id":3354},"valida-prima-di-costruire","Valida prima di costruire",[12,3357,3358,3359,3362],{},"Molti cambi nascono da ipotesi non verificate. Un ",[133,3360,3361],{"href":277},"MVP ben definito"," riduce drasticamente la necessità di cambiare continuamente direzione.",[30,3364,3366],{"id":3365},"lagilità-vera-richiede-disciplina","L’agilità vera richiede disciplina",[12,3368,3369],{},"Il paradosso dell’agile è che richiede più disciplina, non meno. La possibilità di cambiare direzione funziona solo se si ha il metodo per farlo con consapevolezza.",[12,3371,3372],{},"Se le priorità cambiano ogni sprint e nessuno riesce a spiegare perché, il problema sta nell’assenza di una visione chiara e di regole che proteggano il lavoro del team, più che nel framework agile.",[12,3374,3375],{},"L’agilità vera consiste nel fare le cose giuste nel momento giusto, con la piena consapevolezza di ciò che si sta sacrificando.",{"title":199,"searchDepth":200,"depth":200,"links":3377},[3378,3379,3380,3381,3382,3383,3390],{"id":3256,"depth":200,"text":3257},{"id":3278,"depth":200,"text":3279},{"id":3285,"depth":200,"text":3286},{"id":3302,"depth":200,"text":3303},{"id":3309,"depth":200,"text":3310},{"id":3316,"depth":200,"text":3317,"children":3384},[3385,3386,3387,3388,3389],{"id":3320,"depth":1768,"text":3321},{"id":3327,"depth":1768,"text":3328},{"id":3334,"depth":1768,"text":3335},{"id":3347,"depth":1768,"text":3348},{"id":3354,"depth":1768,"text":3355},{"id":3365,"depth":200,"text":3366},"2026-03-10","Lo scope creep mascherato da agilità è tra le cause principali di progetti software fuori budget. Come riconoscerlo e quanto costa cambiare priorità.","/images/blog/scope-creep-progetti-agile.jpg",{},"/blog/2026-03-10-scope-creep-progetti-agile",{"title":3242,"description":3392},"Scope creep agile: come riconoscerlo e contenerlo","scope-creep-progetti-agile","blog/2026-03-10-scope-creep-progetti-agile",[3401,3402,3403,1250,1797],"gestione-progetto","agile","product-ownership","wyh9LWFWTWHLprKoJ3YTth91vYGyB2CFAojwQSmEBjY",{"id":3406,"title":3407,"body":3408,"category":210,"date":3591,"description":3592,"extension":213,"image":3593,"meta":3594,"navigation":3,"path":3595,"published":3,"seo":3596,"seoTitle":3597,"slug":3598,"stem":3599,"tags":3600,"updated":229,"__hash__":3602},"blog/blog/2026-03-05-preventivo-software-partire-dal-budget.md","Preventivo software: perché conviene partire dal budget",{"type":9,"value":3409,"toc":3571},[3410,3416,3423,3427,3431,3434,3442,3449,3453,3456,3459,3463,3469,3473,3476,3480,3487,3490,3494,3497,3500,3504,3510,3517,3521,3528,3532,3536,3539,3543,3546,3550,3553,3557,3564,3568],[12,3411,3412,3415],{},[16,3413,3414],{},"\"Quanto costa fare un'app per gestire i miei ordini?\""," Chiedere un preventivo software senza contesto porta quasi sempre a una semplificazione forzata: il costo dipende da decisioni che emergono davvero solo quando si analizzano processi, eccezioni, integrazioni e vincoli.",[12,3417,3418,3419,3422],{},"Se invece mi dici ",[16,3420,3421],{},"quanto hai da investire",", la conversazione diventa più utile: possiamo decidere insieme cosa costruire prima, cosa rimandare, quali trade-off accetti e come ridurre il rischio di sorprese. È un modo più realistico di lavorare sul software.",[30,3424,3426],{"id":3425},"perché-un-preventivo-al-buio-è-fragile","Perché un preventivo “al buio” è fragile",[1649,3428,3430],{"id":3429},"cosa-stai-comprando-spesso-non-è-ancora-chiaro","Cosa stai comprando spesso non è ancora chiaro",[12,3432,3433],{},"Tu hai in testa un problema da risolvere. Tra problema e soluzione, però, ci sono molte scelte: permessi, eccezioni, integrazioni, flussi alternativi, requisiti non esplicitati.",[12,3435,3436,3437,3441],{},"“Gestione ordini” può voler dire cose molto diverse: un listino semplice o logiche di pricing piene di eccezioni, come succede quando ",[133,3438,3440],{"href":3439},"/blog/digitalizzare-processi-aziendali","il software finisce per codificare il caos","; un'integrazione con la contabilità oppure un semplice export manuale; un portale clienti o una gestione tutta interna; una reportistica essenziale oppure analisi più avanzate.",[12,3443,3444,3445,3448],{},"Ogni risposta sposta costi e tempi, e molte risposte emergono durante l’analisi, non prima. È lo stesso motivo per cui ",[133,3446,3447],{"href":301},"le stime nel software sono spesso imprecise",": è un'esplorazione guidata, più che una somma di pezzi indipendenti.",[1649,3450,3452],{"id":3451},"il-preventivo-fisso-incentiva-comportamenti-difensivi","Il preventivo fisso incentiva comportamenti difensivi",[12,3454,3455],{},"Quando il contratto è “scope fisso, prezzo fisso”, entrambe le parti iniziano a difendersi. Il fornitore aggiunge margine “di sicurezza” oppure sottostima e prova a recuperare dopo con le change request; il cliente, dal canto suo, cerca di infilare tutto possibile perché \"tanto era incluso\".",[12,3457,3458],{},"Non sempre succede, ma succede abbastanza spesso da rendere questo modello rischioso nei progetti dove i requisiti non sono già cristallizzati.",[30,3460,3462],{"id":3461},"perché-parlare-di-budget-migliora-la-qualità-delle-decisioni","Perché parlare di budget migliora la qualità delle decisioni",[12,3464,3465,3466,103],{},"Quando dici “ho 30.000 euro”, smettiamo di discutere di un software ideale e iniziamo a discutere di un software ",[16,3467,3468],{},"realistico",[1649,3470,3472],{"id":3471},"_1-le-priorità-diventano-visibili","1) Le priorità diventano visibili",[12,3474,3475],{},"Con un vincolo chiaro, possiamo separare ciò che è indispensabile da ciò che migliora il prodotto e da ciò che sarebbe solo comodo avere. In altre parole, emerge subito il nucleo senza cui il problema non si risolve, quello che conviene rimandare e quello che può aspettare senza danni. Senza un vincolo, tutto tende a diventare “must”; con un vincolo, il prodotto prende focus.",[1649,3477,3479],{"id":3478},"_2-posso-proporti-lapproccio-adatto-alla-fascia","2) Posso proporti l’approccio adatto alla fascia",[12,3481,3482,3483,3486],{},"Un progetto da 10K e uno da 40K possono risolvere lo stesso problema, ma con strumenti diversi e con compromessi diversi. Come ho spiegato nell’articolo su ",[133,3484,3485],{"href":1192},"quanto costa un software custom",", sono “prodotti” differenti.",[12,3488,3489],{},"Se non so il budget, rischio di proporti una soluzione troppo rigida, che poi esplode quando chiedi personalizzazioni, oppure una soluzione sovradimensionata, che ti fa spendere senza ottenere un valore proporzionato.",[1649,3491,3493],{"id":3492},"_3-possiamo-essere-espliciti-sui-limiti-ed-evitare-sorprese","3) Possiamo essere espliciti sui limiti (ed evitare sorprese)",[12,3495,3496],{},"Esempio di conversazione utile:\n“Con 15K facciamo versione 1 con queste 3 funzionalità core, solide e usabili. La reportistica avanzata e il portale clienti sono fase 2, stimata 10–15K.”",[12,3498,3499],{},"Questo è più onesto di un “ti costa X” senza chiarire cosa resta fuori.",[30,3501,3503],{"id":3502},"se-ti-dico-il-budget-lo-userai-tutto","“Se ti dico il budget, lo userai tutto”",[12,3505,3506,3507],{},"Obiezione legittima. E infatti serve una regola chiara: ",[16,3508,3509],{},"il budget non deve diventare il prezzo. Deve diventare il vincolo.",[12,3511,3512,3513,3516],{},"In pratica, prima definiamo un ",[960,3514,3515],{},"obiettivo minimo misurabile",", cioè cosa deve fare la v1 per poter essere considerata un successo. Poi costruiamo una roadmap di opzioni, distinguendo chiaramente cosa aggiungere se resta budget e cosa rimandare se il margine si restringe. Infine rendiamo trasparente ciò che stiamo acquistando davvero: sviluppo, test, deploy e documentazione minima. Nel software, “cose da fare” ce ne sono sempre più del budget disponibile, e il punto è spendere sulle cose con più ritorno.",[30,3518,3520],{"id":3519},"tre-regole-operative-per-farla-funzionare-davvero","Tre regole operative per farla funzionare davvero",[12,3522,3523,3524,3527],{},"La prima regola è definire un minimo non negoziabile: se il prodotto non riesce a fare il core flow, cioè il flusso principale che genera valore, costruire il resto non ha senso. La seconda è congelare lo scope, cioè il perimetro delle cose da fare, per blocchi brevi di due o tre settimane: consegni, misuri e solo dopo decidi cosa entra nel blocco successivo, in modo coerente con l’approccio ",[133,3525,3526],{"href":2005},"lancia, ascolta, migliora",". La terza è includere nel “minimo” anche continuità e controllo: repository tuo, accessi tuoi, deploy ripetibile, istruzioni di avvio in locale. Senza queste basi, stai solo comprando velocità oggi e fragilità domani.",[30,3529,3531],{"id":3530},"come-funziona-in-pratica","Come funziona in pratica",[1649,3533,3535],{"id":3534},"fase-1-problema-vincolo","Fase 1: problema + vincolo",[12,3537,3538],{},"“Questo è il problema, questo è il budget.” Una call focalizzata su flussi reali, eccezioni, integrazioni, utenti.",[1649,3540,3542],{"id":3541},"fase-2-piano-non-lista-infinita","Fase 2: piano, non lista infinita",[12,3544,3545],{},"Una proposta seria esplicita cosa include la v1, cosa resta fuori, quali trade-off vengono accettati, quali sono tempi e milestone e cosa serve da te in termini di dati, accessi e decisioni. La differenza la fa proprio questa chiarezza.",[1649,3547,3549],{"id":3548},"fase-3-iterazioni-brevi","Fase 3: iterazioni brevi",[12,3551,3552],{},"Ogni 2–3 settimane qualcosa di funzionante. Le priorità si aggiustano con costi visibili, non a fine progetto.",[1649,3554,3556],{"id":3555},"fase-4-il-budget-finisce-il-prodotto-resta-in-piedi","Fase 4: il budget finisce, il prodotto resta in piedi",[12,3558,3559,3560,3563],{},"Obiettivo: arrivare a fine budget con un prodotto ",[16,3561,3562],{},"utilizzabile",", non con “tante cose a metà”.",[30,3565,3567],{"id":3566},"il-budget-da-limite-a-strumento-di-focus","Il budget: da limite a strumento di focus",[12,3569,3570],{},"La maggior parte dei progetti che vanno bene non ha un budget infinito. Ha un budget chiaro, obiettivi misurabili, priorità stabili per blocchi brevi e scelte esplicite su cosa rimandare. Questo riduce sprechi, rework e conflitti, e rende molto più probabile arrivare a qualcosa che funziona davvero per il business.",{"title":199,"searchDepth":200,"depth":200,"links":3572},[3573,3577,3582,3583,3584,3590],{"id":3425,"depth":200,"text":3426,"children":3574},[3575,3576],{"id":3429,"depth":1768,"text":3430},{"id":3451,"depth":1768,"text":3452},{"id":3461,"depth":200,"text":3462,"children":3578},[3579,3580,3581],{"id":3471,"depth":1768,"text":3472},{"id":3478,"depth":1768,"text":3479},{"id":3492,"depth":1768,"text":3493},{"id":3502,"depth":200,"text":3503},{"id":3519,"depth":200,"text":3520},{"id":3530,"depth":200,"text":3531,"children":3585},[3586,3587,3588,3589],{"id":3534,"depth":1768,"text":3535},{"id":3541,"depth":1768,"text":3542},{"id":3548,"depth":1768,"text":3549},{"id":3555,"depth":1768,"text":3556},{"id":3566,"depth":200,"text":3567},"2026-03-05","Chiedere un preventivo software senza contesto porta a stime fragili. Partire dal budget rende la conversazione più utile: cosa costruire prima, cosa rimandare, come evitare le sorprese.","/images/blog/preventivo-software-partire-dal-budget.jpg",{},"/blog/2026-03-05-preventivo-software-partire-dal-budget",{"title":3407,"description":3592},"Preventivo software: partire dal budget per un progetto realistico","preventivo-software-partire-dal-budget","blog/2026-03-05-preventivo-software-partire-dal-budget",[1248,1247,3601,2355,375],"come-fare-preventivo","e6k0VCeDhvBLkguT9GfC2Qd89IpTKTJy9yFsRZRdMSI",{"id":3604,"title":3605,"body":3606,"category":210,"date":3736,"description":3737,"extension":213,"image":3738,"meta":3739,"navigation":3,"path":3740,"published":3,"seo":3741,"seoTitle":3742,"slug":3743,"stem":3744,"tags":3745,"updated":229,"__hash__":3748},"blog/blog/2026-03-03-bus-factor-developer-indispensabile.md","Se il tuo miglior developer se ne va domani, il prodotto sopravvive?",{"type":9,"value":3607,"toc":3722},[3608,3614,3618,3621,3624,3627,3633,3637,3640,3643,3649,3653,3656,3660,3667,3671,3674,3678,3681,3685,3691,3695,3698,3702,3705,3709,3712,3716,3719],[12,3609,3610,3613],{},[16,3611,3612],{},"Hai quel developer che sa tutto. Conosce ogni angolo del codice, ogni workaround, ogni decisione presa anni fa e mai documentata. Tutti lo cercano, tutti dipendono da lui."," All'inizio può sembrare un vantaggio, ma in realtà espone l'azienda a uno dei rischi organizzativi più seri. Il bus factor nello sviluppo software misura proprio questo: quanto il tuo prodotto dipende da una sola persona.",[30,3615,3617],{"id":3616},"cosè-il-bus-factor-e-perché-è-un-problema-aziendale","Cos'è il bus factor e perché è un problema aziendale",[12,3619,3620],{},"Il bus factor indica quante persone nel team, se non fossero più disponibili domani, metterebbero seriamente in difficoltà il progetto. In pratica misura quanto il sapere critico è concentrato su poche teste.",[12,3622,3623],{},"Se la risposta è “una”, il bus factor è 1.",[12,3625,3626],{},"Non serve immaginare scenari estremi. Basta una lettera di dimissioni, un burnout, un’offerta migliore. Quando il bus factor è molto basso, la conoscenza critica del prodotto vive nella testa di poche persone — a volte una sola.",[12,3628,3629,3630,103],{},"È una metrica di ",[16,3631,3632],{},"rischio operativo",[30,3634,3636],{"id":3635},"il-costo-reale-che-raramente-si-considera","Il costo reale che raramente si considera",[12,3638,3639],{},"Quando il developer chiave se ne va, sostituirlo è solo l'inizio del problema. La prima conseguenza è lo stop operativo: nessuno sa esattamente come funziona il deploy, perché quel job gira alle 3 di notte o dove si trovano certe configurazioni, quindi il team rallenta o si blocca.",[12,3641,3642],{},"Subito dopo arriva il reverse engineering del proprio prodotto. Il nuovo sviluppatore deve capire un sistema complesso senza contesto, e ho visto team impiegare mesi solo per tornare al livello di comprensione che avevano prima.",[12,3644,3645,3646,3648],{},"Da lì nasce spesso anche la tentazione di ",[133,3647,3066],{"href":1089},", che quasi sempre si rivela un errore costoso. Intanto si deformano anche le dinamiche interne: ogni decisione passa sempre dalla stessa persona, non per cattiva volontà, ma perché l'organizzazione l'ha resa il punto obbligato di ogni passaggio importante.",[30,3650,3652],{"id":3651},"i-segnali-che-il-problema-è-già-presente","I segnali che il problema è già presente",[12,3654,3655],{},"Puoi capirlo senza analisi complesse. Se quando qualcosa si rompe in produzione viene sempre cercata la stessa persona, se durante le sue ferie il team rallenta visibilmente, se esistono parti del sistema che nessun altro ha mai toccato e se le code review sono poco incisive perché solo uno \"capisce davvero\", allora il problema è già presente. Lo stesso vale quando le decisioni architetturali passano quasi sempre da una sola testa. Se ti riconosci in più di uno di questi segnali, probabilmente il bus factor è molto basso: è un effetto di come è organizzato il lavoro.",[30,3657,3659],{"id":3658},"come-alzare-il-bus-factor-senza-ingrandire-il-team","Come alzare il bus factor senza ingrandire il team",[12,3661,3662,3663,3666],{},"Serve distribuire la conoscenza: ",[133,3664,3665],{"href":1502},"aggiungere sviluppatori"," cambia poco se il sapere resta concentrato.",[1649,3668,3670],{"id":3669},"pair-programming-mirato","Pair programming mirato",[12,3672,3673],{},"Le parti critiche del sistema devono essere lavorate da almeno due persone. È il modo più rapido per trasferire la conoscenza tacita, quella che non finisce nei documenti e che spesso vale più di qualsiasi wiki.",[1649,3675,3677],{"id":3676},"code-review-fatte-davvero","Code review fatte davvero",[12,3679,3680],{},"La review serve ad assicurarsi che qualcun altro capisca cosa è stato fatto e perché. Se il reviewer non è in grado di spiegare la modifica, la review non ha ancora prodotto il suo effetto.",[1649,3682,3684],{"id":3683},"documentare-le-decisioni-non-il-codice","Documentare le decisioni, non il codice",[12,3686,3687,3688,3690],{},"La documentazione utile non commenta ogni riga di codice. Registra soprattutto ",[16,3689,681],{}," sono state prese certe decisioni. Gli ADR, cioè brevi documenti che spiegano una decisione architetturale e le sue ragioni, funzionano bene proprio per questo.",[1649,3692,3694],{"id":3693},"rotazione-sulle-aree-sensibili","Rotazione sulle aree sensibili",[12,3696,3697],{},"Se un componente è sempre gestito dalla stessa persona, la prossima modifica dovrebbe farla qualcun altro con il suo supporto. All'inizio si procede più lentamente, ma nel tempo si costruisce una base molto più solida.",[1649,3699,3701],{"id":3700},"momenti-regolari-di-knowledge-sharing","Momenti regolari di knowledge sharing",[12,3703,3704],{},"Sessioni brevi e frequenti, con il codice aperto e il contesto raccontato a voce, aiutano a distribuire conoscenza in modo naturale. È il classico knowledge sharing, cioè la condivisione pratica di ciò che il team sa già. Non serve trasformarle in cerimonie: basta renderle regolari.",[30,3706,3708],{"id":3707},"il-vero-nodo-è-culturale","Il vero nodo è culturale",[12,3710,3711],{},"Molte aziende premiano chi risolve emergenze, non chi previene la dipendenza dalla singola persona. Il developer che sistema un bug di notte è visto come un eroe, quello che investe tempo nel condividere conoscenza sembra “meno produttivo”, e questo incentivo porta naturalmente a un bus factor basso. Se vuoi davvero ridurre il rischio, la condivisione di conoscenza deve diventare una priorità esplicita, non un’attività secondaria.",[30,3713,3715],{"id":3714},"è-questione-di-gestione-del-rischio","È questione di gestione del rischio",[12,3717,3718],{},"Gestire il bus factor significa trattare la conoscenza come un asset critico dell’azienda, esattamente come fai con i dati o con le infrastrutture.",[12,3720,3721],{},"Il miglior developer fa in modo che il team possa andare avanti anche senza di lui, più che accumulare conoscenza su di sé.",{"title":199,"searchDepth":200,"depth":200,"links":3723},[3724,3725,3726,3727,3734,3735],{"id":3616,"depth":200,"text":3617},{"id":3635,"depth":200,"text":3636},{"id":3651,"depth":200,"text":3652},{"id":3658,"depth":200,"text":3659,"children":3728},[3729,3730,3731,3732,3733],{"id":3669,"depth":1768,"text":3670},{"id":3676,"depth":1768,"text":3677},{"id":3683,"depth":1768,"text":3684},{"id":3693,"depth":1768,"text":3694},{"id":3700,"depth":1768,"text":3701},{"id":3707,"depth":200,"text":3708},{"id":3714,"depth":200,"text":3715},"2026-03-03","Bus factor: cosa misura, perché un bus factor vicino a 1 è un rischio serio, e come distribuire la conoscenza critica nel team senza rallentare lo sviluppo.","/images/blog/bus-factor-developer-indispensabile.jpg",{},"/blog/2026-03-03-bus-factor-developer-indispensabile",{"title":3605,"description":3737},"Bus factor nel team dev: cos'è e come ridurlo","bus-factor-developer-indispensabile","blog/2026-03-03-bus-factor-developer-indispensabile",[658,1024,3746,3747,1026],"knowledge-sharing","sviluppo","GEPqfz_JiMojXP8A8oMRiIn2D2DguAqwp40wHrNCJXU",{"id":3750,"title":3751,"body":3752,"category":210,"date":3871,"description":3872,"extension":213,"image":3873,"meta":3874,"navigation":3,"path":3875,"published":3,"seo":3876,"seoTitle":3877,"slug":3878,"stem":3879,"tags":3880,"updated":229,"__hash__":3883},"blog/blog/2026-02-26-ogni-interruzione-costa-23-minuti.md","Ogni interruzione costa 23 minuti. Fai il conto a fine giornata",{"type":9,"value":3753,"toc":3863},[3754,3760,3763,3767,3789,3793,3803,3818,3822,3825,3829,3832,3835,3838,3842,3853,3857,3860],[12,3755,3756,3759],{},[16,3757,3758],{},"Call alle 10:30. Messaggio Slack alle 11:15. \"Scusa, una domanda veloce\" alle 11:45. Call di allineamento alle 14:00. Messaggio del cliente alle 15:20. Un'altra domanda alle 16:00."," Il costo delle interruzioni per gli sviluppatori è enorme, ma quasi mai misurato.",[12,3761,3762],{},"Il tuo sviluppatore ha avuto 8 ore di giornata lavorativa. Di quelle 8 ore, quante sono state davvero di lavoro concentrato e continuo? Questo non è un articolo sulla produttività personale: è un articolo sul costo economico delle interruzioni — un costo che non appare in nessun budget ma che spesso incide più di un’assunzione.",[30,3764,3766],{"id":3765},"la-ricerca-23-minuti-non-sono-unopinione","La ricerca: 23 minuti non sono un’opinione",[12,3768,3769,3770,3773,3774,3782,3783,3788],{},"Gloria Mark, ricercatrice all’Università della California Irvine, ha studiato per anni l’impatto delle interruzioni sul lavoro cognitivo complesso. Il risultato medio osservato: dopo un’interruzione servono ",[16,3771,3772],{},"circa 23 minuti"," per tornare al livello di concentrazione precedente (",[133,3775,3781],{"href":3776,"rel":3777,"target":3780},"https://ics.uci.edu/~gmark/CHI2005.pdf",[3778,3779],"nofollow","noopener","_blank","studio 2005",", ",[133,3784,3787],{"href":3785,"rel":3786,"target":3780},"https://ics.uci.edu/~gmark/chi08-mark.pdf",[3778,3779],"studio 2008","). Non perché serva tempo a “ripartire”, ma perché lo sviluppo software richiede di mantenere un modello mentale complesso: struttura del sistema, flusso del codice, dipendenze, stato del problema. Una notifica può interrompere questo equilibrio, e ricostruirlo richiede tempo.",[30,3790,3792],{"id":3791},"il-conto-economico-che-raramente-si-fa","Il conto economico che raramente si fa",[12,3794,3795,3796,3799,3800,103],{},"Una “domanda veloce” di 3 minuti non costa 3 minuti: costa circa ",[16,3797,3798],{},"26 minuti",", 3 di interruzione più 23 di recupero. Una call di 30 minuti non costa 30 minuti, ne costa più di 50. Con 5 interruzioni al giorno — un numero realistico in molti team — il costo supera facilmente le ",[16,3801,3802],{},"2 ore",[12,3804,3805,3806,3809,3810,3813,3814,3817],{},"In una settimana sono circa ",[16,3807,3808],{},"10 ore",". In un mese, circa ",[16,3811,3812],{},"40 ore",": l’equivalente di una settimana di lavoro. In un team di 4 persone, è come perdere uno sviluppatore a tempo pieno, ogni mese, senza accorgersene. E ",[133,3815,3816],{"href":1502},"aggiungere persone non risolve il problema"," se il modo di lavorare resta lo stesso.",[30,3819,3821],{"id":3820},"perché-le-interruzioni-a-metà-mattina-sono-le-peggiori","Perché le interruzioni a metà mattina sono le peggiori",[12,3823,3824],{},"Molti sviluppatori iniziano a essere davvero produttivi solo dopo i primi 30–45 minuti della giornata, quando hanno ricostruito il contesto del lavoro lasciato il giorno prima. Interrompere questo momento con una call o una richiesta urgente spezza proprio la fase di massima produttività: non si perde solo il tempo della riunione, ma l’intera finestra di lavoro che la precedeva e quella che serve per rientrare nel flusso.",[30,3826,3828],{"id":3827},"tre-regole-operative-che-cambiano-tutto","Tre regole operative che cambiano tutto",[12,3830,3831],{},"La prima regola è creare finestre di comunicazione. Call e riunioni andrebbero raggruppate in momenti precisi della giornata, come l’inizio, la fine della mattina, l’inizio del pomeriggio o la chiusura della giornata. Il punto è evitare il centro dei blocchi di lavoro. Se devi interrompere il flusso, fallo quando il flusso non è ancora iniziato o sta per finire.",[12,3833,3834],{},"La seconda regola è proteggere blocchi di lavoro veri, da due o tre ore consecutive senza interruzioni reali. Niente call, niente “domande veloci”, niente richieste sincrone. La differenza tra tre ore continue e tre ore spezzettate è enorme: spesso coincide con la differenza tra completare una feature o limitarsi ad avviarla.",[12,3836,3837],{},"La terza regola è usare la comunicazione asincrona come impostazione predefinita. La maggior parte delle richieste può aspettare qualche ora. Come urgenti andrebbero trattati solo i blocchi operativi reali o gli incidenti veri. Se puoi aspettare senza fermare il lavoro altrui, scrivi un messaggio e lascia che lo sviluppatore risponda quando esce dal flusso.",[30,3839,3841],{"id":3840},"segnali-che-il-tuo-team-è-troppo-interrotto","Segnali che il tuo team è troppo interrotto",[12,3843,3844,3845,3848,3849,3852],{},"I segnali sono abbastanza chiari: il lavoro vero si sposta la sera o nel weekend, ",[133,3846,3847],{"href":301},"le stime sembrano sempre sforare",", tutti appaiono occupati tutto il giorno ma le feature avanzano poco, e gli sviluppatori migliori iniziano a mostrare frustrazione o burnout, proprio mentre ",[133,3850,3851],{"href":2723},"trovarli è già abbastanza difficile",". In questi casi il problema raramente è la capacità del team; molto più spesso è il tempo reale di concentrazione che gli viene lasciato.",[30,3854,3856],{"id":3855},"proteggi-il-deep-work-come-proteggi-il-budget","Proteggi il deep work come proteggi il budget",[12,3858,3859],{},"Il tempo di concentrazione del team tecnico è una risorsa limitata e preziosa. Qui il concetto utile è il deep work, cioè il lavoro profondo e continuativo senza interruzioni: ogni riunione evitabile, ogni richiesta non urgente, ogni notifica superflua erode quella risorsa.",[12,3861,3862],{},"Le aziende che consegnano più velocemente non hanno necessariamente team più grandi o più talentuosi. Hanno team che riescono a lavorare in modo concentrato per più ore al giorno. La differenza tra 2 ore di lavoro profondo e 5 ore di lavoro profondo al giorno cambia radicalmente la velocità di avanzamento di un progetto.",{"title":199,"searchDepth":200,"depth":200,"links":3864},[3865,3866,3867,3868,3869,3870],{"id":3765,"depth":200,"text":3766},{"id":3791,"depth":200,"text":3792},{"id":3820,"depth":200,"text":3821},{"id":3827,"depth":200,"text":3828},{"id":3840,"depth":200,"text":3841},{"id":3855,"depth":200,"text":3856},"2026-02-26","Il costo delle interruzioni per gli sviluppatori è enorme: 23 minuti di concentrazione persa ogni volta. Con 5 al giorno perdi 2 ore. Ecco come ridurle.","/images/blog/ogni-interruzione-costa-23-minuti.jpg",{},"/blog/2026-02-26-ogni-interruzione-costa-23-minuti",{"title":3751,"description":3872},"Costo interruzioni sviluppatori: 23 minuti persi ogni volta","ogni-interruzione-costa-23-minuti","blog/2026-02-26-ogni-interruzione-costa-23-minuti",[658,3881,829,3882,227],"produttivita","startup","aUL4NbPr-ABo29AJ1-iM8L0TgVy8STO78iE32sDGtBg",{"id":3885,"title":3886,"body":3887,"category":1784,"date":4029,"description":4030,"extension":213,"image":4031,"meta":4032,"navigation":3,"path":4033,"published":3,"seo":4034,"seoTitle":4035,"slug":4036,"stem":4037,"tags":4038,"updated":229,"__hash__":4040},"blog/blog/2026-02-24-clean-code-guida-pratica.md","Clean Code: guida utile (non dogma)",{"type":9,"value":3888,"toc":4016},[3889,3894,3897,3901,3912,3915,3918,3922,3925,3929,3936,3939,3943,3946,3950,3956,3959,3963,3974,3978,3981,3988,3992,3995,3998,4002,4009,4013],[12,3890,3891],{},[16,3892,3893],{},"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.",[12,3895,3896],{},"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à.",[30,3898,3900],{"id":3899},"cosa-clean-code-fa-bene-molto-bene","Cosa Clean Code fa bene (molto bene)",[12,3902,3903,3904,3907,3908,3911],{},"Prima di criticare, vale la pena riconoscere cosa funziona davvero. I nomi che significano qualcosa sono una forma di manutenzione preventiva: ",[595,3905,3906],{},"calculateMonthlyRevenue()"," è molto meglio di ",[595,3909,3910],{},"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.",[12,3913,3914],{},"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.",[12,3916,3917],{},"Se un team parte dal caos, Clean Code spesso è un upgrade immediato. Il guaio inizia quando “linee guida” diventano “legge”.",[30,3919,3921],{"id":3920},"dove-il-dogma-fa-danni","Dove il dogma fa danni",[12,3923,3924],{},"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.",[1649,3926,3928],{"id":3927},"astrarre-troppo-presto","Astrarre troppo presto",[12,3930,3931,3932,3935],{},"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: ",[16,3933,3934],{},"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.",[12,3937,3938],{},"Un po’ di duplicazione costa poco. Un’astrazione prematura costa settimane quando scopri che era quella sbagliata.",[1649,3940,3942],{"id":3941},"frammentare-il-codice-in-troppi-micro-file","Frammentare il codice in troppi micro-file",[12,3944,3945],{},"“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à.",[1649,3947,3949],{"id":3948},"test-come-cerimonia","Test come cerimonia",[12,3951,3952,3953,103],{},"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: ",[133,3954,3955],{"href":2158},"puoi avere numeri alti e non testare ciò che conta",[12,3957,3958],{},"La domanda giusta non è “quanta coverage?”. È: “che incidente stiamo prevenendo con questo test?”",[1649,3960,3962],{"id":3961},"solid-applicato-senza-contesto","SOLID applicato senza contesto",[12,3964,3965,3966,3969,3970,3973],{},"SOLID è utile su sistemi complessi. Applicato ovunque e subito, può trasformare un progetto semplice in un labirinto di interfacce e livelli. Regola pratica: ",[16,3967,3968],{},"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 ",[133,3971,3972],{"href":277},"MVP",", spesso la priorità è avere un sistema chiaro, modificabile e consegnato in tempo — più che inseguire l’architettura “da manuale”.",[30,3975,3977],{"id":3976},"il-costo-concreto-del-dogma","Il costo concreto del dogma",[12,3979,3980],{},"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.",[12,3982,3983,3984,3987],{},"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 ",[133,3985,3986],{"href":301},"stime",", perché stai stimando la feature insieme a tutta la cerimonia che le viene costruita attorno.",[30,3989,3991],{"id":3990},"dovè-il-confine-5-regole-pratiche","Dov’è il confine: 5 regole pratiche",[12,3993,3994],{},"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.",[12,3996,3997],{},"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?",[30,3999,4001],{"id":4000},"la-sensibilità-conta-più-delle-regole","La sensibilità conta più delle regole",[12,4003,4004,4005,4008],{},"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 ",[133,4006,4007],{"href":1104},"semplicità è la cosa più difficile"," da ottenere, e spesso è il segno di vera competenza.",[30,4010,4012],{"id":4011},"come-riconoscere-il-problema","Come riconoscere il problema",[12,4014,4015],{},"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":199,"searchDepth":200,"depth":200,"links":4017},[4018,4019,4025,4026,4027,4028],{"id":3899,"depth":200,"text":3900},{"id":3920,"depth":200,"text":3921,"children":4020},[4021,4022,4023,4024],{"id":3927,"depth":1768,"text":3928},{"id":3941,"depth":1768,"text":3942},{"id":3948,"depth":1768,"text":3949},{"id":3961,"depth":1768,"text":3962},{"id":3976,"depth":200,"text":3977},{"id":3990,"depth":200,"text":3991},{"id":4000,"depth":200,"text":4001},{"id":4011,"depth":200,"text":4012},"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":3886,"description":4030},"Clean Code: guida pratica o dogma da evitare?","clean-code-guida-pratica","blog/2026-02-24-clean-code-guida-pratica",[226,4039,228,1617,227],"best-practice","AFRJ19Eot_VkQplNkQiYRHzvjSvhTdYBIhWV4JBqV7M",{"id":4042,"title":4043,"body":4044,"category":1784,"date":4156,"description":4157,"extension":213,"image":4158,"meta":4159,"navigation":3,"path":4160,"published":3,"seo":4161,"seoTitle":4162,"slug":4163,"stem":4164,"tags":4165,"updated":229,"__hash__":4167},"blog/blog/2026-02-19-design-pattern-oltre-il-linguaggio.md","Design pattern: perché contano più del linguaggio che usi",{"type":9,"value":4045,"toc":4148},[4046,4051,4054,4057,4067,4070,4074,4085,4091,4095,4098,4101,4104,4108,4111,4115,4118,4122,4125,4135,4139,4142,4145],[12,4047,4048],{},[16,4049,4050],{},"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?",[12,4052,4053],{},"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.",[12,4055,4056],{},"Quella competenza resta valida tra tre anni. E tra dieci.",[12,4058,4059,4060,4063,4064,103],{},"Stiamo entrando in un’era dove ",[133,4061,4062],{"href":1563},"l’AI scrive codice sempre meglio",". Non codice perfetto — ma codice funzionante, velocemente. Quello che l’AI non sa fare è ",[16,4065,4066],{},"decidere come strutturare un sistema",[12,4068,4069],{},"E il linguaggio con cui si struttura un sistema non è un framework. Sono i design pattern.",[30,4071,4073],{"id":4072},"il-programmatore-sta-diventando-sempre-più-un-progettista","Il programmatore sta diventando sempre più un progettista",[12,4075,4076,4077,4080,4081,4084],{},"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 ",[16,4078,4079],{},"cosa far scrivere"," e ",[16,4082,4083],{},"come organizzare il risultato",", più di quello che scrive codice velocemente.",[12,4086,4087,4088,103],{},"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 ",[133,4089,4090],{"href":135},"debito tecnico",[30,4092,4094],{"id":4093},"perché-i-pattern-valgono-più-dei-linguaggi","Perché i pattern valgono più dei linguaggi",[12,4096,4097],{},"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.",[12,4099,4100],{},"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.",[12,4102,4103],{},"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.",[30,4105,4107],{"id":4106},"i-pattern-che-contano-davvero-nella-pratica","I pattern che contano davvero nella pratica",[12,4109,4110],{},"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.",[30,4112,4114],{"id":4113},"lerrore-di-valutare-gli-sviluppatori-per-tecnologia","L’errore di valutare gli sviluppatori per tecnologia",[12,4116,4117],{},"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.",[30,4119,4121],{"id":4120},"cosa-significa-per-chi-investe-in-un-prodotto-software","Cosa significa per chi investe in un prodotto software",[12,4123,4124],{},"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.",[12,4126,4127,4128,4131,4132,103],{},"Un sistema costruito senza queste basi funziona finché non devi modificarlo, e nel software, prima o poi, ",[133,4129,4130],{"href":1746},"devi sempre modificarlo",". È così che nascono le riscritture, i ritardi e i costi che ",[133,4133,4134],{"href":301},"esplodono oltre le stime",[30,4136,4138],{"id":4137},"il-futuro-appartiene-a-chi-progetta","Il futuro appartiene a chi progetta",[12,4140,4141],{},"L’AI sta rendendo la scrittura del codice più accessibile e veloce. Ma progettare un sistema che regge nel tempo richiede ancora competenze umane.",[12,4143,4144],{},"I design pattern non sono teoria accademica. Sono strumenti pratici che determinano quanto un software sarà semplice da mantenere, estendere e far evolvere.",[12,4146,4147],{},"Il codice può essere riscritto. Una buona progettazione ti evita di doverlo fare.",{"title":199,"searchDepth":200,"depth":200,"links":4149},[4150,4151,4152,4153,4154,4155],{"id":4072,"depth":200,"text":4073},{"id":4093,"depth":200,"text":4094},{"id":4106,"depth":200,"text":4107},{"id":4113,"depth":200,"text":4114},{"id":4120,"depth":200,"text":4121},{"id":4137,"depth":200,"text":4138},"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":4043,"description":4157},"Design pattern software: perché valgono più del codice","design-pattern-oltre-il-linguaggio","blog/2026-02-19-design-pattern-oltre-il-linguaggio",[226,4166,222,829,227],"design-pattern","YlKUUsNpmncnStaN1tL8UxKNj0lB75sMDlSIrjA9Oa4",{"id":4169,"title":4170,"body":4171,"category":210,"date":4280,"description":4281,"extension":213,"image":4282,"meta":4283,"navigation":3,"path":4284,"published":3,"seo":4285,"seoTitle":4286,"slug":4287,"stem":4288,"tags":4289,"updated":229,"__hash__":4290},"blog/blog/2026-02-17-aggiungere-sviluppatori-progetto.md","Aggiungere sviluppatori a un progetto in ritardo: perché rallenta",{"type":9,"value":4172,"toc":4268},[4173,4178,4184,4188,4191,4194,4198,4202,4205,4209,4212,4216,4222,4226,4229,4233,4240,4244,4247,4254,4258,4265],[12,4174,4175],{},[16,4176,4177],{},"Il progetto è in ritardo. La deadline si avvicina. Il cliente preme. La reazione istintiva è spesso la stessa: aggiungere sviluppatori al progetto. Sembra logica elementare — più persone, più velocità. Nel software, però, l'effetto è spesso diverso da quello atteso.",[12,4179,4180,4181,4183],{},"Frederick Brooks lo descrisse già nel 1975 in ",[960,4182,1505],{},", un testo ancora molto citato nell'ingegneria del software. A distanza di decenni, il problema che descriveva è ancora attuale.",[30,4185,4187],{"id":4186},"il-mito-del-mese-uomo","Il mito del mese-uomo",[12,4189,4190],{},"Il ragionamento sembra semplice: se uno sviluppatore completa un progetto in 12 mesi, dodici sviluppatori lo completeranno in un mese.",[12,4192,4193],{},"Questa logica funziona quando le attività sono completamente indipendenti e non richiedono coordinamento. Nel software, questa condizione è rara. Il codice ha dipendenze, i moduli si intrecciano e le decisioni di uno sviluppatore influenzano il lavoro degli altri. Ogni persona aggiunta al team deve comprendere il contesto, coordinarsi con gli altri e allinearsi alle scelte fatte in precedenza.",[30,4195,4197],{"id":4196},"perché-aggiungere-persone-può-rallentare","Perché aggiungere persone può rallentare",[1649,4199,4201],{"id":4200},"la-comunicazione-cresce-rapidamente","La comunicazione cresce rapidamente",[12,4203,4204],{},"Se hai 3 sviluppatori, i canali di comunicazione sono pochi. Con 6 aumentano in modo significativo. Con 10 o più, il tempo speso in allineamenti e coordinamento diventa una parte rilevante della giornata. Ogni persona aggiunta non porta solo capacità produttiva, ma aumenta la necessità di sincronizzazione: riunioni, messaggi, code review, chiarimenti.",[1649,4206,4208],{"id":4207},"lonboarding-ha-un-costo","L'onboarding ha un costo",[12,4210,4211],{},"Uno sviluppatore nuovo non è produttivo dal primo giorno. Deve comprendere il codebase, cioè l’insieme del codice e delle convenzioni del progetto, l'architettura e le motivazioni dietro molte scelte. Questo richiede tempo sia a lui sia al team esistente, e nelle prime settimane il contributo netto può essere molto limitato.",[1649,4213,4215],{"id":4214},"la-conoscenza-implicita-non-si-trasferisce-facilmente","La conoscenza implicita non si trasferisce facilmente",[12,4217,4218,4219,4221],{},"In molti progetti, una parte importante delle decisioni non è documentata, ma vive nell'esperienza del team. È il classico problema del ",[133,4220,574],{"href":573},": se chi sa come funziona il sistema non è disponibile, i nuovi non hanno modo di colmare il gap velocemente.",[30,4223,4225],{"id":4224},"uno-scenario-tipico","Uno scenario tipico",[12,4227,4228],{},"Un team di 4 sviluppatori lavora a un prodotto. Il cliente chiede di anticipare la consegna e il team viene ampliato a 10 persone. Nelle prime settimane, i membri più esperti dedicano molto tempo all'onboarding. Successivamente, aumentano le necessità di coordinamento, le code review si allungano e il flusso di lavoro diventa più complesso. Il beneficio in termini di velocità può arrivare solo dopo mesi, quando ormai il vantaggio temporale inizialmente cercato si è ridotto.",[30,4230,4232],{"id":4231},"le-cause-reali-dei-ritardi","Le cause reali dei ritardi",[12,4234,4235,4236,4239],{},"Quando un progetto è in ritardo, raramente la causa è semplicemente il numero di persone. Più spesso entrano in gioco requisiti che cambiano nel tempo, ",[133,4237,4238],{"href":301},"stime iniziali poco realistiche",", debito tecnico che rallenta lo sviluppo e colli di bottiglia architetturali. Aggiungere persone non risolve direttamente nessuno di questi problemi.",[30,4241,4243],{"id":4242},"cosa-fare-invece","Cosa fare invece",[12,4245,4246],{},"Se la deadline non si può spostare, spesso è più efficace ridurre lo scope e rivedere il perimetro delle funzionalità davvero necessarie al rilascio. In parallelo conviene chiedere al team cosa sta rallentando il lavoro, perché molto spesso emergono ostacoli più semplici da rimuovere di quanto sembri: pipeline lente, ambienti instabili, code review bloccate.",[12,4248,4249,4250,4253],{},"Conta anche ridurre le interruzioni. ",[133,4251,4252],{"href":1292},"Meeting frequenti, cambi di priorità e richieste urgenti"," abbassano in modo significativo la produttività del team. Se poi è davvero necessario ampliare il gruppo, è meglio farlo in modo mirato, su attività ben isolate e con competenze specifiche, così da limitare l’impatto sul resto del progetto.",[30,4255,4257],{"id":4256},"la-lezione-di-brooks-oggi","La lezione di Brooks, oggi",[12,4259,4260,4261,4264],{},"La frase di Brooks — ",[960,4262,4263],{},"\"Adding manpower to a late software project makes it later\""," — resta valida come principio generale. In molti casi, un team piccolo, ben coordinato e con poche interruzioni riesce a mantenere una velocità più costante rispetto a un team numeroso che passa gran parte del tempo a coordinarsi.",[12,4266,4267],{},"La domanda utile, quando un progetto è in ritardo, non è \"quante persone servono in più?\", ma \"cosa sta rallentando il team attuale?\".",{"title":199,"searchDepth":200,"depth":200,"links":4269},[4270,4271,4276,4277,4278,4279],{"id":4186,"depth":200,"text":4187},{"id":4196,"depth":200,"text":4197,"children":4272},[4273,4274,4275],{"id":4200,"depth":1768,"text":4201},{"id":4207,"depth":1768,"text":4208},{"id":4214,"depth":1768,"text":4215},{"id":4224,"depth":200,"text":4225},{"id":4231,"depth":200,"text":4232},{"id":4242,"depth":200,"text":4243},{"id":4256,"depth":200,"text":4257},"2026-02-17","Aggiungere sviluppatori a un progetto in ritardo spesso lo rallenta. La Legge di Brooks e cosa fare invece per rispettare le deadline.","/images/blog/aggiungere-sviluppatori-progetto.jpg",{},"/blog/2026-02-17-aggiungere-sviluppatori-progetto",{"title":4170,"description":4281},"Aggiungere sviluppatori al progetto: perché rallenta","aggiungere-sviluppatori-progetto","blog/2026-02-17-aggiungere-sviluppatori-progetto",[658,829,3882,3881,226],"Z-9VeNX_hG0364kVimA9mCuO8olyPzQPdW42RCr3kys",{"id":4292,"title":4293,"body":4294,"category":210,"date":4401,"description":4402,"extension":213,"image":4403,"meta":4404,"navigation":3,"path":4405,"published":3,"seo":4406,"seoTitle":4407,"slug":4408,"stem":4409,"tags":4410,"updated":229,"__hash__":4415},"blog/blog/2026-02-12-ai-impatto-business-software.md","AI nello sviluppo software: cosa cambia per chi guida un'azienda",{"type":9,"value":4295,"toc":4392},[4296,4301,4305,4308,4311,4315,4326,4333,4337,4340,4343,4349,4353,4356,4359,4363,4369,4372,4375,4379,4382,4385,4389],[12,4297,4298],{},[16,4299,4300],{},"L'AI nello sviluppo software sta portando un cambiamento nel modo in cui si lavora e si prendono decisioni, ben oltre un semplice aggiornamento degli strumenti. Se guidi un'azienda o un prodotto digitale, questo riguarda direttamente budget, tempi e competitività.",[30,4302,4304],{"id":4303},"il-software-non-costa-più-quello-che-pensi","Il software non costa più quello che pensi",[12,4306,4307],{},"Fino a poco tempo fa, sviluppare un'applicazione web custom significava settimane di analisi, sprint di sviluppo, code review, bug fixing. Anche un progetto relativamente semplice poteva richiedere mesi e budget significativi. Oggi questo scenario sta cambiando rapidamente.",[12,4309,4310],{},"Gli strumenti basati su intelligenza artificiale stanno riducendo in modo sensibile i tempi di sviluppo. Attività che prima richiedevano ore o giorni oggi possono essere accelerate in modo consistente. Il risultato è codice funzionante, testabile e integrabile in un progetto reale — ben oltre il semplice prototipo.",[30,4312,4314],{"id":4313},"ma-allora-il-software-costerà-meno","Ma allora il software costerà meno?",[12,4316,4317,4318,4321,4322,4325],{},"In parte sì, ma la questione è più articolata. Il costo dell'",[16,4319,4320],{},"esecuzione"," — scrivere codice, implementare una API, cioè un punto di accesso con cui un sistema parla con un altro, costruire un'interfaccia — si sta riducendo. Gli ",[133,4323,4324],{"href":135},"strumenti AI sono un forte moltiplicatore di produttività"," per chi sa integrarli nel proprio flusso di lavoro.",[12,4327,4328,4329,4332],{},"Il costo della ",[16,4330,4331],{},"decisione"," — capire cosa costruire, per chi, con quale architettura, con quali vincoli — non si è ridotto. In alcuni casi, è diventato ancora più rilevante. Quando costruire diventa più semplice, scegliere cosa costruire diventa il vero elemento differenziante. Se la costruzione diventa più veloce, il valore si sposta verso la progettazione e la visione.",[30,4334,4336],{"id":4335},"la-trappola-del-tanto-costa-poco","La trappola del \"tanto costa poco\"",[12,4338,4339],{},"Qui c'è un rischio concreto per chi gestisce un'azienda. Se il software sembra costare meno e svilupparsi più velocemente, la tentazione è pensare: \"Bene, allora facciamolo fare al più economico\". È una scorciatoia che può diventare costosa nel medio periodo.",[12,4341,4342],{},"Un progetto sviluppato rapidamente con l'AI ma senza una visione architetturale solida rischia di funzionare oggi e diventare difficile da mantenere domani. L'AI è molto efficace nell'implementare, ma non conosce il tuo business, i tuoi vincoli organizzativi e il contesto in cui quel software dovrà evolvere nel tempo.",[12,4344,4345,4346,4348],{},"I problemi emergono spesso dopo alcuni mesi, quando il sistema deve crescere, integrarsi con altri strumenti, o adattarsi a requisiti che cambiano. E a quel punto, la tentazione di ",[133,4347,3066],{"href":1089}," diventa fortissima.",[30,4350,4352],{"id":4351},"il-vero-cambio-di-paradigma-dal-codice-al-prodotto","Il vero cambio di paradigma: dal codice al prodotto",[12,4354,4355],{},"Se sviluppare software diventa più economico e veloce, si apre un'opportunità significativa per chi ha idee e capacità di visione. Problemi che prima non aveva senso risolvere con il software — perché il rapporto costo-beneficio non era favorevole — ora diventano affrontabili.",[12,4357,4358],{},"Processi gestiti manualmente, nicchie di mercato troppo piccole per giustificare un investimento importante, idee rimaste in sospeso per motivi di budget: oggi questi scenari possono essere rivisti.",[30,4360,4362],{"id":4361},"cosa-cambia-per-chi-decide","Cosa cambia per chi decide",[12,4364,4365,4366,4368],{},"Per chi guida l'azienda, il software smette di essere solo un centro di costo e diventa un elemento strategico molto più accessibile. Il costo di sperimentare si è ridotto: testare un'idea, validare un mercato, lanciare un ",[133,4367,3972],{"href":277}," oggi richiede meno tempo e meno risorse rispetto a pochi anni fa.",[12,4370,4371],{},"Per chi guida il prodotto, invece, aumenta il peso delle priorità e dei requisiti. In un contesto in cui il codice si scrive più in fretta, la vera leva sta nel decidere cosa scrivere e perché. È lì che si crea o si distrugge valore.",[12,4373,4374],{},"Se infine stai valutando un fornitore di sviluppo software, conviene andare oltre il costo orario e la velocità di consegna. La domanda più importante è se quel team capisce il tuo business, sa farti le domande giuste e possiede una visione che va oltre la singola funzionalità.",[30,4376,4378],{"id":4377},"una-nuova-fase-della-digitalizzazione","Una nuova fase della digitalizzazione",[12,4380,4381],{},"La trasformazione digitale non è finita. Anzi, l'adozione di strumenti AI nello sviluppo software sta rendendo possibile affrontare progetti che prima non erano sostenibili economicamente.",[12,4383,4384],{},"Nei prossimi anni vedremo molte più soluzioni digitali verticali, strumenti su misura e automazioni in contesti dove oggi si lavora ancora in modo manuale. Non perché la tecnologia non esistesse, ma perché ora il costo di realizzazione è più allineato al valore generato.",[30,4386,4388],{"id":4387},"il-momento-è-questo","Il momento è questo",[12,4390,4391],{},"L'AI non sostituisce la capacità di progettare bene un sistema. Rende più veloce la parte esecutiva, ma aumenta l'importanza delle scelte iniziali. La differenza continua a farla la qualità delle decisioni, non la quantità di codice scritto.",{"title":199,"searchDepth":200,"depth":200,"links":4393},[4394,4395,4396,4397,4398,4399,4400],{"id":4303,"depth":200,"text":4304},{"id":4313,"depth":200,"text":4314},{"id":4335,"depth":200,"text":4336},{"id":4351,"depth":200,"text":4352},{"id":4361,"depth":200,"text":4362},{"id":4377,"depth":200,"text":4378},{"id":4387,"depth":200,"text":4388},"2026-02-12","L'AI riduce il costo di sviluppo software, ma aumenta il peso delle decisioni. Cosa cambia per chi guida un'azienda: budget, scelta dei fornitori, priorità.","/images/blog/ai-impatto-business-software.jpg",{},"/blog/2026-02-12-ai-impatto-business-software",{"title":4293,"description":4402},"AI nello sviluppo software: cosa cambia per il business","ai-impatto-business-software","blog/2026-02-12-ai-impatto-business-software",[4411,4412,4413,375,4414],"ai-business","costi-sviluppo","decisioni-tecniche","strategia-digitale","uCAn9iJfNhT_pmal5zEanMEYeKutLrR-ycAR2mQdOfk",{"id":4417,"title":4418,"body":4419,"category":1784,"date":4599,"description":4600,"extension":213,"image":4601,"meta":4602,"navigation":3,"path":4603,"published":3,"seo":4604,"seoTitle":4605,"slug":4606,"stem":4607,"tags":4608,"updated":229,"__hash__":4615},"blog/blog/2026-02-10-backend-frontend-separati-costi.md","Separare backend e frontend: quando ha senso (e quando no)",{"type":9,"value":4420,"toc":4578},[4421,4426,4429,4433,4437,4440,4444,4451,4454,4458,4462,4465,4469,4476,4480,4488,4492,4498,4502,4506,4513,4520,4524,4527,4531,4534,4538,4541,4545,4548,4554,4560,4564,4567,4571],[12,4422,4423],{},[16,4424,4425],{},"\"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.",[12,4427,4428],{},"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.",[30,4430,4432],{"id":4431},"perché-si-separa-backend-e-frontend","Perché si separa backend e frontend",[1649,4434,4436],{"id":4435},"la-promessa-della-riusabilità","La promessa della riusabilità",[12,4438,4439],{},"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.",[1649,4441,4443],{"id":4442},"la-realtà-api-frontend-driven-senza-documentazione","La realtà: API frontend-driven senza documentazione",[12,4445,4446,4447,4450],{},"Il team ha poco tempo. Le scadenze sono strette. Quindi le API vengono progettate ",[16,4448,4449],{},"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.",[12,4452,4453],{},"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.",[30,4455,4457],{"id":4456},"quanto-costa-davvero-la-separazione","Quanto costa davvero la separazione",[1649,4459,4461],{"id":4460},"doppio-lavoro-su-autenticazione-e-autorizzazione","Doppio lavoro su autenticazione e autorizzazione",[12,4463,4464],{},"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.",[1649,4466,4468],{"id":4467},"doppia-gestione-degli-errori","Doppia gestione degli errori",[12,4470,4471,4472,4475],{},"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 ",[16,4473,4474],{},"due volte"," — una lato backend, una lato frontend. Il tempo di sviluppo aumenta sensibilmente su ogni funzionalità che gestisce errori.",[1649,4477,4479],{"id":4478},"doppio-deploy-doppio-ambiente-doppio-debugging","Doppio deploy, doppio ambiente, doppio debugging",[12,4481,4482,4483,4487],{},"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 ",[133,4484,4486],{"href":4485},"/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.",[1649,4489,4491],{"id":4490},"il-costo-in-termini-di-team","Il costo in termini di team",[12,4493,4494,4495,103],{},"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 è ",[133,4496,4497],{"href":2723},"una complessità in più",[30,4499,4501],{"id":4500},"lalternativa-laravel-inertia-e-il-monolite-moderno","L'alternativa: Laravel Inertia e il monolite moderno",[1649,4503,4505],{"id":4504},"cosè-laravel-inertia-spiegato-semplice","Cos'è Laravel Inertia (spiegato semplice)",[12,4507,4508,4509,4512],{},"Laravel Inertia è un approccio che ti dà il ",[16,4510,4511],{},"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.",[12,4514,4515,4516,4519],{},"Il frontend e il backend vivono nello ",[16,4517,4518],{},"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.",[1649,4521,4523],{"id":4522},"cosa-elimini","Cosa elimini",[12,4525,4526],{},"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.",[1649,4528,4530],{"id":4529},"cosa-tieni","Cosa tieni",[12,4532,4533],{},"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.",[1649,4535,4537],{"id":4536},"per-chi-funziona","Per chi funziona",[12,4539,4540],{},"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.",[30,4542,4544],{"id":4543},"ma-se-poi-ci-serve-lapp-mobile","\"Ma se poi ci serve l'app mobile?\"",[12,4546,4547],{},"Questa è l'obiezione più comune. La risposta ha due parti.",[12,4549,4550,4553],{},[16,4551,4552],{},"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.",[12,4555,4556,4559],{},[16,4557,4558],{},"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.",[30,4561,4563],{"id":4562},"il-vero-costo-della-decisione-sbagliata","Il vero costo della decisione sbagliata",[12,4565,4566],{},"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.",[30,4568,4570],{"id":4569},"come-prendere-la-decisione-giusta","Come prendere la decisione giusta",[12,4572,4573,4574,4577],{},"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 ",[133,4575,4576],{"href":301},"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":199,"searchDepth":200,"depth":200,"links":4579},[4580,4584,4590,4596,4597,4598],{"id":4431,"depth":200,"text":4432,"children":4581},[4582,4583],{"id":4435,"depth":1768,"text":4436},{"id":4442,"depth":1768,"text":4443},{"id":4456,"depth":200,"text":4457,"children":4585},[4586,4587,4588,4589],{"id":4460,"depth":1768,"text":4461},{"id":4467,"depth":1768,"text":4468},{"id":4478,"depth":1768,"text":4479},{"id":4490,"depth":1768,"text":4491},{"id":4500,"depth":200,"text":4501,"children":4591},[4592,4593,4594,4595],{"id":4504,"depth":1768,"text":4505},{"id":4522,"depth":1768,"text":4523},{"id":4529,"depth":1768,"text":4530},{"id":4536,"depth":1768,"text":4537},{"id":4543,"depth":200,"text":4544},{"id":4562,"depth":200,"text":4563},{"id":4569,"depth":200,"text":4570},"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":4418,"description":4600},"Separare backend e frontend: quando conviene davvero","backend-frontend-separati-costi","blog/2026-02-10-backend-frontend-separati-costi",[226,4609,4610,4611,4612,4613,3882,4614,829],"backend","frontend","api-rest","laravel","inertia","costo-sviluppo","i7dz3-lnoxwPitFPo9eTt-sRbJLJpgnjgb2tjpqo5Hk",{"id":4617,"title":4618,"body":4619,"category":4746,"date":4747,"description":4748,"extension":213,"image":4749,"meta":4750,"navigation":3,"path":4751,"published":3,"seo":4752,"seoTitle":4753,"slug":4754,"stem":4755,"tags":4756,"updated":229,"__hash__":4758},"blog/blog/2026-02-05-test-coverage-cosa-misura.md","Test coverage al 100%: cosa misura davvero (e cosa no)",{"type":9,"value":4620,"toc":4731},[4621,4626,4629,4633,4637,4640,4644,4647,4650,4654,4657,4660,4664,4668,4671,4675,4678,4682,4685,4689,4692,4698,4702,4705,4708,4715,4719,4725,4728],[12,4622,4623],{},[16,4624,4625],{},"\"Abbiamo il 95% di code coverage.\" Bene. Ma il test coverage 100% è davvero l'obiettivo giusto? Cosa stiamo davvero testando? Mi è capitato di vedere suite di test con coverage altissima che non intercettavano bug critici in produzione. E suite con coverage molto basse che coprivano i flussi che contavano davvero.",[12,4627,4628],{},"La code coverage, cioè la percentuale di codice che viene eseguita mentre girano i test, rischia di diventare una metrica fine a se stessa. Un numero da mostrare nelle dashboard, da mettere nei badge del repository, da esibire nelle code review. Un numero alto non dice nulla sulla qualità dei test. Dice solo che del codice è stato eseguito durante i test.",[30,4630,4632],{"id":4631},"perché-la-coverage-è-una-metrica-ingannevole","Perché la coverage è una metrica ingannevole",[1649,4634,4636],{"id":4635},"coverage-misura-lesecuzione-non-la-verifica","Coverage misura l'esecuzione, non la verifica",[12,4638,4639],{},"Se scrivo un test che chiama una funzione ma non verifica il risultato, la coverage aumenta. La funzione è stata “coperta”: il codice è stato eseguito. Ma il test non protegge nulla. Il test passa, la coverage sale, e il bug resta lì.",[1649,4641,4643],{"id":4642},"i-test-facili-alzano-i-numeri-quelli-difficili-salvano-il-prodotto","I test facili alzano i numeri, quelli difficili salvano il prodotto",[12,4645,4646],{},"Testare un getter che restituisce un campo è facile. La coverage aumenta. Testare il flusso di pagamento completo con gestione degli errori, retry, e rollback è difficile. Aggiunge poca coverage, ma è il test che ti salva quando qualcosa va storto.",[12,4648,4649],{},"La tendenza naturale è scrivere molti test facili, veloci da scrivere e utili ad alzare la metrica, e pochi test difficili che richiedono setup e ragionamento. Il risultato è una suite che dà una falsa sensazione di sicurezza.",[1649,4651,4653],{"id":4652},"il-100-è-un-obiettivo-che-raramente-ha-senso-economico","Il 100% è un obiettivo che raramente ha senso economico",[12,4655,4656],{},"Passare dal 70% all’80% è relativamente economico. Dall’80% al 90% lo sforzo cresce in modo significativo. Dal 90% al 100% lo sforzo tende a diventare sproporzionato rispetto al valore aggiunto.",[12,4658,4659],{},"Quell’ultimo tratto include casi molto rari che difficilmente vedrai in produzione. Il tempo che il team spende a inseguire il 100% è tempo che non spende a testare i flussi critici in modo più approfondito.",[30,4661,4663],{"id":4662},"quali-test-servono-davvero","Quali test servono davvero",[1649,4665,4667],{"id":4666},"i-flussi-che-fanno-guadagnare-soldi","I flussi che fanno guadagnare soldi",[12,4669,4670],{},"Registrazione, login, pagamento, le azioni core del tuo prodotto. Se questi si rompono, perdi utenti e ricavi. Testali in modo approfondito: happy path, errori comuni, casi limite realistici e integrazioni reali. Pochi test ben scritti qui valgono più di molti test su utilità secondarie.",[1649,4672,4674],{"id":4673},"le-integrazioni-con-sistemi-esterni","Le integrazioni con sistemi esterni",[12,4676,4677],{},"API di terze parti, gateway di pagamento, servizi di email, storage — tutto ciò che è fuori dal tuo controllo. Qui è dove le cose tendono a rompersi più spesso: API che cambiano, timeout diversi, formati non documentati. I test di integrazione che verificano il comportamento reale — non mock — sono tra i più preziosi che puoi avere.",[1649,4679,4681],{"id":4680},"i-casi-che-ti-fanno-perdere-soldi","I casi che ti fanno perdere soldi",[12,4683,4684],{},"Un utente viene addebitato due volte? Un ordine viene perso? I dati personali finiscono esposti? Questi scenari hanno un costo sproporzionato rispetto alla loro frequenza. Un test che previene un doppio addebito può valere più di decine di test su logica secondaria. Identifica gli scenari più rischiosi per il tuo business e dedica particolare attenzione a testarli.",[1649,4686,4688],{"id":4687},"le-regressioni-dopo-ogni-bug-in-produzione","Le regressioni dopo ogni bug in produzione",[12,4690,4691],{},"Ogni bug significativo che arriva in produzione dovrebbe generare un test. Non per coverage — per prevenzione. Se è successo una volta, può succedere di nuovo. Il test riduce significativamente la probabilità che si ripresenti.",[12,4693,4694,4695,103],{},"Nel tempo, questa pratica costruisce una suite che copre i problemi reali del tuo prodotto. Ed è anche ciò che rende possibile il ",[133,4696,4697],{"href":1089},"refactoring sicuro invece della riscrittura da zero",[30,4699,4701],{"id":4700},"cosa-dire-al-team-e-al-pm","Cosa dire al team (e al PM)",[12,4703,4704],{},"Se gestisci un team e la coverage è diventata un obiettivo, la prima cosa da fare è smettere di fissare target numerici rigidi. Un 90% come traguardo rischia di incentivare test scritti per alzare un numero invece che per proteggere davvero il prodotto. Ha molto più senso spingere il team a coprire bene i flussi critici.",[12,4706,4707],{},"La domanda utile non è “quanta coverage abbiamo?”, ma “questo test che cosa protegge?”. Quando vengono aggiunti nuovi test, vale la pena chiedere quale scenario stanno prevenendo. Se la risposta è solo “alza la coverage”, probabilmente quel test non serve molto.",[12,4709,4710,4711,4714],{},"Conta anche mettere a budget il tempo per i test giusti. I test di integrazione richiedono più tempo per essere scritti e mantenuti, e proprio per questo sono i primi a saltare quando il team è ",[133,4712,4713],{"href":301},"sotto pressione sulle stime",". Infine, la metrica che conta davvero resta un’altra: quanti bug arrivano in produzione.",[30,4716,4718],{"id":4717},"il-testing-è-un-investimento-non-una-cerimonia","Il testing è un investimento, non una cerimonia",[12,4720,4721,4722,103],{},"I test sono codice. Vanno scritti, mantenuti, eseguiti, e ogni tanto riscritti. Sono un costo — un costo che si ripaga prevenendo problemi più costosi. Ma solo se testano le cose giuste. Senza una buona suite di test sui flussi critici, il deploy diventa una roulette e il team finisce per avere ",[133,4723,4724],{"href":1081},"paura di rilasciare",[12,4726,4727],{},"Un team con il 40% di coverage concentrata sui flussi critici è spesso in una posizione più solida di un team con il 95% distribuita uniformemente su codice che non ha impatto diretto sul business.",[12,4729,4730],{},"La coverage è un indicatore, non l’obiettivo. I test servono a proteggere il prodotto, non a riempire una metrica. L’obiettivo è un prodotto che continua a funzionare anche quando il codice cambia.",{"title":199,"searchDepth":200,"depth":200,"links":4732},[4733,4738,4744,4745],{"id":4631,"depth":200,"text":4632,"children":4734},[4735,4736,4737],{"id":4635,"depth":1768,"text":4636},{"id":4642,"depth":1768,"text":4643},{"id":4652,"depth":1768,"text":4653},{"id":4662,"depth":200,"text":4663,"children":4739},[4740,4741,4742,4743],{"id":4666,"depth":1768,"text":4667},{"id":4673,"depth":1768,"text":4674},{"id":4680,"depth":1768,"text":4681},{"id":4687,"depth":1768,"text":4688},{"id":4700,"depth":200,"text":4701},{"id":4717,"depth":200,"text":4718},"Testing","2026-02-05","Test coverage al 100%: cosa misura davvero e cosa no. Puoi avere numeri altissimi e non testare nulla di utile. Come capire quali test proteggono il prodotto.","/images/blog/test-coverage-cosa-misura.jpg",{},"/blog/2026-02-05-test-coverage-cosa-misura",{"title":4618,"description":4748},"Test coverage: cosa misura davvero (e cosa no)","test-coverage-cosa-misura","blog/2026-02-05-test-coverage-cosa-misura",[4757,1617,228,227],"testing","1fY6K0llc3G_mv8m7qWlKTd1iHr4Ypwx8BjO7Qa7OlI",{"id":4760,"title":4761,"body":4762,"category":210,"date":4943,"description":4944,"extension":213,"image":4945,"meta":4946,"navigation":3,"path":4947,"published":3,"seo":4948,"seoTitle":4949,"slug":4950,"stem":4951,"tags":4952,"updated":229,"__hash__":4954},"blog/blog/2026-02-03-cos-e-un-mvp-software.md","Cos'è un MVP software: significato, esempi e come farlo bene",{"type":9,"value":4763,"toc":4931},[4764,4769,4772,4776,4790,4797,4808,4812,4820,4823,4826,4829,4833,4837,4840,4843,4847,4850,4857,4861,4868,4875,4879,4882,4885,4892,4895,4899,4906,4911,4914,4918,4925,4928],[12,4765,4766],{},[16,4767,4768],{},"\"È solo un MVP.\" Questa frase è diventata, in molti casi, una giustificazione per rilasciare software con qualità discutibile. Pagine che caricano in 8 secondi? MVP. Bug nei flussi principali? MVP. Interfaccia che confonde gli utenti? MVP. Come se aggiungere \"minimum viable\" davanti a \"product\" rendesse accettabile un prodotto che non funziona.",[12,4770,4771],{},"Il concetto di MVP software, cioè la versione più piccola di un prodotto che abbia comunque senso usare, è stato uno dei contributi più importanti alla cultura startup. Ed è anche uno dei più fraintesi. Fraintenderlo non è solo un errore teorico — è un errore che brucia soldi, utenti, e credibilità.",[30,4773,4775],{"id":4774},"cosa-significa-davvero-mvp","Cosa significa davvero MVP",[12,4777,4778,4779,4782,4783,4786,4787,103],{},"Eric Ries, che ha reso popolare il termine, lo definisce come il prodotto con il ",[16,4780,4781],{},"minimo set di feature"," che permette di raccogliere il ",[16,4784,4785],{},"massimo di apprendimento validato"," con il ",[16,4788,4789],{},"minimo sforzo",[12,4791,4792,4793,4796],{},"La parola chiave è ",[16,4794,4795],{},"viable",". Non minimum. Viable. Il prodotto deve funzionare. Deve risolvere un problema reale per un utente reale. Deve farlo in modo affidabile.",[12,4798,4799,4800,4803,4804,4807],{},"\"Minimum\" si riferisce allo ",[16,4801,4802],{},"scope",", non alla ",[16,4805,4806],{},"qualità",". Fai poche cose, ma falle bene. Un'app che fa una sola cosa perfettamente è un MVP. Un'app che fa dieci cose tutte male difficilmente può essere considerata un MVP: è più simile a un prototipo portato in produzione troppo presto.",[30,4809,4811],{"id":4810},"come-si-riconosce-un-falso-mvp","Come si riconosce un falso MVP",[12,4813,4814,4815,4819],{},"Un falso MVP di solito si riconosce subito. È lento: se la tua web app ci mette più di tre secondi a caricare, stai testando la pazienza degli utenti più che l’idea. Per chi la usa non esiste la distinzione tra “è lento perché è un MVP” ed “è lento perché è fatto male”. Esiste solo la lentezza, e quindi l’abbandono. Per questo le performance fanno parte del “viable”: una ",[133,4816,4818],{"href":4817},"/blog/web-app-lenta-problema-database","web app lenta"," difficilmente può esserlo davvero.",[12,4821,4822],{},"Un falso MVP ha anche bug nei flussi principali. Se il tuo tool di prenotazione fallisce una volta su cinque, non stai validando il valore della tua idea, ma solo la tolleranza degli utenti agli errori. Le feature secondarie possono mancare, ma quelle presenti devono funzionare.",[12,4824,4825],{},"Spesso poi nessuno capisce cosa fa. Se gli utenti arrivano e in dieci secondi non capiscono a cosa serve e come si usa, il problema è l’esperienza confusa. Un MVP con una sola funzionalità chiara vale più di un prodotto pieno di parti incomprensibili.",[12,4827,4828],{},"Infine c’è la formula “lo miglioriamo dopo”, che di solito è solo il nome elegante di un debito tecnico che non verrà mai ripagato. Dopo arriverà sempre qualcos’altro. Se non hai il tempo di farlo bene adesso, difficilmente lo troverai in seguito.",[30,4830,4832],{"id":4831},"il-costo-reale-di-un-mvp-di-bassa-qualità","Il costo reale di un MVP di bassa qualità",[1649,4834,4836],{"id":4835},"bruci-i-primi-utenti","Bruci i primi utenti",[12,4838,4839],{},"I primi utenti sono i più preziosi. Sono quelli che ti hanno dato fiducia prima che tu avessi credibilità. Sono quelli che ti danno feedback onesto. Sono quelli che, se soddisfatti, diventano evangelisti del tuo prodotto.",[12,4841,4842],{},"Se il tuo MVP li accoglie con bug, lentezza e confusione, non torneranno. E non ti diranno perché — spariranno silenziosamente. Peggio: diranno ad altri di non provare il tuo prodotto. Il passaparola negativo tende a diffondersi più velocemente di quello positivo.",[1649,4844,4846],{"id":4845},"i-dati-che-raccogli-non-valgono-nulla","I dati che raccogli non valgono nulla",[12,4848,4849],{},"Lo scopo dell'MVP è imparare. Ma cosa impari da un prodotto che non funziona? Se gli utenti abbandonano perché la pagina è lenta, non hai validato che l'idea non funziona — hai validato che un prodotto rotto non piace a nessuno.",[12,4851,4852,4853,4856],{},"Per raccogliere dati validi, il prodotto deve funzionare abbastanza bene da far sì che le decisioni degli utenti riflettano ",[16,4854,4855],{},"il valore della tua idea",", non la qualità dell'implementazione.",[1649,4858,4860],{"id":4859},"accumuli-debito-dal-giorno-zero","Accumuli debito dal giorno zero",[12,4862,4863,4864,4867],{},"Un MVP scritto in fretta e senza struttura diventa la base su cui costruisci tutto il resto. Ogni feature successiva si appoggia su fondamenta fragili. ",[133,4865,4866],{"href":135},"Il debito tecnico si accumula"," prima ancora di aver validato l'idea.",[12,4869,4870,4871,4874],{},"Se l'idea funziona, ti trovi a dover ",[133,4872,4873],{"href":1089},"riscrivere"," tutto dopo sei mesi. Se non funziona, hai sprecato lo stesso tempo che avresti sprecato facendolo bene — perché spesso la differenza di tempo tra un MVP fatto bene e uno fatto male è molto più legata allo scope che alla qualità del codice.",[30,4876,4878],{"id":4877},"come-fare-un-mvp-vero","Come fare un MVP vero",[12,4880,4881],{},"La regola di base è tagliare feature, non qualità. Siediti con il team, fai la lista di tutto ciò che il prodotto “dovrebbe” avere e poi elimina quasi tutto. Tieni solo quello che serve a rispondere alla domanda più importante per il business in quel momento. Se la domanda è “gli utenti pagheranno per prenotare lezioni online?”, allora bastano registrazione, pagamento e prenotazione. Chat, recensioni, programma fedeltà, analytics e notifiche possono aspettare.",[12,4883,4884],{},"Prima ancora di scrivere codice, però, conviene definire cosa vuoi imparare. Una frase semplice del tipo “Con questo MVP vogliamo capire se…” basta a guidare tutte le scelte di scope. Ogni feature proposta andrebbe giudicata in base a quella domanda.",[12,4886,4887,4888,4891],{},"Ci sono poi fondamenta che non conviene tagliare: performance, sicurezza, affidabilità dei flussi principali e una struttura del codice che permetta di evolvere senza ricominciare da capo. Non serve un’architettura enterprise, ma serve un ",[133,4889,4890],{"href":4485},"monolite ben strutturato",", con codice pulito, test sui flussi critici e un database che risponda in tempi ragionevoli.",[12,4893,4894],{},"Infine, un MVP ha bisogno di un limite temporale. Datti un timebox chiaro: per esempio quattro settimane, al termine delle quali si rilascia quello che si è riusciti a completare bene. Se in quel tempo non sei riuscito a costruire abbastanza per validare l’idea, probabilmente l’idea stessa è troppo complessa per un MVP.",[30,4896,4898],{"id":4897},"la-differenza-tra-un-mvp-e-un-prototipo","La differenza tra un MVP e un prototipo",[12,4900,4901,4902,4905],{},"Un ",[16,4903,4904],{},"prototipo"," è un esperimento interno. Serve a esplorare un'idea, capire la fattibilità tecnica e mostrare qualcosa agli stakeholder. Può essere brutto, fragile, incompleto. Non va in produzione.",[12,4907,4901,4908,4910],{},[16,4909,3972],{}," va in produzione, viene usato da persone reali e le loro decisioni influenzano il futuro del tuo business. Per questo deve funzionare.",[12,4912,4913],{},"Se quello che hai in produzione è un prototipo che hai chiamato MVP per giustificarne la qualità, sii onesto con te stesso. O lo trasformi in un prodotto viable, o lo chiami quello che è.",[30,4915,4917],{"id":4916},"minimum-viable-non-è-minimum-effort","Minimum viable non è minimum effort",[12,4919,4920,4921,4924],{},"Lo scope minimo non implica lo sforzo minimo. Implica lo sforzo ",[16,4922,4923],{},"focalizzato",". Tutta l'energia del team concentrata su poche cose fatte bene, invece di tante cose fatte male.",[12,4926,4927],{},"I migliori MVP che ho visto facevano una sola cosa. Ma la facevano in modo impeccabile: veloce, affidabile, chiaro. Gli utenti non si chiedevano “cos’altro dovrebbe fare”, ma “dove firmo per pagare”.",[12,4929,4930],{},"Quello è un MVP. Tutto il resto rischia di essere una scorciatoia che nel medio periodo si paga.",{"title":199,"searchDepth":200,"depth":200,"links":4932},[4933,4934,4935,4940,4941,4942],{"id":4774,"depth":200,"text":4775},{"id":4810,"depth":200,"text":4811},{"id":4831,"depth":200,"text":4832,"children":4936},[4937,4938,4939],{"id":4835,"depth":1768,"text":4836},{"id":4845,"depth":1768,"text":4846},{"id":4859,"depth":1768,"text":4860},{"id":4877,"depth":200,"text":4878},{"id":4897,"depth":200,"text":4898},{"id":4916,"depth":200,"text":4917},"2026-02-03","Cos'è un MVP software e come svilupparlo senza bruciare i primi utenti: significato reale di 'minimum viable product', esempi, principi di qualità e trappole.","/images/blog/cos-e-un-mvp-software.jpg",{},"/blog/2026-02-03-cos-e-un-mvp-software",{"title":4761,"description":4944},"MVP software: cos'è, significato, esempi pratici","cos-e-un-mvp-software","blog/2026-02-03-cos-e-un-mvp-software",[2517,3882,2353,4953,1134],"validazione-idea","vu6EFw8f9GsZwI5IrJFvDUy2U0uVBD8iX6bdttQbl5g",{"id":4956,"title":4957,"body":4958,"category":210,"date":5119,"description":5120,"extension":213,"image":5121,"meta":5122,"navigation":3,"path":5123,"published":3,"seo":5124,"seoTitle":5125,"slug":5126,"stem":5127,"tags":5128,"updated":229,"__hash__":5132},"blog/blog/2026-01-29-stime-sviluppo-sbagliate-perche.md","Stime di sviluppo software: perché sbagliano e come migliorare",{"type":9,"value":4959,"toc":5103},[4960,4966,4969,4973,4977,4984,4987,4991,4998,5001,5005,5008,5012,5016,5023,5030,5034,5041,5045,5048,5052,5059,5063,5066,5069,5076,5082,5086,5093,5097,5100],[12,4961,4962,4965],{},[16,4963,4964],{},"\"Quanto ci vuole?\" è la domanda più frequente che chi gestisce un prodotto fa al team di sviluppo."," Ed è anche la domanda a cui il team fatica a rispondere in modo davvero onesto, perché la risposta più corretta molto spesso sarebbe: \"dipende da ciò che scopriremo mentre lo facciamo\".",[12,4967,4968],{},"Le stime sviluppo software sono spesso imprecise. Non per caso — ma per motivi strutturali. E non perché il team è incompetente, pigro, o disonesto. Sono imprecise per motivi intrinseci al modo in cui funziona lo sviluppo software. Capire perché cambia completamente il modo in cui dovresti pianificare.",[30,4970,4972],{"id":4971},"perché-le-stime-funzionano-peggio-di-quanto-ci-aspettiamo","Perché le stime funzionano peggio di quanto ci aspettiamo",[1649,4974,4976],{"id":4975},"lo-sviluppo-software-è-ricerca-non-costruzione","Lo sviluppo software è ricerca, non costruzione",[12,4978,4979,4980,4983],{},"Quando costruisci una casa, sai quanti mattoni servono. Hai fatto case simili prima. I materiali hanno specifiche note. Le incognite sono poche e gestibili. Lo sviluppo software non funziona così. Ogni feature è diversa dalla precedente. Le incognite emergono ",[16,4981,4982],{},"durante"," lo sviluppo, non prima. L'integrazione con quel servizio esterno sembrava semplice nella documentazione ma ha tre casi limite non documentati. Il framework gestisce quel pattern in modo diverso da quello che il team si aspettava. Il requisito \"semplice\" nascondeva una complessità che nessuno poteva prevedere finché non ci si è messo le mani.",[12,4985,4986],{},"Chiedere una stima precisa per alcune attività di sviluppo software è più simile a un’attività di ricerca che a un lavoro ripetitivo. Può darti un'ipotesi ragionevole, ma le incognite sono l'essenza del lavoro.",[1649,4988,4990],{"id":4989},"leffetto-dellottimismo-strutturale","L'effetto dell'ottimismo strutturale",[12,4992,4993,4994,4997],{},"Gli sviluppatori, quando stimano, pensano allo ",[16,4995,4996],{},"scenario migliore",". Il percorso senza ostacoli. Il codice che funziona al primo tentativo. L'integrazione che va liscia. I test che passano subito. È come funziona il cervello umano con le stime, indipendentemente dall'onestà di chi stima. Si chiama planning fallacy, cioè la tendenza a sottostimare sistematicamente il tempo necessario, anche quando abbiamo già vissuto casi simili che hanno richiesto più tempo.",[12,4999,5000],{},"Il risultato: le stime del team sono quasi sempre il lower bound, non la media. Il tempo reale sarà tra 1.5x e 3x la stima, con una distribuzione asimmetrica verso l'alto. Raramente un task finisce in metà del tempo stimato, mentre è molto più comune che richieda molto più tempo del previsto, a volte anche il triplo.",[1649,5002,5004],{"id":5003},"i-requisiti-cambiano-quasi-sempre","I requisiti cambiano (quasi sempre)",[12,5006,5007],{},"Anche se la stima fosse perfetta al momento in cui viene fatta — e non lo è — i requisiti cambiano durante lo sviluppo. Il PM vede un prototipo e vuole una modifica. Chi guida l'azienda parla con un cliente e cambia priorità. Il designer nota un problema di UX e propone un'alternativa. Ogni cambio invalida la stima originale. E i cambi sono inevitabili: sono il segno che il team sta imparando man mano che il prodotto prende forma.",[30,5009,5011],{"id":5010},"cosa-fare-al-posto-delle-stime-tradizionali","Cosa fare al posto delle stime tradizionali",[1649,5013,5015],{"id":5014},"lavora-per-incrementi-piccoli","Lavora per incrementi piccoli",[12,5017,5018,5019,5022],{},"Invece di stimare un progetto di 3 mesi, chiediti: ",[16,5020,5021],{},"qual è la cosa più piccola che possiamo rilasciare in 1-2 settimane che ci dà informazioni utili?"," Non un prototipo incompleto. Una versione ridotta ma funzionante che un utente reale può usare. Poi, sulla base di quello che impari, pianifica il passo successivo.",[12,5024,5025,5026,5029],{},"Questo approccio non elimina l'incertezza. La rende ",[16,5027,5028],{},"gestibile",". Invece di una grande scommessa su una stima inevitabilmente incerta, fai piccole scommesse frequenti con feedback rapido.",[1649,5031,5033],{"id":5032},"usa-intervalli-non-numeri-singoli","Usa intervalli, non numeri singoli",[12,5035,5036,5037,5040],{},"Se proprio serve una stima, chiedi un intervallo: ",[16,5038,5039],{},"\"caso migliore, caso realistico, caso peggiore\"",". Il caso migliore è quello che il team ti dice spontaneamente. Il caso realistico è 2x. Il caso peggiore è 3-4x. Pianifica per il caso realistico, metti a budget il caso peggiore. Se va meglio del previsto, hai guadagnato tempo. Se va peggio, sei coperto.",[1649,5042,5044],{"id":5043},"misura-la-velocità-storica-non-le-stime-future","Misura la velocità storica, non le stime future",[12,5046,5047],{},"Dopo qualche mese di lavoro, il team avrà dati reali su quanto tempo richiedono diversi tipi di task. Usa quei dati. \"Task simili a questo in passato hanno richiesto tra 3 e 8 giorni\" è molto più affidabile di \"penso che ci vogliano 4 giorni\". Non è perfetto, ma è basato sulla realtà invece che sull'ottimismo.",[1649,5049,5051],{"id":5050},"separa-la-scoperta-dallesecuzione","Separa la scoperta dall'esecuzione",[12,5053,5054,5055,5058],{},"Per feature complesse o nuove, aggiungi una fase di ",[16,5056,5057],{},"spike",", cioè un breve blocco di esplorazione tecnica: un timebox di 2-3 giorni in cui il team esplora il problema, prototipa le parti rischiose e identifica le incognite. Solo dopo lo spike puoi chiedere una stima, e sarà enormemente più accurata perché le incognite principali sono già emerse.",[30,5060,5062],{"id":5061},"il-costo-delle-stime-sbagliate","Il costo delle stime sbagliate",[12,5064,5065],{},"Per chi gestisce budget e roadmap, le stime sbagliate hanno un costo molto concreto. Il primo è fatto di promesse non mantenute: dici al cliente che la feature sarà pronta in sei settimane, il team la consegna in quattordici e la credibilità che si brucia è quella dell’azienda intera.",[12,5067,5068],{},"Il secondo costo riguarda la pianificazione. Se ogni progetto sfora del 100 o 200 per cento, come pianifichi il trimestre, come allochi le risorse, come fai previsioni finanziarie? Stai costruendo piani sopra numeri che sai già essere troppo fragili.",[12,5070,5071,5072,5075],{},"Poi c’è la pressione sul team. Quando la stima viene trattata come una deadline, il gruppo taglia qualità per rispettarla: meno test, meno refactoring, più scorciatoie. Il ",[133,5073,5074],{"href":135},"debito tecnico si accumula",", e dopo sei mesi tutto procede ancora più lentamente.",[12,5077,5078,5079,103],{},"Infine arriva il feature bloat. Senza la disciplina degli incrementi piccoli, la tendenza è pianificare feature grandi e complete. Se qualcosa va storto, e succede spesso, hai investito mesi in qualcosa di inutilizzabile perché incompleto. È l’opposto dell’approccio ",[133,5080,5081],{"href":2005},"lancia prima, migliora dopo",[30,5083,5085],{"id":5084},"la-conversazione-che-dovresti-avere-col-tuo-team","La conversazione che dovresti avere col tuo team",[12,5087,5088,5089,5092],{},"Smetti di chiedere \"quanto ci vuole\" e inizia a chiedere qual è la versione più piccola di quella feature che ha davvero valore, perché costringe il team a pensare per incrementi e non per monoliti. Chiedi anche quali sono le incognite principali: se il team identifica i rischi prima di stimare, le stime migliorano. Ha senso domandare cosa si può mostrare già tra una settimana, così il focus resta sui progressi tangibili, e di cosa il team ha bisogno per andare più veloce. A volte la risposta non è “più tempo”, ma ",[133,5090,5091],{"href":1292},"meno interruzioni",", meno meeting e meno cambi di priorità.",[30,5094,5096],{"id":5095},"è-un-problema-di-aspettative","È un problema di aspettative",[12,5098,5099],{},"Le stime nel software difficilmente diventeranno precise come in altri ambiti. Tool migliori, processi più rigidi e sviluppatori più esperti aiutano fino a un certo punto: l'incertezza resta intrinseca a questo tipo di lavoro. Quello che può migliorare è come gestiamo quell'incertezza. Incrementi piccoli, feedback rapido, aspettative realistiche, e la volontà di adattarsi man mano che impariamo.",[12,5101,5102],{},"Le aziende che lo capiscono rilasciano più spesso, con meno sorprese, e con team più sereni. Quelle che continuano a chiedere stime precise e a trattarle come promesse finiscono molto spesso per creare aspettative che poi è difficile rispettare.",{"title":199,"searchDepth":200,"depth":200,"links":5104},[5105,5110,5116,5117,5118],{"id":4971,"depth":200,"text":4972,"children":5106},[5107,5108,5109],{"id":4975,"depth":1768,"text":4976},{"id":4989,"depth":1768,"text":4990},{"id":5003,"depth":1768,"text":5004},{"id":5010,"depth":200,"text":5011,"children":5111},[5112,5113,5114,5115],{"id":5014,"depth":1768,"text":5015},{"id":5032,"depth":1768,"text":5033},{"id":5043,"depth":1768,"text":5044},{"id":5050,"depth":1768,"text":5051},{"id":5061,"depth":200,"text":5062},{"id":5084,"depth":200,"text":5085},{"id":5095,"depth":200,"text":5096},"2026-01-29","Le stime di sviluppo software falliscono per motivi strutturali. Cosa chiedere al team al posto di 'quanto ci vuole' e come pianificare con meno sorprese.","/images/blog/stime-sviluppo-sbagliate-perche.jpg",{},"/blog/2026-01-29-stime-sviluppo-sbagliate-perche",{"title":4957,"description":5120},"Stime sviluppo software: perché sbagliano e cosa fare","stime-sviluppo-sbagliate-perche","blog/2026-01-29-stime-sviluppo-sbagliate-perche",[5129,2355,3401,5130,5131],"stime-sviluppo","planning-fallacy","budget-tempo","TjLPFaqrbJ9MMC5q29P1cSb09N3FTjHxwsyjtSG6joE",{"id":5134,"title":5135,"body":5136,"category":5298,"date":5299,"description":5300,"extension":213,"image":5301,"meta":5302,"navigation":3,"path":5303,"published":3,"seo":5304,"seoTitle":5305,"slug":5306,"stem":5307,"tags":5308,"updated":229,"__hash__":5312},"blog/blog/2026-01-27-dipendenze-open-source-costo-nascosto.md","Dipendenze open source: il costo nascosto che non vedi nell'invoice",{"type":9,"value":5137,"toc":5283},[5138,5147,5150,5154,5158,5164,5167,5170,5174,5177,5180,5193,5197,5202,5205,5209,5216,5220,5223,5226,5230,5233,5237,5247,5251,5258,5260,5263,5269,5272,5274,5280],[12,5139,5140],{},[16,5141,5142,5143,5146],{},"Le dipendenze open source sono ovunque nel tuo progetto. Il tuo progetto ha 47 dipendenze dirette. Quelle 47 dipendenze hanno 847 dipendenze transitive, cioè pacchetti che non hai scelto tu direttamente ma che arrivano insieme agli altri. Ognuna di queste è mantenuta da qualcuno che non conosci, che potrebbe smettere domani, e il cui codice finisce direttamente nel tuo processo di build e nel software che metti in produzione. ",[595,5144,5145],{},"npm install"," è gratis. Tutto il resto no.",[12,5148,5149],{},"C'è un paradosso nell'open source: lo usiamo perché è gratuito, affidabile e comunitario. Ma gratuito non significa senza costi, affidabile non significa per sempre, e comunitario non significa che qualcuno si prende la responsabilità quando qualcosa va storto.",[30,5151,5153],{"id":5152},"il-costo-che-non-vedi","Il costo che non vedi",[1649,5155,5157],{"id":5156},"manutenzione-continua","Manutenzione continua",[12,5159,5160,5161,103],{},"Ogni dipendenza nel tuo progetto è codice che qualcun altro ha scritto e che tu devi mantenere aggiornato. Non perché vuoi le ultime feature — perché ogni versione non aggiornata è un potenziale problema di ",[133,5162,5163],{"href":3144},"sicurezza",[12,5165,5166],{},"Un progetto Laravel o React reale può facilmente arrivare a centinaia di dipendenze tra dirette e transitive. Anche un sito molto semplice può superare diverse centinaia di pacchetti installati. Pensi che stia esagerando il conteggio? Questo piccolo sito web ha un totale di 788 dipendenze tra dirette e transitive! Molte rilasciano aggiornamenti frequenti, alcune introducono breaking changes, e nel tempo possono emergere vulnerabilità.",[12,5168,5169],{},"Il tempo che il tuo team spende ad aggiornare dipendenze, verificare compatibilità, risolvere conflitti di versione e testare che nulla si sia rotto è tempo che non spende sulle feature. Ed è un costo ricorrente: non finisce mai.",[1649,5171,5173],{"id":5172},"vulnerabilità-nella-supply-chain","Vulnerabilità nella supply chain",[12,5175,5176],{},"Nel 2024, l'attacco a xz/liblzma ha dimostrato che un singolo maintainer compromesso può inserire una backdoor in una libreria usata da milioni di sistemi. Non è un caso isolato, ma un esempio concreto di quanto la supply chain open source possa essere un punto delicato.",[12,5178,5179],{},"Il tuo progetto dipende da centinaia di pacchetti. Tu verifichi quelli che installi direttamente. Ma verifichi anche le loro dipendenze? E le dipendenze delle dipendenze? Un attaccante non deve compromettere il pacchetto più popolare — basta una libreria di utility sepolta tre livelli sotto che nessuno guarda.",[12,5181,5182,4080,5185,5188,5189,5192],{},[595,5183,5184],{},"npm audit",[595,5186,5187],{},"composer audit"," trovano le vulnerabilità ",[16,5190,5191],{},"note",". Quelle che non sono state ancora scoperte — o che sono state inserite intenzionalmente — passano inosservate.",[1649,5194,5196],{"id":5195},"il-rischio-di-abbandono","Il rischio di abbandono",[12,5198,5199,5200,103],{},"L'open source dipende dalla volontà di individui. Maintainer che lavorano gratis nel tempo libero, che possono stancarsi, cambiare lavoro, o semplicemente perdere interesse. Quando un pacchetto viene abbandonato, hai tre opzioni: forkarlo e mantenerlo tu (costo enorme), migrare a un'alternativa (costo significativo), o restare su una versione non mantenuta (rischio crescente). Nessuna è gratuita. E se la dipendenza critica la conosce solo una persona nel team, hai anche un bel problema di ",[133,5201,574],{"href":573},[12,5203,5204],{},"E non parliamo di pacchetti oscuri. Librerie molto popolari sono state abbandonate, oppure hanno cambiato maintainer nel tempo senza che la maggior parte degli utilizzatori se ne accorgesse. Il tuo package-lock.json potrebbe contenere rischi di cui non sospetti l’esistenza.",[30,5206,5208],{"id":5207},"meno-è-meglio-il-principio-della-dipendenza-minima","Meno è meglio: il principio della dipendenza minima",[12,5210,5211,5212,5215],{},"La soluzione è usare l'open source ",[16,5213,5214],{},"con consapevolezza",", non rinunciarci.",[1649,5217,5219],{"id":5218},"chiediti-mi-serve-davvero","Chiediti: mi serve davvero?",[12,5221,5222],{},"Prima di aggiungere una dipendenza, la domanda è: posso fare la stessa cosa con il linguaggio o il framework che ho già? Un pacchetto per formattare le date? Forse le API native del linguaggio bastano. Un pacchetto per validare le email? Spesso poche righe di codice ben scritte possono coprire il tuo caso d’uso senza introdurre un’ulteriore dipendenza. Un pacchetto per fare il left-pad di una stringa? Quella è una riga di codice.",[12,5224,5225],{},"Ogni dipendenza che non aggiungi è una dipendenza che non devi manutenere, aggiornare, e monitorare. Il codice più sicuro e più affidabile è quello che non esiste.",[1649,5227,5229],{"id":5228},"valuta-la-salute-del-pacchetto","Valuta la salute del pacchetto",[12,5231,5232],{},"Se decidi che una dipendenza serve, guardane prima lo stato reale. Conta quanti maintainer ha, perché se ne dipende uno solo il rischio di abbandono è alto. Guarda quando è stato aggiornato l’ultima volta: se l’ultimo commit è di un anno fa, vale la pena fermarsi un attimo. Controlla se esiste una policy di sicurezza e chiediti quante dipendenze transitive porta con sé, perché ogni pacchetto aggiuntivo aumenta il tuo livello di esposizione.",[1649,5234,5236],{"id":5235},"blocca-le-versioni","Blocca le versioni",[12,5238,5239,5240,4080,5243,5246],{},"Non fidarti di ",[595,5241,5242],{},"^",[595,5244,5245],{},"~"," nel tuo file di dipendenze. Un minor update \"compatibile\" può introdurre bug o cambiamenti di comportamento. Usa lockfile (sempre), e aggiorna manualmente con test dopo ogni update.",[1649,5248,5250],{"id":5249},"monitora-automaticamente","Monitora automaticamente",[12,5252,5253,5254,5257],{},"Attiva Dependabot su GitHub. Non per aggiornare automaticamente — per essere ",[16,5255,5256],{},"informato"," quando escono aggiornamenti e vulnerabilità. L'aggiornamento lo fai tu, consapevolmente, dopo aver testato.",[30,5259,3056],{"id":3055},[12,5261,5262],{},"Per chi gestisce budget e roadmap, le dipendenze open source sono un costo operativo nascosto. C’è innanzitutto il tempo del team: aggiornare pacchetti, risolvere conflitti, gestire deprecation. In un progetto maturo questa attività può consumare una parte rilevante della capacità di sviluppo, anche se spesso non compare in nessun ticket visibile.",[12,5264,5265,5266,103],{},"Poi c’è il rischio di incidenti. Una vulnerabilità critica in una dipendenza può costringere a un aggiornamento d’emergenza: il team lascia tutto quello che sta facendo, testa la compatibilità, deploya, e brucia un pomeriggio o una giornata intera. Quel tempo perso peggiora ancora di più le ",[133,5267,5268],{"href":301},"stime di sviluppo già fragili",[12,5270,5271],{},"Infine esiste un lock-in invisibile, cioè una dipendenza crescente da scelte fatte da altri. Più dipendenze hai, più il progetto è legato a decisioni di terzi. Quando un pacchetto cambia API, depreca feature o cambia licenza, devi adattarti ai loro tempi e alle loro scelte.",[30,5273,3088],{"id":3087},[12,5275,5276,5277],{},"Per ogni dipendenza nel tuo progetto, dovresti poter rispondere a questa domanda: ",[16,5278,5279],{},"\"Se domani questo pacchetto sparisse, quanto ci costerebbe?\"",[12,5281,5282],{},"Se la risposta è “nulla, lo riscrivo in un’ora”, allora va bene averlo: ti sta davvero facendo risparmiare tempo. Se la risposta è “settimane di lavoro”, allora hai un rischio che dovresti gestire in modo attivo, con un fork interno, un piano di migrazione o almeno con una consapevolezza chiara di cosa perderesti. Se la risposta è “non lo so”, è il momento di scoprirlo prima che te lo faccia scoprire un problema in produzione.",{"title":199,"searchDepth":200,"depth":200,"links":5284},[5285,5290,5296,5297],{"id":5152,"depth":200,"text":5153,"children":5286},[5287,5288,5289],{"id":5156,"depth":1768,"text":5157},{"id":5172,"depth":1768,"text":5173},{"id":5195,"depth":1768,"text":5196},{"id":5207,"depth":200,"text":5208,"children":5291},[5292,5293,5294,5295],{"id":5218,"depth":1768,"text":5219},{"id":5228,"depth":1768,"text":5229},{"id":5235,"depth":1768,"text":5236},{"id":5249,"depth":1768,"text":5250},{"id":3055,"depth":200,"text":3056},{"id":3087,"depth":200,"text":3088},"DevOps","2026-01-27","Le dipendenze open source nel tuo progetto costano più di quello che pensi: manutenzione, sicurezza, rischio abbandono. npm install è gratis, il resto no.","/images/blog/dipendenze-open-source-costo-nascosto.jpg",{},"/blog/2026-01-27-dipendenze-open-source-costo-nascosto",{"title":5135,"description":5300},"Dipendenze open source: il costo nascosto nel progetto","dipendenze-open-source-costo-nascosto","blog/2026-01-27-dipendenze-open-source-costo-nascosto",[5309,5163,5310,5311,228],"open-source","dipendenze","npm","3uEV4U18-9OpSQVklz3bwmQIRyGx4KdKDZklCByWV4w",{"id":5314,"title":5315,"body":5316,"category":1784,"date":5483,"description":5484,"extension":213,"image":5485,"meta":5486,"navigation":3,"path":5487,"published":3,"seo":5488,"seoTitle":5489,"slug":5490,"stem":5491,"tags":5492,"updated":229,"__hash__":5497},"blog/blog/2026-01-22-riscrivere-software-da-zero.md","Riscrivere un software da zero: quando ha senso e quando no",{"type":9,"value":5317,"toc":5465},[5318,5323,5326,5330,5333,5336,5339,5343,5347,5350,5354,5357,5361,5368,5375,5379,5382,5388,5392,5396,5399,5403,5406,5410,5417,5421,5424,5428,5431,5438,5442,5445,5448,5451,5455,5462],[12,5319,5320],{},[16,5321,5322],{},"\"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.",[12,5324,5325],{},"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.",[30,5327,5329],{"id":5328},"perché-il-team-vuole-riscrivere","Perché il team vuole riscrivere",[12,5331,5332],{},"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.",[12,5334,5335],{},"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.",[12,5337,5338],{},"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.",[30,5340,5342],{"id":5341},"perché-le-riscritture-vanno-male","Perché le riscritture vanno male",[1649,5344,5346],{"id":5345},"il-vecchio-sistema-sa-più-di-quanto-pensi","Il vecchio sistema sa più di quanto pensi",[12,5348,5349],{},"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.",[1649,5351,5353],{"id":5352},"i-requisiti-non-aspettano","I requisiti non aspettano",[12,5355,5356],{},"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).",[1649,5358,5360],{"id":5359},"le-stime-sono-sempre-sbagliate","Le stime sono sempre sbagliate",[12,5362,5363,5364,5367],{},"Gli sviluppatori ",[133,5365,5366],{"href":301},"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.",[12,5369,5370,5371,5374],{},"La verità? ",[16,5372,5373],{},"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.",[1649,5376,5378],{"id":5377},"i-compromessi-torneranno","I compromessi torneranno",[12,5380,5381],{},"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.",[12,5383,5384,5385,103],{},"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 ",[133,5386,5387],{"href":1746},"il software ha costi di manutenzione continui",[30,5389,5391],{"id":5390},"cosa-fare-invece-di-riscrivere","Cosa fare invece di riscrivere",[1649,5393,5395],{"id":5394},"refactoring-incrementale","Refactoring incrementale",[12,5397,5398],{},"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.",[1649,5400,5402],{"id":5401},"strangler-fig-pattern","Strangler fig pattern",[12,5404,5405],{},"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.",[1649,5407,5409],{"id":5408},"investi-nel-testing-prima-di-toccare-il-codice","Investi nel testing prima di toccare il codice",[12,5411,5412,5413,5416],{},"Se il team ha paura di cambiare perché “potremmo rompere qualcosa”, il primo investimento è una ",[133,5414,5415],{"href":2158},"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.",[1649,5418,5420],{"id":5419},"scrivi-le-regole-di-business","Scrivi le regole di business",[12,5422,5423],{},"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.",[30,5425,5427],{"id":5426},"quando-la-riscrittura-ha-senso-davvero","Quando la riscrittura ha senso davvero",[12,5429,5430],{},"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.",[12,5432,5433,5434,5437],{},"La riscrittura può anche avere senso se il codebase è ancora piccolo. Un ",[133,5435,5436],{"href":277},"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.",[30,5439,5441],{"id":5440},"le-domande-da-farsi-prima-di-dire-sì-a-una-riscrittura","Le domande da farsi prima di dire sì a una riscrittura",[12,5443,5444],{},"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é.",[12,5446,5447],{},"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.",[12,5449,5450],{},"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.",[30,5452,5454],{"id":5453},"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.",[12,5456,5457,5458,5461],{},"Lo so, è dura da accettare, ma è la verità. Se il team vuole riscrivere tutto, ",[16,5459,5460],{},"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.",[12,5463,5464],{},"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":199,"searchDepth":200,"depth":200,"links":5466},[5467,5468,5474,5480,5481,5482],{"id":5328,"depth":200,"text":5329},{"id":5341,"depth":200,"text":5342,"children":5469},[5470,5471,5472,5473],{"id":5345,"depth":1768,"text":5346},{"id":5352,"depth":1768,"text":5353},{"id":5359,"depth":1768,"text":5360},{"id":5377,"depth":1768,"text":5378},{"id":5390,"depth":200,"text":5391,"children":5475},[5476,5477,5478,5479],{"id":5394,"depth":1768,"text":5395},{"id":5401,"depth":1768,"text":5402},{"id":5408,"depth":1768,"text":5409},{"id":5419,"depth":1768,"text":5420},{"id":5426,"depth":200,"text":5427},{"id":5440,"depth":200,"text":5441},{"id":5453,"depth":200,"text":5454},"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":5315,"description":5484},"Riscrivere software da zero: rischi, costi e alternative","riscrivere-software-da-zero","blog/2026-01-22-riscrivere-software-da-zero",[5493,5494,228,5495,5496],"riscrivere-software","refactoring","modernizzazione","scelta-tecnica","bPm3Pyn7B5r-OTd0BW7zOBPcE4ueVGg_Z-H6KtvWN0Q",{"id":5499,"title":5500,"body":5501,"category":1784,"date":5633,"description":5634,"extension":213,"image":5635,"meta":5636,"navigation":3,"path":5637,"published":3,"seo":5638,"seoTitle":5639,"slug":5640,"stem":5641,"tags":5642,"updated":229,"__hash__":5646},"blog/blog/2026-01-20-monolite-vs-microservizi.md","Monolite vs microservizi: quando servono davvero i servizi distribuiti",{"type":9,"value":5502,"toc":5620},[5503,5512,5515,5519,5522,5525,5532,5536,5540,5543,5546,5550,5553,5557,5560,5563,5567,5570,5573,5580,5584,5587,5590,5594,5597,5600,5602,5609,5613],[12,5504,5505],{},[16,5506,5507,5508,5511],{},"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 ",[133,5509,5510],{"href":1089},"migrazione che dura mesi",", non risolve i veri problemi, e ne tira fuori di nuovi.",[12,5513,5514],{},"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.",[30,5516,5518],{"id":5517},"il-vero-problema-che-risolvono-i-microservizi","Il vero problema che risolvono i microservizi",[12,5520,5521],{},"I microservizi risolvono diversi problemi tecnici reali, ma nella pratica diventano davvero utili soprattutto quando la complessità organizzativa del team cresce molto.",[12,5523,5524],{},"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.",[12,5526,5527,5528,5531],{},"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. ",[16,5529,5530],{},"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.",[30,5533,5535],{"id":5534},"cosa-succede-davvero-quando-ti-butti-sui-microservizi-troppo-presto","Cosa succede davvero quando ti butti sui microservizi troppo presto",[1649,5537,5539],{"id":5538},"la-complessità-operativa-schizza-alle-stelle","La complessità operativa schizza alle stelle",[12,5541,5542],{},"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.",[12,5544,5545],{},"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.",[1649,5547,5549],{"id":5548},"il-debugging-diventa-un-incubo","Il debugging diventa un incubo",[12,5551,5552],{},"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.",[1649,5554,5556],{"id":5555},"la-gestione-della-coerenza-dei-dati-diventa-molto-più-complessa","La gestione della coerenza dei dati diventa molto più complessa",[12,5558,5559],{},"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?",[12,5561,5562],{},"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.",[30,5564,5566],{"id":5565},"ma-il-monolite-non-scala","\"Ma il monolite non scala!\"",[12,5568,5569],{},"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.",[12,5571,5572],{},"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.",[12,5574,5575,5576,5579],{},"Molto spesso il vero collo di bottiglia è proprio ",[133,5577,5578],{"href":4817},"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.",[30,5581,5583],{"id":5582},"quando-i-microservizi-hanno-davvero-senso","Quando i microservizi hanno davvero senso",[12,5585,5586],{},"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.",[12,5588,5589],{},"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.",[30,5591,5593],{"id":5592},"cosa-fare-invece-dei-microservizi","Cosa fare invece dei microservizi",[12,5595,5596],{},"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.",[12,5598,5599],{},"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.",[30,5601,2164],{"id":2163},[12,5603,5604,5605,5608],{},"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? ",[133,5606,5607],{"href":301},"Le stime su questi passaggi tendono a essere fortemente sottovalutate",". Infine, la domanda più importante: esiste una soluzione più semplice? Molto spesso sì.",[30,5610,5612],{"id":5611},"un-buon-monolite-è-un-vantaggio-competitivo","Un buon monolite è un vantaggio competitivo",[12,5614,5615,5616,5619],{},"Nel 2026, con ",[133,5617,5618],{"href":135},"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":199,"searchDepth":200,"depth":200,"links":5621},[5622,5623,5628,5629,5630,5631,5632],{"id":5517,"depth":200,"text":5518},{"id":5534,"depth":200,"text":5535,"children":5624},[5625,5626,5627],{"id":5538,"depth":1768,"text":5539},{"id":5548,"depth":1768,"text":5549},{"id":5555,"depth":1768,"text":5556},{"id":5565,"depth":200,"text":5566},{"id":5582,"depth":200,"text":5583},{"id":5592,"depth":200,"text":5593},{"id":2163,"depth":200,"text":2164},{"id":5611,"depth":200,"text":5612},"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":5500,"description":5634},"Monolite vs microservizi: quando servono davvero","monolite-vs-microservizi","blog/2026-01-20-monolite-vs-microservizi",[226,5643,4486,3882,5644,5645,658],"microservizi","scalabilita","devops","XYFDaOyvMwJxflmNkgb2NY9q98j84lqDx5DEIgoah_Q",{"id":5648,"title":5649,"body":5650,"category":1784,"date":5798,"description":5799,"extension":213,"image":5800,"meta":5801,"navigation":3,"path":5802,"published":3,"seo":5803,"seoTitle":5804,"slug":5805,"stem":5806,"tags":5807,"updated":229,"__hash__":5812},"blog/blog/2026-01-15-web-app-lenta-problema-database.md","Web app lenta: perché il collo di bottiglia è quasi sempre il database",{"type":9,"value":5651,"toc":5785},[5652,5659,5662,5666,5669,5676,5680,5683,5686,5689,5693,5696,5700,5703,5707,5710,5714,5717,5721,5724,5727,5733,5737,5740,5743,5746,5749,5753,5756,5759,5762,5765,5769,5772,5779,5782],[12,5653,5654,5655,5658],{},"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: \"",[133,5656,5657],{"href":1089},"Riscriviamo tutto da zero",".\"",[12,5660,5661],{},"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.",[30,5663,5665],{"id":5664},"come-funziona-davvero-il-problema-spiegato-semplice","Come funziona davvero il problema (spiegato semplice)",[12,5667,5668],{},"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.",[12,5670,5671,5672,5675],{},"Questo schema è noto come ",[16,5673,5674],{},"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.",[30,5677,5679],{"id":5678},"perché-succede-e-perché-spesso-non-si-vede","Perché succede (e perché spesso non si vede)",[12,5681,5682],{},"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.",[12,5684,5685],{},"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.",[12,5687,5688],{},"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.",[30,5690,5692],{"id":5691},"i-segnali-dallarme-da-tenere-docchio","I segnali d'allarme da tenere d'occhio",[12,5694,5695],{},"Non serve essere tecnici per intercettare alcuni indizi.",[1649,5697,5699],{"id":5698},"le-pagine-diventano-più-lente-col-tempo","Le pagine diventano più lente col tempo",[12,5701,5702],{},"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é.",[1649,5704,5706],{"id":5705},"i-costi-dei-server-crescono-più-del-previsto","I costi dei server crescono più del previsto",[12,5708,5709],{},"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.",[1649,5711,5713],{"id":5712},"si-tende-a-risolvere-con-infrastruttura-e-cache","Si tende a risolvere con infrastruttura e cache",[12,5715,5716],{},"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.",[30,5718,5720],{"id":5719},"quanto-costa-ignorare-il-problema","Quanto costa ignorare il problema",[12,5722,5723],{},"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.",[12,5725,5726],{},"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.",[12,5728,5729,5730,103],{},"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 ",[133,5731,5732],{"href":1081},"fragile e ha paura di deployare",[30,5734,5736],{"id":5735},"la-domanda-che-chiarisce-la-situazione","La domanda che chiarisce la situazione",[12,5738,5739],{},"Una domanda semplice aiuta a capire molto:",[12,5741,5742],{},"“Quante query fa la pagina principale?”",[12,5744,5745],{},"Se il team ha un numero aggiornato, significa che misura e osserva. Se la risposta è incerta, probabilmente questa dimensione non è sotto controllo.",[12,5747,5748],{},"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.",[30,5750,5752],{"id":5751},"cosa-puoi-fare-in-pratica","Cosa puoi fare in pratica",[12,5754,5755],{},"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.",[12,5757,5758],{},"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.",[12,5760,5761],{},"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.",[12,5763,5764],{},"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.",[30,5766,5768],{"id":5767},"quanto-costa-intervenire","Quanto costa intervenire?",[12,5770,5771],{},"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.",[12,5773,5774,5775,5778],{},"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 ",[133,5776,5777],{"href":4485},"riscrivere tutto il monolite in microservizi"," quando il vero problema era nelle query.",[12,5780,5781],{},"La domanda chiave resta la stessa:",[12,5783,5784],{},"“Quante query fa questa pagina?”",{"title":199,"searchDepth":200,"depth":200,"links":5786},[5787,5788,5789,5794,5795,5796,5797],{"id":5664,"depth":200,"text":5665},{"id":5678,"depth":200,"text":5679},{"id":5691,"depth":200,"text":5692,"children":5790},[5791,5792,5793],{"id":5698,"depth":1768,"text":5699},{"id":5705,"depth":1768,"text":5706},{"id":5712,"depth":1768,"text":5713},{"id":5719,"depth":200,"text":5720},{"id":5735,"depth":200,"text":5736},{"id":5751,"depth":200,"text":5752},{"id":5767,"depth":200,"text":5768},"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":5649,"description":5799},"Web app lenta: cause e ottimizzazione database","web-app-lenta-problema-database","blog/2026-01-15-web-app-lenta-problema-database",[5808,5809,658,3882,829,1797,5810,5811],"performance","database","infrastruttura","web-app","1VwxOM99pAKADu_l8TsM0VczpTBirmO8eNzeIUF7Zts",{"id":5814,"title":5815,"body":5816,"category":1784,"date":6077,"description":6078,"extension":213,"image":6079,"meta":6080,"navigation":3,"path":6081,"published":3,"seo":6082,"seoTitle":6083,"slug":6084,"stem":6085,"tags":6086,"updated":229,"__hash__":6092},"blog/blog/2026-01-13-quale-framework-javascript-scegliere.md","React, Vue o Angular: come scegliere il framework JavaScript",{"type":9,"value":5817,"toc":6058},[5818,5821,5824,5828,5831,5834,5837,5840,5844,5847,5851,5854,5860,5866,5872,5876,5879,5884,5889,5894,5898,5901,5906,5911,5917,5921,5924,5930,5936,5942,5945,5949,5956,5960,5963,5966,5970,5973,5976,5980,5983,5986,5990,5993,5996,5999,6003,6006,6012,6015,6019,6022,6025,6032,6035,6039,6042,6045,6049,6052,6055],[12,5819,5820],{},"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.",[12,5822,5823],{},"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”.",[30,5825,5827],{"id":5826},"perché-il-mondo-javascript-e-typescript-è-un-campo-minato","Perché il mondo JavaScript e TypeScript è un campo minato",[12,5829,5830],{},"Prima di parlare dei singoli framework, bisogna capire perché il frontend è così caotico.",[12,5832,5833],{},"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.",[12,5835,5836],{},"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.",[12,5838,5839],{},"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?",[30,5841,5843],{"id":5842},"react-vs-vue-vs-angular-costi-e-compromessi-veri","React vs Vue vs Angular: costi e compromessi veri",[12,5845,5846],{},"Non esiste il framework perfetto. Esistono solo scelte con pro e contro, ed ecco quelli che fanno davvero la differenza.",[1649,5848,5850],{"id":5849},"react-tanta-libertà-tanta-responsabilità","React: tanta libertà, tanta responsabilità",[12,5852,5853],{},"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.",[12,5855,5856,5859],{},[16,5857,5858],{},"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.",[12,5861,5862,5865],{},[16,5863,5864],{},"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.",[12,5867,5868,5871],{},[16,5869,5870],{},"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.",[1649,5873,5875],{"id":5874},"vue-il-compromesso-che-funziona","Vue: il compromesso che funziona",[12,5877,5878],{},"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.",[12,5880,5881,5883],{},[16,5882,5858],{}," 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.",[12,5885,5886,5888],{},[16,5887,5864],{}," 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.",[12,5890,5891,5893],{},[16,5892,5870],{}," 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.",[1649,5895,5897],{"id":5896},"angular-struttura-rigida-zero-sorprese","Angular: struttura rigida, zero sorprese",[12,5899,5900],{},"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.",[12,5902,5903,5905],{},[16,5904,5858],{}," 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.",[12,5907,5908,5910],{},[16,5909,5864],{}," 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.",[12,5912,5913,5916],{},[16,5914,5915],{},"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.",[30,5918,5920],{"id":5919},"svelte-solid-qwik-e-gli-altri-occasione-o-rischio","Svelte, Solid, Qwik e gli altri: occasione o rischio?",[12,5922,5923],{},"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.",[12,5925,5926,5929],{},[16,5927,5928],{},"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.",[12,5931,5932,5935],{},[16,5933,5934],{},"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.",[12,5937,5938,5941],{},[16,5939,5940],{},"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.",[12,5943,5944],{},"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.",[30,5946,5948],{"id":5947},"il-fattore-che-cambia-tutto-lai-nello-sviluppo-frontend","Il fattore che cambia tutto: l'AI nello sviluppo frontend",[12,5950,5951,5952,5955],{},"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. ",[133,5953,5954],{"href":135},"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.",[1649,5957,5959],{"id":5958},"angular-e-ai-i-pattern-rigidi-aiutano","Angular e AI: i pattern rigidi aiutano",[12,5961,5962],{},"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.",[12,5964,5965],{},"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.",[1649,5967,5969],{"id":5968},"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",[12,5971,5972],{},"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.",[12,5974,5975],{},"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.",[1649,5977,5979],{"id":5978},"vue-e-ai-il-compromesso-funziona","Vue e AI: il compromesso funziona",[12,5981,5982],{},"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.",[12,5984,5985],{},"In pratica: l'AI è più affidabile con Vue che con React, ma meno che con Angular.",[30,5987,5989],{"id":5988},"impatto-dellai-sulla-produttività-dipende-tutto-dal-framework","Impatto dell'AI sulla produttività: dipende tutto dal framework",[12,5991,5992],{},"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.",[12,5994,5995],{},"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.",[12,5997,5998],{},"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.",[30,6000,6002],{"id":6001},"conta-di-più-il-team-del-framework","Conta di più il team del framework",[12,6004,6005],{},"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.",[12,6007,6008,6009,103],{},"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 ",[133,6010,6011],{"href":2723},"nella tua offerta, non nel mercato",[12,6013,6014],{},"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.",[30,6016,6018],{"id":6017},"come-scegliere-il-framework-frontend-nel-2026","Come scegliere il framework frontend nel 2026",[12,6020,6021],{},"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.",[12,6023,6024],{},"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.",[12,6026,6027,6028,6031],{},"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, ",[133,6029,6030],{"href":1089},"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.",[12,6033,6034],{},"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.",[30,6036,6038],{"id":6037},"il-framework-è-solo-un-mezzo-il-team-è-ciò-che-conta","Il framework è solo un mezzo, il team è ciò che conta",[12,6040,6041],{},"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.",[12,6043,6044],{},"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.",[30,6046,6048],{"id":6047},"la-mia-esperienza","La mia esperienza",[12,6050,6051],{},"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.",[12,6053,6054],{},"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.",[12,6056,6057],{},"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":199,"searchDepth":200,"depth":200,"links":6059},[6060,6061,6066,6067,6072,6073,6074,6075,6076],{"id":5826,"depth":200,"text":5827},{"id":5842,"depth":200,"text":5843,"children":6062},[6063,6064,6065],{"id":5849,"depth":1768,"text":5850},{"id":5874,"depth":1768,"text":5875},{"id":5896,"depth":1768,"text":5897},{"id":5919,"depth":200,"text":5920},{"id":5947,"depth":200,"text":5948,"children":6068},[6069,6070,6071],{"id":5958,"depth":1768,"text":5959},{"id":5968,"depth":1768,"text":5969},{"id":5978,"depth":1768,"text":5979},{"id":5988,"depth":200,"text":5989},{"id":6001,"depth":200,"text":6002},{"id":6017,"depth":200,"text":6018},{"id":6037,"depth":200,"text":6038},{"id":6047,"depth":200,"text":6048},"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":5815,"description":6078},"React, Vue o Angular: quale framework JavaScript scegliere","quale-framework-javascript-scegliere","blog/2026-01-13-quale-framework-javascript-scegliere",[6087,6088,6089,6090,4610,6091,658,226,222,3882],"javascript","react","vue","angular","typescript","nHGTseCMi85A2PHnjrvNimtvox5Rawqze-qhbGEXui0",{"id":6094,"title":6095,"body":6096,"category":210,"date":6229,"description":6230,"extension":213,"image":6231,"meta":6232,"navigation":3,"path":6233,"published":3,"seo":6234,"seoTitle":6235,"slug":6236,"stem":6237,"tags":6238,"updated":229,"__hash__":6239},"blog/blog/2026-01-08-sviluppare-con-ai.md","Sviluppare con l'AI: come cambia il lavoro (e i rischi)",{"type":9,"value":6097,"toc":6218},[6098,6101,6108,6112,6115,6118,6121,6124,6127,6131,6135,6138,6141,6147,6151,6154,6157,6161,6164,6171,6175,6178,6185,6188,6192,6195,6198,6201,6208,6212,6215],[12,6099,6100],{},"Sviluppare con AI è il tema del momento, e negli ultimi due anni gira un'idea che affascina un sacco di gente: l'AI sta democratizzando la programmazione. In teoria, serve meno personale, si fa tutto più in fretta, si spende meno. Chi guida aziende e prodotti sta impostando assunzioni e strategie di crescita su questa promessa. Ma il punto è che questa storia non è completa. E quando basi le tue decisioni su una visione parziale, rischi di pagare caro.",[12,6102,6103,6104,6107],{},"Io uso Claude Code ogni giorno, Codex ogni tanto soprattutto per revisionare. Questi strumenti ti fanno andare ",[16,6105,6106],{},"più veloce"," nello sviluppo. Non lo rendono più facile. Sembra una sfumatura da poco, ma cambia tutto: da come strutturi il team a come pianifichi la roadmap, fino a dove metti i soldi.",[30,6109,6111],{"id":6110},"dove-lai-fa-davvero-la-differenza","Dove l’AI fa davvero la differenza",[12,6113,6114],{},"Partiamo dal concreto: dove l’AI è particolarmente efficace. Lo è nella prototipazione: un prototipo funzionante che prima richiedeva una settimana oggi puoi tirarlo su in un giorno, e per testare un’idea in fretta il vantaggio è evidente.",[12,6116,6117],{},"Funziona molto bene anche sul lavoro ripetitivo. Ogni progetto ha una quantità enorme di codice “noioso”: configurazioni, routine standard, integrazioni, boilerplate. L’AI riduce tutto questo da ore a minuti e libera più tempo per la logica di business.",[12,6119,6120],{},"Aiuta poi a orientarsi nei progetti esistenti. Un nuovo sviluppatore di solito impiega settimane solo per capire dove ha messo i piedi; l’AI può ridurre sensibilmente questo tempo, rendendo l’onboarding, cioè l’ingresso operativo nel progetto, e i passaggi di consegne meno pesanti.",[12,6122,6123],{},"Infine accelera il refactoring. Rinominare, riorganizzare e sistemare codice vecchio diventa più veloce, anche se qui serve sempre un controllo umano perché gli errori sottili restano possibili.",[12,6125,6126],{},"Tutto questo è concreto. Se il tuo team sa usare questi strumenti, la produttività sale — e lo vedi. Il vero problema nasce quando “più veloce” viene confuso con “più facile”.",[30,6128,6130],{"id":6129},"i-costi-nascosti-che-nessuno-ti-dice","I costi nascosti che nessuno ti dice",[1649,6132,6134],{"id":6133},"il-debito-tecnico-cresce-a-una-velocità-nuova","Il debito tecnico cresce a una velocità nuova",[12,6136,6137],{},"Il debito tecnico, cioè il costo futuro delle scorciatoie che prendi oggi, è quel conto che paghi domani per guadagnare velocità adesso. Tutti i progetti ce l’hanno, chi più chi meno. Ma con l’AI, la velocità con cui cresce non si era mai vista. Il motivo è semplice: scrivere codice con l’AI costa quasi zero in termini di tempo e fatica. E allora prendi quello che arriva: “Funziona? Dai, andiamo avanti.” Il codice che ti dà l’AI spesso fa quello che chiedi, sì, ma magari in modo poco efficiente, fragile, o con problemi di sicurezza che non si vedono subito.",[12,6139,6140],{},"Nel concreto, il debito tecnico lo senti quando tra sei mesi il team ti dice: “Per aggiungere questa feature ci vogliono tre mesi invece di tre settimane, perché prima dobbiamo rifare le fondamenta.” O quando un bug in produzione tiene tutti fermi per giorni, perché nessuno capisce più come funziona quel pezzo di codice.",[12,6142,6143,6146],{},[16,6144,6145],{},"Il debito tecnico che prima si accumulava lentamente, con l’AI può accumularsi molto più in fretta."," Più codice imperfetto, più problemi.",[1649,6148,6150],{"id":6149},"spesso-il-team-non-conosce-davvero-il-codice-che-finisce-in-produzione","Spesso il team non conosce davvero il codice che finisce in produzione",[12,6152,6153],{},"Qui c'è un problema che chi guida un team dovrebbe tenere bene a mente: quando uno sviluppatore usa l’AI per generare codice, quel pezzo finisce nel progetto, ma nessuno ci ha davvero ragionato sopra. Nessuno ha fatto scelte consapevoli, nessuno si è costruito un modello mentale di come funziona quel codice, riga per riga.",[12,6155,6156],{},"Poi, puntualmente, qualcosa si rompe. Nel software succede sempre. E invece di risolvere in fretta, ci si mette di più. Lo sviluppatore si trova a fare il detective su un pezzo di codice che, ufficialmente, è suo… ma che in realtà non ha mai davvero progettato. In pratica, le stime diventano un terno al lotto. Il bug che “dovrebbe portar via un’ora” si trasforma in un giorno intero. E ripeti questa storia, tutte le settimane, tutto l’anno.",[1649,6158,6160],{"id":6159},"le-decisioni-strategiche-restano-umane","Le decisioni strategiche restano umane",[12,6162,6163],{},"L'AI scrive codice, sì. Ma non decide quale codice serve. Che architettura regge il salto da 100 a 10.000 utenti? Quali compromessi sono accettabili per lanciare prima senza tagliarsi le gambe per il futuro? Come si struttura un sistema perché il team non si blocchi da solo quando lavora in parallelo?",[12,6165,6166,6167,6170],{},"Queste cose richiedono esperienza vera, conoscenza del contesto, una visione chiara sul prodotto. L’AI, queste cose, non le ha. Può darti una risposta generica, se gliela chiedi, ma le decisioni di architettura che separano un prodotto che scala da uno che va ",[133,6168,6169],{"href":1089},"riscritto da zero"," tra 18 mesi sono dettagliate, dipendono dal contesto e richiedono giudizio umano. Quando costruisci un prodotto software, le scelte più rischiose e costose non sono sul codice, ma sulla struttura. E qui l’AI non ti dà una mano. Almeno ancora non oggi.",[30,6172,6174],{"id":6173},"chi-ci-guadagna-davvero-con-lai-nello-sviluppo-software","Chi ci guadagna davvero con l'AI nello sviluppo software",[12,6176,6177],{},"Arriviamo al punto: chi gestisce team e fa assunzioni deve capirlo bene. Gli strumenti di AI aiutano di più chi ha meno bisogno di aiuto: gli sviluppatori senior. Quelli che costano di più. Il motivo è semplice. Chi ha esperienza sa fare la domanda giusta, perché l’output dell’AI dipende molto da come la interroghi; sa giudicare il codice che riceve e scartarlo se non va bene; sa dove inserirlo nel sistema e come adattarlo al resto del progetto; sa riconoscere problemi prima che diventino bug in produzione.",[12,6179,6180,6181,6184],{},"I junior spesso non hanno ancora sviluppato questi filtri. Prendono il codice generato, lo infilano nel progetto senza capirlo davvero, e costruiscono sopra fondamenta che non conoscono. Quando qualcosa si rompe, non hanno gli strumenti per venirne a capo. È il motivo per cui ",[133,6182,6183],{"href":2132},"i design pattern valgono più di qualsiasi linguaggio",": servono a riconoscere se la struttura proposta dall'AI ha senso oppure no.",[12,6186,6187],{},"L’AI moltiplica le capacità di chi già sa cosa fare. Non sostituisce la competenza. Questa cosa si riflette direttamente sulle scelte di hiring: un team di cinque senior con AI produce di più (e meglio) di dieci junior con gli stessi strumenti. E ti costa meno in manutenzione, alla lunga.",[30,6189,6191],{"id":6190},"cosa-cambia-davvero-per-chi-decide","Cosa cambia davvero per chi decide",[12,6193,6194],{},"Se guidi un team, gestisci un budget o una roadmap, il primo punto è non ridurre il team ma spostarne il lavoro. L'AI non elimina il bisogno di sviluppatori: cambia il tipo di attività su cui li vuoi concentrare. Il tempo risparmiato sulle task ripetitive va investito in revisione del codice, test e ragionamento architetturale, non in una corsa cieca ad aggiungere feature.",[12,6196,6197],{},"Conta anche puntare sulla competenza più che sulla quantità. Uno sviluppatore senior che sa guidare e valutare l’AI vale spesso più di tre junior che si fidano ciecamente di ciò che esce. Quello che sembra un risparmio all’inizio si trasforma facilmente in un costo pesante dopo pochi mesi.",[12,6199,6200],{},"Va poi considerata la revisione come parte del processo. Se il flusso è “genera con AI, poi deploy”, stai accumulando debito tecnico a una velocità pericolosa. Quel codice va letto, capito e validato da qualcuno che sappia davvero cosa sta guardando. Allo stesso modo non bisogna farsi ingannare dalle demo: con l'AI è facilissimo tirare fuori un prototipo brillante in un pomeriggio, ma tra “funziona nella demo” e “regge in produzione con mille utenti contemporanei” resta un abisso.",[12,6202,6203,6204,6207],{},"Infine bisogna monitorare il debito tecnico. Chiedi al team quanto tempo passa a sistemare problemi vecchi rispetto a costruire cose nuove. Se quella percentuale cresce mese dopo mese, la velocità iniziale si sta trasformando in zavorra. E attenzione a non ",[133,6205,6206],{"href":1502},"aggiungere persone"," pensando che questo risolva il problema, perché spesso lo aggrava.",[30,6209,6211],{"id":6210},"lai-amplifica-la-competenza-non-la-sostituisce","L'AI amplifica la competenza, non la sostituisce",[12,6213,6214],{},"L'AI non ha reso lo sviluppo software più facile. Ha velocizzato il lavoro meccanico, ma la parte che richiede giudizio, esperienza e visione è rimasta. Anzi, ora pesa ancora di più. Chi costruisce software non dovrebbe chiedersi “quanta gente posso tagliare grazie all'AI”, ma piuttosto \"come posso usare l'AI per far lavorare meglio le persone giuste\".",[12,6216,6217],{},"Le aziende che ci arrivano prima stanno giocando d’anticipo: lanciano prodotti migliori, più robusti, e ci arrivano prima degli altri. Chi invece pensa che “più veloce” voglia dire “più facile” finisce per costruire roba che fra un anno dovrà rifare da capo. E questa differenza, alla lunga, vale centinaia di migliaia di euro.",{"title":199,"searchDepth":200,"depth":200,"links":6219},[6220,6221,6226,6227,6228],{"id":6110,"depth":200,"text":6111},{"id":6129,"depth":200,"text":6130,"children":6222},[6223,6224,6225],{"id":6133,"depth":1768,"text":6134},{"id":6149,"depth":1768,"text":6150},{"id":6159,"depth":1768,"text":6160},{"id":6173,"depth":200,"text":6174},{"id":6190,"depth":200,"text":6191},{"id":6210,"depth":200,"text":6211},"2026-01-08","L'AI accelera lo sviluppo software ma aumenta il peso delle decisioni. Cosa cambia per chi gestisce team, budget e roadmap, e come evitare errori costosi.","/images/blog/sviluppare-con-ai.jpg",{},"/blog/2026-01-08-sviluppare-con-ai",{"title":6095,"description":6230},"Sviluppo software con AI: vantaggi e limiti reali","sviluppare-con-ai","blog/2026-01-08-sviluppare-con-ai",[222,227,658,3881,228,829,3882],"PcMDzV-HjK0dEIwWS7wDVqtTeCTpnAW6hFlSaXIHqeY",{"id":6241,"title":6242,"body":6243,"category":5298,"date":6441,"description":6442,"extension":213,"image":6443,"meta":6444,"navigation":3,"path":6445,"published":3,"seo":6446,"seoTitle":6447,"slug":6448,"stem":6449,"tags":6450,"updated":229,"__hash__":6451},"blog/blog/2026-01-06-sicurezza-backend-produzione.md","Sicurezza del backend: tre errori comuni e come mitigarli",{"type":9,"value":6244,"toc":6429},[6245,6248,6251,6258,6261,6265,6268,6271,6274,6277,6280,6284,6287,6291,6294,6297,6301,6304,6307,6313,6317,6324,6327,6331,6334,6337,6348,6352,6355,6364,6370,6380,6384,6391,6394,6400,6404,6410,6413,6416,6419,6422],[12,6246,6247],{},"La sicurezza backend è un tema che troppi team sottovalutano fino a quando non è troppo tardi. Dipendenze vecchie, configurazioni di sviluppo finite in produzione, secret messi ovunque come coriandoli: ecco come nasce un disastro, e come evitarlo anche se il tuo team non è formato da venti persone.",[12,6249,6250],{},"Parliamoci chiaro: se il tuo prodotto gira su un framework web moderno — Laravel, Django, Rails, Express, scegli tu — è molto probabile che il tuo server di produzione abbia dipendenze con vulnerabilità note. È una situazione più comune di quanto si pensi.",[12,6252,6253,6254,6257],{},"E la cosa peggiore? Probabilmente lo sapete già. Chi gestisce il tech pensa \"prima o poi aggiorniamo tutto\". Quel famoso task su Jira, \"",[133,6255,6256],{"href":3152},"aggiornamento dipendenze","\", che ormai da sei mesi slitta di sprint in sprint. Nessuno lo mette mai tra le priorità, tanto non porta nessuna funzionalità visibile. Poi arriva quel martedì mattina in cui ti arriva una email che ti informa che il tuo token è stato revocato in quanto apparso su un repo Github privato, e il \"prima o poi\" si trasforma di colpo in \"doveva essere ieri\".",[12,6259,6260],{},"Questo articolo è per chi deve prendere decisioni su un prodotto software. È una triste storia vista troppe volte. E il finale, spesso, è lo stesso.",[30,6262,6264],{"id":6263},"come-si-buca-un-server-nel-2026","Come si buca un server nel 2026",[12,6266,6267],{},"Lasciate stare l’immagine dell’hacker col cappuccio e la maschera di Guy Fawkes, lo schermo nero pieno di codice verde e il computer che fa bip-bip ogni volta che appare il testo. Gli attacchi di oggi sono spesso noiosi, metodici, e sfruttano la pigrizia di chi gestisce i server più che l’ingegno di chi li attacca.",[12,6269,6270],{},"Di solito funziona così. Un framework web famoso ha una libreria che si installa di default o perché serve per una feature secondaria. Esce una CVE critica, cioè una vulnerabilità di sicurezza riconosciuta e catalogata pubblicamente, tipo la recente CVE-2025-54068, che permette a un attaccante di eseguire codice sul server con una richiesta ben costruita. Il fix spesso esce in tempi brevi, e aggiornare di solito basta. Sei mesi dopo, capita di trovare server ancora sulla versione bucata.",[12,6272,6273],{},"L’attaccante non ha bisogno di essere un genio. L’exploit è pubblico, ci sono già gli script pronti. Scannerizza automaticamente migliaia di server, identifica versioni vulnerabili tramite fingerprinting e prova exploit già pronti. Spesso in tempi più rapidi di un vostro deploy, è già dentro.",[12,6275,6276],{},"Se riesce a eseguire codice o leggere file sul server, può accedere al file .env con tutte le variabili d’ambiente. Quel file è un tesoro per chi attacca: ci trova molto, dalle credenziali del database ai token API di GitHub, dalle chiavi AWS ai token del servizio di hosting, ai segreti OAuth. Informazioni critiche sulla tua infrastruttura possono trovarsi tutte concentrate in un unico file.",[12,6278,6279],{},"A quel punto diventa un disastro completo, ben oltre il \"semplice incidente di sicurezza\". Dovete cambiare tutte le credenziali esposte, controllare che non abbia installato backdoor, verificare che non abbia girato su altri server con i token rubati, avvisare chi va avvisato. Giorni di lavoro bruciati e la paranoia che qualcosa vi sia sfuggito.",[30,6281,6283],{"id":6282},"le-tre-vulnerabilità-che-vedo-più-spesso-nei-backend","Le tre vulnerabilità che vedo più spesso nei backend",[12,6285,6286],{},"I disastri, per quello che ho visto, nascono spesso da tre errori ricorrenti. Presi singolarmente, si gestiscono. Ma insieme diventano una vera e propria kill chain.",[1649,6288,6290],{"id":6289},"_1-debug-attivo-in-produzione","1. Debug attivo in produzione",[12,6292,6293],{},"Ogni framework ha la modalità debug, cioè la configurazione che mostra molti dettagli tecnici utili a chi sviluppa. Quando la lasci attiva, in caso di errore mostra stack trace dettagliati, variabili d’ambiente, percorsi del filesystem, a volte informazioni sensibili che aiutano molto un attaccante. Serve tantissimo in sviluppo. In produzione, è come lasciare le chiavi di casa infilate nella porta con un post-it sopra: \"entrate pure\".",[12,6295,6296],{},"E succede più spesso di quanto si voglia ammettere. Un deploy fatto di corsa, un copia-incolla sbagliato del file di configurazione, un \"lo sistemo dopo\" che resta lì per mesi. E spesso nessuno se ne accorge, il sito continua a funzionare uguale — la modalità debug può passare inosservata all’utente normale, ma fornire informazioni molto utili a chi attacca. Per dire, mi è capitato di trovare due deploy fatti così in una settimana (non sto romanzando ai fini del post, sono serio!). Prima di mettere in produzione, controlla tutto due volte!",[1649,6298,6300],{"id":6299},"_2-dipendenze-fantasma","2. Dipendenze fantasma",[12,6302,6303],{},"Alcuni pacchetti possono registrare automaticamente route, endpoint o middleware senza che tu debba scrivere una riga di codice. È uno degli effetti collaterali dei framework moderni: tutto funziona subito.",[12,6305,6306],{},"Il problema è che queste route possono finire in produzione e diventare pubbliche, e tu magari non te ne accorgi nemmeno perché non le hai scritte tu. Alcuni pacchetti possono esporre endpoint o funzionalità accessibili via web senza che tu li abbia scritti direttamente.",[12,6308,6309,6312],{},[16,6310,6311],{},"Quante route ha davvero il tuo server di produzione?"," Se pensi \"quelle che abbiamo scritto noi\", probabilmente ti sbagli. Fatevi un audit!",[1649,6314,6316],{"id":6315},"_3-i-segreti-nello-stesso-cestino","3. I segreti nello stesso cestino",[12,6318,6319,6320,6323],{},"Il file ",[595,6321,6322],{},".env"," è una comodità che ti si può ritorcere contro. Un unico file con dentro tutte le chiavi: database, cloud, API, servizi di deploy, OAuth. Se qualcuno mette le mani su quel file, può potenzialmente accedere a gran parte della tua infrastruttura. Se lì dentro c’è il token del tuo hosting, l’attaccante può entrare in più punti: leggere le variabili degli altri progetti, aggiungere SSH key, cambiare gli script di deploy, piazzare backdoor che possono resistere anche a pulizie superficiali.",[12,6325,6326],{},"Può bastare un solo file compromesso e, come niente, l’attaccante si trova la strada molto più aperta verso tutta l’infrastruttura. Se il server è già stato bucato, puoi ragionevolmente temere che quel file ora sia in mani sbagliate.",[30,6328,6330],{"id":6329},"perché-la-sicurezza-viene-sempre-dopo","Perché la sicurezza viene sempre dopo",[12,6332,6333],{},"Arriviamo al punto dolente. Tutti e tre gli errori di cui ho parlato si risolvono in modo relativamente banale. Disattivare il debug può richiedere una sola configurazione. Aggiornare una dipendenza può essere questione di un comando. Vault per i segreti? Esiste già, e in molti casi basta integrarlo.",[12,6335,6336],{},"Il problema? Spesso non c'è tempo, mandato o voglia di farlo. Chi guida il tech ha almeno altre 15 priorità. Il team corre per consegnare la feature che il cliente aspetta da mesi. Nessuno metterà “aggiornamento librerie” in cima al backlog: non si vede, non si vende, non fa scena in demo.",[12,6338,6339,6340,6343,6344,6347],{},"La sicurezza è uno degli ambiti dell'ingegneria dove ",[16,6341,6342],{},"non fare nulla sembra andare benissimo"," — fino al giorno in cui tutto esplode, tutto insieme. È un po' come i ",[133,6345,6346],{"href":1746},"costi di manutenzione del software",": invisibili finché non ti presentano il conto. È come l’assicurazione sulla casa: è una spesa inutile. Finché non viene un alluvione.",[30,6349,6351],{"id":6350},"cosa-fare-davvero-anche-senza-un-team-dedicato","Cosa fare davvero (anche senza un team dedicato)",[12,6353,6354],{},"Non ti serve un esercito. Bastano poche pratiche ben impostate che, una volta messe in piedi, continuano a lavorare da sole.",[12,6356,6357,6358,6360,6361,6363],{},"La prima è un gate automatico nella pipeline di deploy, cioè nella sequenza di controlli e passaggi che porta il codice in produzione. Prima di ogni rilascio deve esserci un controllo che faccia almeno due cose: verificare che non esistano CVE gravi note nelle dipendenze e controllare che le configurazioni sensibili siano corrette. Se qualcosa non va, il deploy si ferma. Se avete già una CI/CD, cioè un sistema che automatizza test e rilasci, aggiungere un ",[595,6359,5187],{}," o un ",[595,6362,5184],{}," può portarvi via poco tempo; se partite da zero servono alcuni giorni per farlo bene, ma poi quel controllo continua a lavorare in modo costante.",[12,6365,6366,6367,6369],{},"La seconda pratica è un audit mensile molto semplice. Non serve per forza un penetration test da migliaia di euro. Spesso basta dedicare mezz’ora al mese a lanciare ",[595,6368,5187],{}," o l’equivalente, controllare gli endpoint realmente esposti in produzione, verificare che debug ed error reporting siano configurati correttamente e attivare strumenti come Dependabot su GitHub. È un controllo leggero, ma evita molti problemi grossi.",[12,6371,6372,6373,6376,6377,6379],{},"La terza riguarda i secret. Tenerli tutti in un file di testo è comodo, ma non è una soluzione matura per la produzione. Meglio usare strumenti come AWS Secrets Manager e, quando possibile, attivare una ",[16,6374,6375],{},"rotazione automatica",". Se un secret viene rubato ma cambia ogni trenta giorni, l’attaccante ha una finestra molto più stretta per fare danni. Se invece resta nello stesso ",[595,6378,6322],{}," per due anni, il rischio cresce enormemente.",[30,6381,6383],{"id":6382},"il-discorso-scomodo-per-chi-decide","Il discorso scomodo per chi decide",[12,6385,6386,6387,6390],{},"Se sei arrivato fin qui e prendi decisioni sul prodotto, questa parte è per te. Ogni sprint in cui rimandi la manutenzione di sicurezza, stai facendo debiti. Non è debito tecnico vago: sono interessi veri, in giorni persi a rimediare, costi legali se ci scappano dati personali, danni alla reputazione, e quella settimana in cui il team migliore non fa feature ma corre a ruotare chiavi e a cercare backdoor. E se pensi di risolvere ",[133,6388,6389],{"href":1502},"aggiungendo più sviluppatori"," alla gestione di una crisi in corso, il risultato è spesso l'opposto di quello sperato.",[12,6392,6393],{},"Il conto è abbastanza chiaro. Qualche giorno per impostare i controlli automatici, mezz’ora al mese per un audit. Dall’altra parte, una settimana di lavoro buttata per un incidente, più i soldi della notifica GDPR, più il danno d’immagine.",[12,6395,6396,6399],{},[16,6397,6398],{},"Non è solo \"se\" succede. Spesso è \"quando\"."," E quel quando dipende anche da quanto è sveglio chi ti sta scannerizzando.",[30,6401,6403],{"id":6402},"incident-response-cosa-fare-quando-ti-hanno-bucato","Incident response: cosa fare quando ti hanno bucato",[12,6405,6406,6407,6409],{},"Se sei qui perché il problema è già esploso, la prima cosa da fare è revocare tutto subito. Ogni token, ogni API key, ogni credenziale che era nel file ",[595,6408,6322],{}," va considerata compromessa. Non “appena riesci”: adesso.",[12,6411,6412],{},"Subito dopo vanno cambiate tutte le password e le credenziali dei servizi collegati. Se nel file c’erano token di Forge, DigitalOcean, Hetzner o servizi simili, devi partire dal presupposto che qualcuno possa già muoversi sui tuoi server. Guarda i log di accesso e controlla ogni servizio collegato.",[12,6414,6415],{},"Poi bisogna cercare le backdoor. Controlla cron job, chiavi SSH autorizzate, file modificati di recente. Chi entra in un sistema spesso prova a lasciarsi una strada aperta per tornare. E non fidarti mai della sensazione che “sembra tutto ok”: se non trovi niente, può semplicemente voler dire che non l’hai ancora trovato.",[12,6417,6418],{},"Infine scrivi tutto. Segna orari, azioni eseguite e ciò che hai scoperto. Ti servirà sia per ricostruire l’incidente sia, se ci sono dati personali coinvolti, per tutto ciò che riguarda la GDPR.",[12,6420,6421],{},"La prima reazione è mettere tutto a posto in fretta e poi far finta di niente. Ma resisti. Se fai le cose bene ora, eviti di ripetere lo stesso incubo tra tre mesi.",[12,6423,6424,6425,6428],{},"Il tuo backend non è una bomba a orologeria per colpa di come l’hanno progettato. ",[16,6426,6427],{},"Diventa davvero pericoloso soprattutto se lo trascuri."," E oggi, nel 2026, puoi automatizzare quasi tutta la fatica della manutenzione.",{"title":199,"searchDepth":200,"depth":200,"links":6430},[6431,6432,6437,6438,6439,6440],{"id":6263,"depth":200,"text":6264},{"id":6282,"depth":200,"text":6283,"children":6433},[6434,6435,6436],{"id":6289,"depth":1768,"text":6290},{"id":6299,"depth":1768,"text":6300},{"id":6315,"depth":1768,"text":6316},{"id":6329,"depth":200,"text":6330},{"id":6350,"depth":200,"text":6351},{"id":6382,"depth":200,"text":6383},{"id":6402,"depth":200,"text":6403},"2026-01-06","Sicurezza backend: vulnerabilità nelle dipendenze, secrets esposti e debug in produzione. Guida pratica per proteggere il tuo server.","/images/blog/sicurezza-backend-produzione.jpg",{},"/blog/2026-01-06-sicurezza-backend-produzione",{"title":6242,"description":6442},"Sicurezza backend in produzione: errori comuni e mitigazioni","sicurezza-backend-produzione","blog/2026-01-06-sicurezza-backend-produzione",[5163,4609,5645,4039],"L60YusAPF68P5dcsSTDpGPzVBA-NbNaKfB0PEL4yesI",{"id":6453,"title":6454,"body":6455,"category":1784,"date":6622,"description":6623,"extension":213,"image":6624,"meta":6625,"navigation":3,"path":6626,"published":3,"seo":6627,"seoTitle":6628,"slug":6629,"stem":6630,"tags":6631,"updated":229,"__hash__":6635},"blog/blog/2026-01-01-sito-web-senza-server-nuxt-cloudflare.md","Sito web senza server: perché scegliere Nuxt e Cloudflare",{"type":9,"value":6456,"toc":6608},[6457,6464,6467,6471,6474,6477,6481,6484,6487,6491,6494,6498,6501,6504,6508,6511,6514,6518,6521,6524,6528,6542,6549,6556,6560,6563,6566,6569,6573,6576,6580,6583,6594,6598,6601],[12,6458,6459,6460,6463],{},"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 ",[133,6461,6462],{"href":277},"MVP tirato via in fretta",": è un approccio architetturale preciso.",[12,6465,6466],{},"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.",[30,6468,6470],{"id":6469},"il-problema-che-tutti-fanno-finta-di-non-vedere","Il problema che tutti fanno finta di non vedere",[12,6472,6473],{},"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.",[12,6475,6476],{},"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.",[30,6478,6480],{"id":6479},"come-funziona-questo-sito-spoiler-niente-server-dietro","Come funziona questo sito (spoiler: niente server dietro)",[12,6482,6483],{},"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.",[12,6485,6486],{},"È 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.",[30,6488,6490],{"id":6489},"i-numeri-che-davvero-contano","I numeri che davvero contano",[12,6492,6493],{},"Basta chiacchiere, vediamo cosa cambia davvero.",[1649,6495,6497],{"id":6496},"costo-hosting-zero-euro-al-mese","Costo hosting: zero euro al mese",[12,6499,6500],{},"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.",[12,6502,6503],{},"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.",[1649,6505,6507],{"id":6506},"tempo-di-caricamento-meno-di-un-secondo","Tempo di caricamento: meno di un secondo",[12,6509,6510],{},"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.",[12,6512,6513],{},"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!",[1649,6515,6517],{"id":6516},"livelli-di-disponibilità-tipici-delle-grandi-cdn-globali","Livelli di disponibilità tipici delle grandi CDN globali",[12,6519,6520],{},"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.",[12,6522,6523],{},"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.",[30,6525,6527],{"id":6526},"la-sicurezza-di-chi-non-ha-niente-da-perdere","La sicurezza di chi non ha niente da perdere",[12,6529,6530,6531,6534,6535,6538,6539,103],{},"Qui inizia il bello. Un sito WordPress è un bersaglio facile in mille modi: ",[16,6532,6533],{},"SQL injection",", bug nel core, plugin pieni di buchi (ce ne sono migliaia), tentativi di ",[16,6536,6537],{},"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 ",[133,6540,6541],{"href":3144},"il tuo backend può diventare una bomba ad orologeria",[12,6543,6544,6545,6548],{},"Il mio sito, invece, ",[16,6546,6547],{},"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.",[12,6550,6551,6552,6555],{},"Il modo più semplice per non farsi rubare qualcosa? Non averlo. Questa è ",[16,6553,6554],{},"sicurezza progettata",", non rattoppata.",[30,6557,6559],{"id":6558},"il-rovescio-della-medaglia","Il rovescio della medaglia",[12,6561,6562],{},"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.",[12,6564,6565],{},"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.",[12,6567,6568],{},"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.",[30,6570,6572],{"id":6571},"per-chi-funziona-davvero","Per chi funziona davvero",[12,6574,6575],{},"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.",[30,6577,6579],{"id":6578},"facciamo-due-conti","Facciamo due conti",[12,6581,6582],{},"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.",[12,6584,6585,6586,6589,6590,6593],{},"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 ",[133,6587,6588],{"href":3152},"aggiornamenti delle dipendenze",". Il break-even, in molti casi, arriva nel giro del primo anno. Ma il vero vantaggio non è nei soldi: è ",[16,6591,6592],{},"dormire tranquilli"," sapendo che il sito non va giù alle tre di notte perché un plugin ha fatto i capricci.",[30,6595,6597],{"id":6596},"in-conclusione","In conclusione",[12,6599,6600],{},"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.",[12,6602,6603,6604,6607],{},"La tecnologia è andata avanti. Oggi puoi avere un sito ",[16,6605,6606],{},"più veloce, più sicuro e più affidabile"," spesso anche spendendo meno. Basta scegliere lo strumento giusto.",{"title":199,"searchDepth":200,"depth":200,"links":6609},[6610,6611,6612,6617,6618,6619,6620,6621],{"id":6469,"depth":200,"text":6470},{"id":6479,"depth":200,"text":6480},{"id":6489,"depth":200,"text":6490,"children":6613},[6614,6615,6616],{"id":6496,"depth":1768,"text":6497},{"id":6506,"depth":1768,"text":6507},{"id":6516,"depth":1768,"text":6517},{"id":6526,"depth":200,"text":6527},{"id":6558,"depth":200,"text":6559},{"id":6571,"depth":200,"text":6572},{"id":6578,"depth":200,"text":6579},{"id":6596,"depth":200,"text":6597},"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":6454,"description":6623},"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",[6632,6633,6634,5808,5163],"nuxt","cloudflare","jamstack","Wkr2d12saKUxUHbAUeBczwLjVUkEsmt0hSxHVDRkuZU",[6637,6638,6639,6640],{"slug":226,"name":1784},{"slug":5645,"name":5298},{"slug":3747,"name":210},{"slug":4757,"name":4746},1779395073451]