Come scegliere uno stack tecnico nel 2026: la nostra checklist

Scegliere lo stack tecnico di un nuovo progetto è il singolo commitment di lungo periodo più importante prima di scrivere una riga di codice. Vi accompagnerà per 5-15 anni. Lo riterete responsabile di metà dei vostri problemi futuri (ingiustamente, spesso), e di metà dei vostri successi (ingiustamente, anche quelli). Eppure la maggior parte delle scelte di stack si prende per inerzia, per moda o per chi parla più alto nel team. Vediamo una checklist concreta per farlo in modo deliberato nel 2026.

TL;DR

• Sette criteri di valutazione: talent pool, ecosystem maturity, longevity, operability, lock-in, AI tooling, fit con il dominio.
• Il talent pool italiano conta più di quanto sembri: assumere uno sviluppatore Rust in Italia nel 2026 costa 30-40% più di un Node.js per fit comparabile.
• L’evoluzione AI è il nuovo fattore strategico: stack che hanno buon supporto LLM nel coding assistance (Python, TypeScript, Go) accelerano lo sviluppo del 20-40% rispetto a stack di nicchia (Rust, Elixir, Clojure).
• La trappola della “tecnologia hype” è ovunque: ogni anno ci sono 2-3 framework “del futuro” che dopo 24 mesi sono stagnant. Resistere al new shiny è una skill di leadership tecnica.
• Lo stack che usiamo noi (TypeScript + Node.js + Postgres + Astro/React + Python solo per ML): scelte fatte deliberatamente per ottimizzare i 7 criteri sopra. Non è “il migliore”; è quello che ottimizza il nostro contesto.

Perché la scelta di stack conta nel 2026 (più che in altri anni)

Tre dinamiche del 2025-2026 hanno reso la scelta di stack più delicata che in passato:

Primo, l’AI coding assistance ha cambiato la produttività. Gli sviluppatori con Cursor, Claude Code, GitHub Copilot, Cline producono il 30-50% in più di codice testato e funzionante su stack ben supportati (TypeScript, Python, Go) rispetto a stack di nicchia. Lo stack non è più solo “facciamoci stare bene gli sviluppatori”: è “facciamogli accedere alla migliore tooling AI esistente”. Stack con poco volume di codice open-source pubblico (Elixir, Crystal, Nim) producono assistenza AI meno utile.

Secondo, il talent pool italiano è cambiato. Negli ultimi 5 anni si è polarizzato: cresce il numero di dev TypeScript, Python, Go, Rust; scende il numero di dev Ruby, Scala, PHP “puro”. Stack che 5 anni fa avevano un pool ampio (Ruby) oggi hanno scarsità talent in Italia. Sceglierli oggi è scommettere sulla disponibilità futura.

Terzo, la pressione cloud cost ha rivalutato l’efficienza. Stack interpretati con overhead alto (Python puro, Ruby, alcune configurazioni Node) costano più infrastructure su scala media-alta rispetto a Go, Rust, Java moderno. Sopra una certa soglia di traffico, lo stack diventa una voce di costo operativo non trascurabile.

I 7 criteri della checklist

Sette domande in ordine di importanza decrescente per il contesto italiano 2026. Ogni criterio dovrebbe ricevere un punteggio (1-5) e i punteggi pesati danno una valutazione complessiva.

1. Talent pool italiano

Quanti sviluppatori competenti su questo stack ci sono in Italia? Quanto costa assumerli? Quanto velocemente possiamo sostituirne uno che lascia?

Pool ampio (≥ 5.000 dev attivi in Italia): TypeScript/JavaScript, Python, Java, PHP, C#/.NET, SQL (su tutti i DB principali).

Pool medio (1.000-5.000 dev): Go, Kotlin, Swift, Rust, Vue.js, Ruby.

Pool ristretto (sotto 1.000 dev): Elixir, Clojure, Haskell, Scala, F#, OCaml.

Test concreto: aprite LinkedIn Italia, cercate “Go developer”. Confrontate con “Python developer”. La differenza nei risultati (e nelle aspettative salariali) è il vostro talent pool premium. Per progetti di 3-7 anni, sopravalutare la disponibilità talent è un errore comune.

2. Ecosystem maturity

Quante librerie pronte all’uso esistono per i problemi che dovrete risolvere? La maturità si misura concretamente: cercate le 10-15 librerie che sicuramente userete (autenticazione, ORM, web framework, queue, monitoring, ecc.) e valutate se sono mature, mantenute, documentate.

