Come scegliere uno stack tecnologico (senza delegarlo all'AI)

Quando partiamo con un nuovo progetto, la domanda più ricorrente da parte dei clienti è sempre la stessa: "quale stack usate?". La risposta onesta, quella che deludiamo a volte raccontare, è: dipende. Dipende da cosa deve fare il sistema, da chi lo manterrà, da quanto velocemente deve evolversi e da quanto margine c'è sui costi operativi.

Negli ultimi mesi è diventato popolare chiedere direttamente a un modello AI di scegliere lo stack. In parte è comprensibile: l'output è rapido, sembra informato, cita tecnologie note. Il problema è che un LLM non sceglie, suggerisce. Se il contesto che gli forniamo è incompleto, la proposta sarà plausibile ma cieca rispetto a vincoli che non abbiamo raccontato, o che non sapevamo nemmeno di dover raccontare.

Questo articolo racconta come ragioniamo noi quando valutiamo uno stack, e perché riteniamo che la decisione finale debba restare in mano a chi ha esperienza concreta.

Partire dai vincoli, non dalla tecnologia

La prima domanda non è "Next.js o Nuxt?" ma "che cosa deve fare questo sistema, e per quanto tempo?". I vincoli tipici che guidano davvero una scelta di stack sono quattro:

• Funzionali: cosa deve fare, per chi, in quale contesto d'uso.
• Non funzionali: carichi attesi, latenza accettabile, affidabilità richiesta, sicurezza, compliance.
• Operativi: chi opererà il sistema, con quali competenze, con quale budget di manutenzione nel tempo.
• Evolutivi: in che direzione pensa di crescere il progetto, quali integrazioni sono prevedibili.

Solo dopo avere messo per iscritto questi quattro vincoli ha senso iniziare a ragionare su linguaggi, framework, database e infrastruttura. Invertire l'ordine significa scegliere una soluzione prima ancora di aver capito il problema.

I quattro vettori di valutazione

Per ogni componente dello stack (linguaggio, framework, database, hosting, layer applicativi) valutiamo quattro dimensioni:

1. Costo totale di possesso

Non solo la licenza o la fattura mensile del cloud. Va considerato il costo di onboarding del team, il costo di trovare persone che sappiano usarlo, il costo di manutenere le versioni nel tempo. Una tecnologia "gratuita" ma esoterica può costare più di una commerciale ben diffusa.

2. Rischio di esecuzione

Quanto è maturo lo stack? Quanto è ampia la community? Quali sono gli incident noti in produzione? Quanto spesso introduce breaking changes? Ogni scelta ha un profilo di rischio implicito che va dichiarato, non scoperto.

3. Evoluzione prevedibile

Dove sta andando il progetto nei prossimi 12-24 mesi? Una scelta che va bene oggi, su un MVP, potrebbe diventare un collo di bottiglia quando arriveranno integrazioni con sistemi legacy, requisiti di compliance o volumi di traffico moltiplicati.

4. Reversibilità

Quanto è facile cambiare idea? Alcune decisioni sono facilmente reversibili (sostituire una libreria UI), altre sono quasi irreversibili (cambiare database dopo anni di dati, o lasciare una piattaforma SaaS chiusa con lock-in profondo). Le decisioni irreversibili meritano molto più tempo di analisi.

Il ruolo dell'AI in questo processo

L'AI è utile, e la usiamo tutti i giorni. Ma al posto giusto. Ecco dove:

• Esplorazione rapida di alternative: per farsi un'idea panoramica di tecnologie emergenti o di pattern consolidati in un dominio sconosciuto.
• Sanity check: per cercare contro-argomenti alle nostre scelte, forzandoci a considerare vincoli che non avevamo messo in conto.
• Documentazione e onboarding: per produrre spiegazioni coerenti di una decisione già presa, accelerando il trasferimento di conoscenza.

Dove invece l'AI non deve decidere da sola:

• Sulla scelta finale di uno stack critico, perché non conosce i vincoli reali del progetto se non glieli raccontiamo noi, e non ha modo di verificare se il racconto è completo.
• Sui compromessi tra costo e rischio, perché sono valutazioni che dipendono dal profilo finanziario del cliente, dalla sua tolleranza al downtime, dalla sua roadmap commerciale.
• Sulla reversibilità delle decisioni, perché un LLM non ha memoria dei costi concreti di un refactoring lungo sei mesi in produzione.

Una checklist operativa

Prima di chiudere uno stack, questi sono i controlli minimi che facciamo:

1. I quattro vincoli (funzionali, non funzionali, operativi, evolutivi) sono scritti e firmati dal cliente?
2. Per ogni componente abbiamo un responsabile interno che lo conosce in produzione, non solo sulla carta?
3. Esiste un piano di uscita per i componenti più critici? Quanto costa abbandonarli?
4. Abbiamo identificato almeno due alternative per ogni componente chiave, con motivazione della scelta?
5. Sono chiari i costi operativi attesi nei primi 12 mesi, al netto della crescita?
6. Abbiamo considerato ciò che non vogliamo fare, oltre a ciò che vogliamo fare?

Se anche una sola di queste domande resta senza risposta, la decisione è prematura.

Perché la competenza conta ancora

La parte davvero difficile non è conoscere le tecnologie. È sapere quali combinazioni funzionano in produzione, quali collassano sotto carico, quali invecchiano bene e quali no. Questo tipo di conoscenza arriva solo dall'esperienza: sistemi che abbiamo costruito, manutenuto, migrato e, a volte, dovuto abbandonare con costi non banali.

Ogni scelta tecnica che facciamo oggi porta con sé la memoria di quelle esperienze. È quello che ci permette di essere cauti quando serve esserlo e coraggiosi quando il contesto lo permette. Un LLM, per quanto utile, non ha questa memoria. Ha solo testo.

La nostra proposta ai clienti è semplice: l'AI la usiamo, e tanto. Ma la firma su una decisione tecnica la mettiamo noi. È l'unico modo onesto di farlo.