Eccellenti: Python, TypeScript/Node, Java, C#. Ecosystem di decenni con copertura quasi totale.

Buoni: Go (cresciuto molto), Rust (cresciuto ma alcune nicchie ancora deboli), Ruby (storico, ora in flessione).

Limitati: linguaggi più giovani (Zig, Crystal, Gleam), che hanno core tecnicamente eccellenti ma ecosystem da costruire.

Un ecosystem immaturo significa scrivere voi quello che in altri stack è una npm install. Costa.

3. Longevity (resta vivo nei prossimi 10 anni?)

I framework e i linguaggi seguono cicli di vita. La probabilità che il vostro stack sia ancora rilevante nel 2036 è un fattore strategico.

Alta longevity: linguaggi maturi con grande base installata (Java, Python, JavaScript, C#, Go, SQL). Probabilità >85% che siano ancora primary nel 2036.

Longevity media: linguaggi con backing forte e adozione crescente (Rust, Kotlin, Swift). Probabilità 70-85%.

Longevity incerta: linguaggi/framework di nicchia o nuovissimi (Bun runtime, Deno, framework giovani come Astro stesso). Probabilità 40-70%.

Bassa longevity: framework hype-driven con boom + bust (CoffeeScript, AngularJS, varie generation di “the next big thing”). Probabilità sotto 40%.

Il principio operativo: il core del vostro stack (linguaggio, DB principale) deve essere ad alta longevity. Le periferie (framework di UI, librerie singole) possono essere a longevity media. Costruire tutto su componenti a bassa longevity è scommettere su un singolo cavallo.

4. Operability (quanto è facile da gestire in produzione?)

Lo stack genera operational overhead: monitoring, deployment, debugging, scaling. Diversi stack hanno diversi profili.

Operability eccellente: Go (binari statici, deploy semplice, runtime veloce), Java (mature tooling, observability profondissima), TypeScript/Node (semplice da deployare, ecosystem ricco).

Operability media: Python (GIL, dependency hell occasionale, cold start lenti), Ruby (memory consumption, GC), C#/.NET (eccellente su Windows/Azure, mediamente OK altrove).

Operability complessa: Rust (compilazione lunga, learning curve toolchain), C++ (memory management, build systems), Elixir/Erlang (mental model BEAM, debugging differente).

Cosa misurare: tempi di build, dimensione artefatti deployati, complessità del runtime, qualità degli strumenti di osservabilità (APM, distributed tracing, profiling).

5. Lock-in (quanto facilmente potete cambiare in futuro?)

Lock-in tecnologico = capacità di abbandonare lo stack senza riscrivere tutto.

Basso lock-in: linguaggi standard con multiple implementazioni, framework open-source con buona portabilità. Esempio: codice TypeScript con un web framework portabile (Express, Fastify) può migrare a un altro framework con costo limitato.

Lock-in medio: framework opinionati ma open-source. Esempio: Rails, Django, Laravel - migrare via è una riscrittura significativa ma fattibile.

Lock-in alto: piattaforme proprietarie. Esempio: tecnologie chiuse di vendor specifici, low-code platform proprietarie, function-as-a-service con runtime non-standard.

Per progetti di lungo periodo, ridurre il lock-in è strategico anche se nessuno pensa di cambiare oggi. Le aziende che 10 anni fa scelsero Heroku scoprono ora cosa significa lock-in quando i prezzi cambiano.

6. AI tooling compatibility (criterio nuovo)

Nel 2026, la qualità degli assistenti AI di sviluppo per il vostro stack è un fattore reale di produttività.

Eccellente AI support: Python, TypeScript/JavaScript, Go, Java, C#. Volumi enormi di codice pubblico, LLM allenati su questi, autocomplete e generation superiori.

Buono: Rust, Swift, Kotlin, PHP. Volumi crescenti, qualità AI in miglioramento.

Mediocre: Ruby (volume in calo), Scala, R, Elixir.

Limitato: Haskell, Clojure, Erlang, linguaggi di nicchia.

L’impatto pratico: su Python uno sviluppatore con Claude Code o Cursor produce il 30-50% in più di codice utile. Su Haskell, l’incremento è del 5-15%. Non è marginale.

7. Fit con il dominio

Alcuni domini hanno fit tecnico naturale con stack specifici. Ignorarlo è inefficiente.

ML/data science: Python è dominante per ragioni di ecosystem (PyTorch, scikit-learn, pandas). Altre scelte richiedono bridge costosi.

Sistemi a bassa latenza ad alta scala: Go, Rust, Java moderno. Python e Ruby pagano l’overhead.

Sviluppo mobile nativo: Swift (iOS), Kotlin (Android). Cross-platform: React Native o Flutter.

Sistemi enterprise integrazione: Java, C#/.NET hanno il vantaggio di decenni di integrazioni esistenti.

Web full-stack moderno: TypeScript end-to-end (Node + React/Vue/Svelte + Postgres) è oggi quasi sempre la scelta ottimale per progetti web moderni di scala media.

La trappola della “tecnologia hype”

Ogni 18-24 mesi nasce un framework che “cambia tutto”. Negli ultimi 5 anni: Deno (2020), Bun (2022), HTMX (2023), Astro (2023), Tauri (2023), Hono (2024), tanti altri. Alcuni si stabilizzano (Astro è ormai mainstream). Altri restano interesting experiments senza adozione enterprise (HTMX, Tauri).

Il problema: chi sceglie il framework hype in fase di forte hype paga un costo nascosto se quello non si stabilizza. Ecosystem limitato, library mancanti, talent scarsi, AI tooling parziale.

La regola operativa: per il core del vostro stack (linguaggio, DB, runtime), aspettare almeno 24-36 mesi dal momento in cui il framework diventa popolare prima di adottarlo. Se a 36 mesi è ancora rilevante (vedi Astro, Next.js), può essere adottato con minor rischio. Per peripheral concerns (un componente di UI, un tool di build) il rischio è minore: potete sperimentare.

Caso concreto: Bun runtime nel 2024 era hype. Nel 2026 ha maturato e ha adozione reale, ma il talent pool italiano è ancora sotto Node.js standard di 10x. Adottarlo per un progetto enterprise significa scommettere che fra 5 anni il pool sarà cresciuto. Forse sì, forse no.

Lo stack che usiamo noi (e perché)

Per trasparenza, lo stack che oggi adottiamo come default in Obsidian Technologies su nuovi progetti:

• Linguaggio principale: TypeScript end-to-end (frontend + backend). Massimo talent pool, eccellente AI tooling, longevity alta, lock-in basso.
• Runtime backend: Node.js (recente LTS). Alternativa Bun per progetti specifici dove la performance conta. Restiamo prudenti su Deno.
• Database primario: PostgreSQL. Maturità decennale, talent pool universale, ecosystem superiore, operability eccellente.
• Cache/queue: Redis. Standard di settore, operability ottima.
• Frontend framework: Astro per siti contenutistici (questo blog è in Astro), React/Next.js per applicazioni complesse. Vue per progetti con team che lo conosce meglio. Niente Angular nuovo, Angular legacy si mantiene.
• Mobile: React Native quando serve cross-platform. Native (Swift/Kotlin) quando il prodotto è solo mobile e merita team dedicato.
• Python: solo per ML, data science, integrazioni Python-specific. Non per backend web standard.
• Cloud: Vercel per progetti frontend-heavy, Fly.io per backend custom, AWS/Azure/GCP per scenari enterprise.
• AI tooling: Claude Code + Cursor come coding assistant standard. GPT API o Claude API per applicazioni che servono LLM.

Le scelte che NON facciamo (e perché):

• Rust per backend web: eccellente per sistemi a bassa latenza, ma per la maggior parte dei progetti enterprise italiani il talent pool è troppo ristretto e i tempi di sviluppo si allungano del 30-50%.
• Java moderno: non è sbagliato, ma per progetti nuovi il costo di sviluppo è maggiore di TypeScript. Lo usiamo solo dove c’è infrastruttura Java esistente da preservare.
• PHP: non è morto, ma il talent pool italiano qualificato si è spostato altrove. Lo manteniamo solo su progetti legacy.
• Microservices come default: complessità operativa elevata. Adottabile solo sopra certe soglie di scala e di team size. Per il 90% delle nostre soluzioni modular monolith è la scelta giusta.

Questo non è “lo stack perfetto”. È lo stack che ottimizza il nostro contesto specifico (servizi a PMI italiane, team medio-piccolo, time-to-market importante). Il vostro contesto può richiedere scelte diverse.

Errori comuni nella scelta di stack

1. Lasciare scegliere allo sviluppatore più vocal. Il dev che parla più alto nel team spesso ha bias personali (“voglio imparare Rust”, “Vue è meglio di React perché lo conosco”). La scelta strategica va presa dalla leadership tecnica con input dal team, non outsourced al più convinto.

2. Scegliere per conference-driven development. Adottare uno stack perché “tutti ne parlano alla conference” o “lo usa Netflix” senza valutare se il vostro contesto somiglia a quello dell’utente di riferimento. Netflix usa Java e Python su scala diversa dalla vostra; cosa funziona per loro non necessariamente funziona per voi.

3. Non considerare il talent pool nel medio periodo. Lo stack viene scelto per il team attuale. Ma il team cambia: dopo 5 anni il core team originale spesso non è più lì. Se lo stack è esotico, sostituire diventa un problema.

4. Sottovalutare l’AI tooling. Nel 2026 chi sceglie uno stack a basso supporto AI accetta una productivity gap del 25-40% sui prossimi 5 anni. È un costo che si capitalizza in salari, time-to-market, qualità del codice.

5. Cambiare stack a metà progetto. La tentazione di “lasciamo perdere quello che abbiamo iniziato, riprendiamo con X che è meglio” è quasi sempre sbagliata se il progetto è oltre il 30%. Il costo di switch supera il beneficio. Le aziende che lo fanno spesso ripetono lo stesso errore con un terzo stack 2 anni dopo.

6. Architettura su misura senza necessità. Costruire microservices, event-driven, CQRS, hexagonal architecture da zero per progetti che non li richiedono è il singolo maggior generatore di over-engineering nel 2026. Si parte sempre da un modular monolith ben scritto.

FAQ

Come si valuta lo stack di un progetto già esistente per capire se mantenerlo o cambiarlo?

Cinque domande: (1) il talent pool sta scendendo (es. PHP)? (2) la longevity è a rischio (es. framework deprecated)? (3) l’AI tooling è scarso? (4) i costi operativi sono in crescita? (5) il fit col dominio è cambiato (es. siete diventati più AI-heavy)? Se sì a 2+ domande, valutare migrazione graduale. Se 1 sì, valutare upgrade dentro lo stack invece di cambio.

Conviene fare progetti cross-stack (backend in linguaggio diverso da frontend)?

In Obsidian preferiamo monolinguaggio dove possibile (TypeScript fullstack) per ridurre context switch, condividere tipi, semplificare assunzioni. Cross-stack (es. Python backend + TypeScript frontend) ha senso quando il dominio impone Python (ML), o quando il team interno è diviso per competenze e questo è efficiente. Non come scelta di default.

Lo stack open-source vs proprietario: differenza pratica?

Open-source è quasi sempre preferibile per ridurre lock-in. Eccezione: tecnologie proprietarie che sono de facto standard (AWS RDS, Vercel, ecc.), dove il vendor lock-in è accettato in cambio di riduzione operativa. Mai scegliere proprietario per il core business logic.

Quanto pesa la disponibilità di librerie open-source italiane?

Praticamente zero come fattore di scelta. Le librerie open-source globali (npm, pip, crates.io) sono ciò che conta. La produzione italiana è marginale ovunque.

Come si gestisce il fear of missing out sui nuovi framework?

Avere un innovation budget del 10-15% del tempo del team dedicato a esplorare nuove tecnologie senza committarsi. I dev possono sperimentare Bun, HTMX, Tauri, ecc. in side project aziendali. Se qualcosa matura nei 2-3 anni successivi e diventa adottabile, il team ha già esperienza. Se non matura, non si è investito in produzione.

Il technology radar di ThoughtWorks/Gartner è utile?

Sì come input, no come oracolo. Pubblicano valutazioni utili sulla maturità delle tecnologie. Sono biased verso il consulting enterprise (preferiscono tecnologie che vendono bene), e parzialmente verso lo USA market. Usateli come una voce, non come la voce.

Conclusione

Scegliere lo stack tecnico nel 2026 richiede deliberatezza più che mai. I criteri di una volta (linguaggio comodo per il team, framework che mi piace) sono insufficienti: il talent pool, l’AI tooling, la longevity, l’operability sono fattori strategici che vanno valutati esplicitamente. Le aziende che lo fanno costruiscono prodotti che invecchiano bene per 8-15 anni. Quelle che non lo fanno si trovano a rincorrere riscritture ogni 4-5 anni.

Se state per iniziare un progetto nuovo e volete una valutazione di stack indipendente per il vostro caso, parliamone. Possiamo fare una sessione di stack assessment di 4-8 ore che vi fa risparmiare anni di rimpianti.

Per approfondire: la pagina pilastro software custom security-aware, e l’articolo correlato software custom vs SaaS per chi sta decidendo se costruire o comprare.