Il tech stack non è una decisione tecnica. È una decisione di business. E la maggior parte dei founder la delega alla persona sbagliata.
L'ho visto accadere centinaia di volte in oltre 12 anni e più di 100 prodotti: un founder assume uno sviluppatore, lo sviluppatore sceglie quello con cui si trova più a suo agio, e sei mesi dopo la startup è bloccata con una tecnologia che non scala, costa una fortuna da mantenere, o — peggio ancora — non riesce ad attrarre altri ingegneri disposti a lavorarci.
Ecco la verità scomoda: il tuo primo sviluppatore non è quasi mai la persona giusta per scegliere il tech stack. Ottimizzerà per ciò che conosce, non per ciò di cui il tuo business ha bisogno. Non è una critica — è la natura umana. Ma è tuo compito come founder assicurarti che la decisione venga presa con il quadro completo in mente.
In questo articolo, ti guiderò attraverso l'esatto framework che utilizzo quando consiglio le startup sulle loro scelte tecnologiche. Niente hype, niente trend della settimana, solo una guida pratica che è stata testata su piattaforme SaaS, marketplace, prodotti fintech, app mobile e tutto il resto.
Perché il tech stack è importante (e perché non è così importante come pensi)
Permettimi di iniziare con un paradosso. Il tuo tech stack è enormemente importante — e allo stesso tempo, conta molto meno di quanto la maggior parte dei founder pensi.
È importante perché determina quanto velocemente puoi lanciare, quanto facilmente puoi assumere, quanto costa la tua infrastruttura e quanto sarà doloroso ogni cambiamento tra dodici mesi. Una scelta sbagliata qui crea debito tecnico composto che prosciuga il tuo budget.
Non è così importante come pensi perché non esiste un unico tech stack "migliore". React vs Vue? Django vs Rails? AWS vs GCP? Per il 90% delle startup, qualsiasi di queste scelte funzionerà benissimo. La differenza tra successo e fallimento non dipende quasi mai dal fatto che tu abbia scelto PostgreSQL o MongoDB. Dipende dall'esecuzione.
Il parere di Michele
Il tech stack perfetto che nessuno nel tuo team sa usare è infinitamente peggio di uno stack "abbastanza buono" con cui il tuo team può iniziare a sviluppare domani. Ho visto startup bruciare tre mesi e 80.000€ riscrivendo un prototipo funzionante in un framework "migliore". Non essere quel founder.
C'è un concetto nell'ingegneria chiamato "la tecnologia noiosa vince". È stato coniato da Dan McKinley di Etsy, ed è una delle cose più vere mai dette sulla costruzione di prodotti. Tecnologie provate, ben documentate e ampiamente adottate supereranno sempre l'ultima novità. Perché? Perché quando avrai un problema alle 2 di notte — e avrai un problema alle 2 di notte — avrai bisogno di risposte su Stack Overflow, non di issue su GitHub con zero risposte.
Il tuo obiettivo non è avere il tech stack più impressionante. Il tuo obiettivo è lanciare un prodotto che funziona, attrae utenti e può scalare quando necessario. Tutto il resto è ego.
Il framework decisionale in 4 passi
Dopo aver costruito oltre 100 prodotti, ho ridotto la decisione sul tech stack a quattro passi sequenziali. Segui questi correttamente e tutto il resto andrà al suo posto.
Passo 1: definisci i tuoi vincoli
Prima ancora di pensare ai linguaggi di programmazione, rispondi onestamente a queste quattro domande:
- Budget: Quanto puoi spendere nello sviluppo nei prossimi 6-12 mesi? Questo determina se costruisci su misura o sfrutti framework e low-code dove possibile.
- Tempistiche: Quando devi lanciare? Se la risposta è "ieri", hai bisogno di uno stack ottimizzato per la velocità, non per la perfezione.
- Team: Chi hai in questo momento? Cosa sanno fare? Per cosa puoi realisticamente assumere nel tuo mercato?
- Tipo di prodotto: Stai costruendo una dashboard ricca di dati, un'app mobile per consumatori, un marketplace e-commerce o uno strumento di collaborazione in tempo reale? Ognuno richiede punti di forza tecnici diversi.
Questi vincoli eliminano l'80% delle opzioni immediatamente. Ed è esattamente ciò che vuoi — meno scelte, decisioni più rapide. Se il tuo budget è limitato e la tua timeline è di 3 mesi, non stai costruendo un cluster Kubernetes personalizzato. Stai facendo il deploy su Vercel o Railway e vai avanti con la tua vita. Per un approfondimento sul budget, leggi la mia guida su quanto costa costruire un MVP.
Passo 2: web, mobile o entrambi?
Questo è il bivio che determina tutto ciò che viene dopo. Ecco come la vedo:
| Approccio | Ideale per | Pro | Contro |
|---|---|---|---|
| Web Responsive (Next.js / Nuxt) | SaaS B2B, dashboard, piattaforme di contenuti | Un unico codebase, veloce da sviluppare, ottimo SEO | Nessuna presenza sugli app store, API del dispositivo limitate |
| Progressive Web App (PWA) | Marketplace, media, utility | Funziona offline, installabile, un unico codebase | Supporto iOS limitato, niente notifiche push su Safari (in miglioramento) |
| React Native / Expo | App consumer che necessitano presenza sugli app store | Un unico codebase per iOS + Android, grande community | Limiti di prestazioni per UI complesse, difficoltà con i moduli nativi |
| Nativo (Swift + Kotlin) | App ad alte prestazioni (gaming, AR, fintech) | Migliori prestazioni, accesso completo alle API | Costo di sviluppo doppio, manutenzione doppia, iterazione più lenta |
Il mio consiglio predefinito per la maggior parte delle startup: inizia con un'app web responsive. Potrai sempre aggiungere un'app mobile in seguito. Ma se il tuo prodotto è intrinsecamente mobile — pensa al fitness tracking, ride-hailing, social networking — allora React Native con Expo ti offre il miglior rapporto qualità-prezzo nella fase MVP.
Passo 3: scegli il tuo backend
Il backend è dove risiede la tua logica di business. Ecco la mia opinione sincera sui principali contendenti:
| Stack | Ideale per | Perché | Attenzione a |
|---|---|---|---|
| Python / Django | Prodotti data-heavy, funzionalità ML/AI, SaaS B2B | Tutto incluso, pannello admin incredibile, ecosistema enorme | Può essere più lento con alta concorrenza senza pattern asincroni |
| Node.js / Express o Fastify | App in tempo reale, API, team JavaScript-heavy | Stesso linguaggio front e back, enorme ecosistema npm, ottimo I/O asincrono | Complessità dei callback, facile scrivere codice disordinato su larga scala |
| Ruby on Rails | MVP rapidi, marketplace, piattaforme di contenuti | Convention over configuration, tempo di prototipazione più veloce | Più difficile assumere in alcuni mercati, limiti di prestazioni |
| Go | Microservizi ad alte prestazioni, strumenti infrastrutturali | Velocissimo, eccellente concorrenza, deployment semplice | Curva di apprendimento più ripida, ecosistema web più piccolo, iterazione più lenta |
Se non sei sicuro, scegli Node.js o Python. Entrambi hanno community enormi, per entrambi è facile assumere, ed entrambi ti porteranno da zero a milioni di utenti senza problemi. La decisione spesso si riduce alla preferenza del team — e questo va benissimo.
Passo 4: scegli la tua infrastruttura
L'infrastruttura è dove i founder sovraingegnerizzano più frequentemente. Non hai bisogno di AWS con Terraform e un cluster Kubernetes multi-regione per la tua beta con 50 utenti. Ecco la progressione che raccomando:
- 0-1.000 utenti: Vercel (frontend) + Railway o Render (backend) + PostgreSQL gestito. Costo totale: 0-50€/mese. Deploy in minuti, non giorni.
- 1.000-50.000 utenti: AWS o GCP con servizi gestiti (RDS, ECS/Cloud Run, S3). Avrai bisogno di uno sviluppatore con competenze DevOps ma non di un team DevOps dedicato.
- 50.000+ utenti: Ora puoi iniziare a pensare all'orchestrazione dei container, CDN, livelli di caching e il resto. Ma a questo punto, puoi permetterti di assumere per questo.
Il principio chiave: inizia con l'infrastruttura più semplice che funziona, e scala solo quando le metriche lo richiedono. Ogni livello di complessità che aggiungi prima del necessario è una tassa sulla tua velocità.
Tech stack consigliati per tipo di startup
Dopo aver costruito prodotti in quasi tutti i settori, ecco gli stack che raccomando più spesso. Non sono teorici — sono le combinazioni che ho visto avere successo in produzione, sotto pressione reale, con utenti reali.
SaaS B2B
React + Python/Django + PostgreSQL + AWS
Il pannello admin integrato di Django da solo fa risparmiare settimane di sviluppo sugli strumenti interni. PostgreSQL gestisce query complesse e reportistica in modo eccellente. React ti offre un frontend ricco e interattivo. AWS fornisce le certificazioni di conformità (SOC 2, HIPAA) che i clienti enterprise chiederanno prima o poi. Questo è lo stack cavallo di battaglia per un motivo.
Marketplace / Piattaforma
Next.js + Node.js + PostgreSQL + Stripe + AWS
I marketplace hanno bisogno di un ottimo SEO (Next.js ti offre il server-side rendering out of the box), aggiornamenti in tempo reale (Node.js), dati relazionali complessi (PostgreSQL) e pagamenti (Stripe Connect per pagamenti multi-parte). Ho costruito diversi marketplace di successo con esattamente questo stack. Funziona.
App mobile-first per consumatori
React Native + Node.js + Firebase (MVP) → AWS (scala)
Per le app consumer dove la velocità di iterazione conta sopra tutto, inizia con Firebase per autenticazione, database e notifiche push. È incredibilmente veloce da configurare. Quando raggiungerai i limiti di Firebase — e li raggiungerai intorno ai 10-20K utenti attivi — migra il tuo backend su AWS con un layer API appropriato. Questo è un compromesso deliberato: velocità ora, costo di migrazione dopo. Per la maggior parte delle startup, è la scommessa giusta.
Fintech / Healthtech (settori regolamentati)
React + Python o Java + PostgreSQL + AWS (con focus sulla compliance)
Nei settori regolamentati, le scelte del tech stack sono in parte dettate dai requisiti di conformità. Servono audit trail, crittografia a riposo e in transito, controlli sulla residenza dei dati e una solida gestione degli accessi. Questo significa AWS (con le sue certificazioni di conformità), PostgreSQL (con row-level security) e un linguaggio backend con tipizzazione forte e strumenti di sicurezza. Python con type hints o Java/Kotlin sono scelte eccellenti qui. Evita qualsiasi cosa sperimentale.
Il parere di Michele
Ho visto founder nel fintech scegliere architetture serverless all'avanguardia perché suonavano moderne nelle presentazioni agli investitori. Poi hanno scoperto che il loro auditor di conformità non riusciva a capire l'architettura, e hanno speso due mesi a ristrutturare tutto in qualcosa di verificabile. Nei settori regolamentati, conservativo non è noioso — è intelligente.
5 errori sul tech stack che vediamo ogni settimana
Questi non sono casi limite. Vedo questi errori costantemente, in startup di ogni dimensione e settore. Se ne stai commettendo qualcuno, non sei solo — ma dovresti correggerli ora.
1. Microservizi per un MVP
Hai tre sviluppatori e nessun utente. Non hai bisogno di otto microservizi, una coda di messaggi e un API gateway. Inizia con un monolite. Sul serio. Shopify gira su un monolite. Anche Twitter lo ha fatto per anni. Un monolite ben strutturato è infinitamente meglio di un insieme di microservizi mal strutturati. Potrai sempre estrarre servizi in seguito, quando capirai davvero i confini del tuo dominio — cosa che non succederà finché non avrai utenti reali.
2. Kubernetes per 100 utenti
Kubernetes è uno strumento fenomenale — per aziende con il team e il traffico per giustificarlo. Se non hai ancora raggiunto il product-market fit, K8s è un lavoro a tempo pieno travestito da scelta infrastrutturale. Usa un Platform-as-a-Service invece. Svilupperai 10 volte più veloce.
3. "Il mio sviluppatore conosce solo X, quindi usiamo X"
Questo è l'errore più comune e più pericoloso. Le tue scelte tecnologiche dovrebbero servire il tuo business, non la zona di comfort del tuo sviluppatore. Una volta ho visto una startup costruire una piattaforma di editing collaborativo in tempo reale in PHP perché era ciò che il loro lead developer conosceva. È stato un incubo. Se la tecnologia giusta per il tuo prodotto non corrisponde alle competenze del tuo team, hai bisogno di un team diverso — o almeno di un fractional CTO che possa colmare il divario.
4. Rincorrere il linguaggio più nuovo e trendy
Rust per un'app CRUD web. Elixir per una landing page. Bun al posto di Node perché è 2 volte più veloce in un benchmark che non raggiungerai mai. Il cimitero delle startup è pieno di prodotti costruiti su tecnologie trendy da sviluppatori che volevano arricchire il proprio CV. Ottimizza per le assunzioni, il supporto della community e l'ecosistema di librerie — non per il karma di Hacker News.
5. Non pensare al deployment dal giorno 1
Ho revisionato codebase dove l'app funzionava perfettamente sul laptop dello sviluppatore ma non era mai stata deployata da nessuna parte. Nessuna pipeline CI/CD, nessuna gestione delle variabili d'ambiente, nessun ambiente di staging. Il deployment dovrebbe far parte del tuo primo sprint, non dell'ultimo. Se non puoi fare il deploy, non puoi lanciare. E se non puoi lanciare, non esiste. Questo è anche strettamente legato alla più ampia decisione build vs buy — a volte il percorso più veloce verso la produzione è non costruire affatto.
Il ruolo dell'AI nel tuo tech stack (2026)
Ogni founder mi chiede dell'AI adesso. "Dovremmo aggiungere l'AI al nostro prodotto?" "I nostri sviluppatori dovrebbero usare Copilot?" "Possiamo sostituire il nostro backend con un LLM?" Ecco la mia risposta sincera.
Dove l'AI ha senso
- Produttività degli sviluppatori: GitHub Copilot, Cursor e strumenti simili aumentano genuinamente la velocità di sviluppo del 20-40% per sviluppatori esperti. Ogni team con cui lavoriamo li usa ormai. Sono indispensabili.
- Funzionalità AI nel tuo prodotto: Ricerca, raccomandazioni, generazione di contenuti, analisi dati — se il tuo prodotto può essere significativamente migliorato dalle capacità dell'AI, integrale tramite API (OpenAI, Anthropic, Mistral). Non addestrare i tuoi modelli a meno che tu non abbia un dottorando in organico e un'ottima ragione.
- Automazione: Chatbot per il supporto clienti, elaborazione documenti, classificazione email — questi sono casi d'uso maturi dove l'AI aggiunge un valore chiaro e misurabile.
Dove l'AI NON ha senso
- Sostituire la logica di business con gli LLM: Il tuo motore di pricing, l'elaborazione dei pagamenti e il sistema di permessi dovrebbero essere codice deterministico, non AI probabilistica. Gli LLM hanno allucinazioni. Il tuo sistema di fatturazione non dovrebbe.
- "AI-first" senza un caso d'uso chiaro: Se stai aggiungendo l'AI al tuo pitch deck ma non riesci ad articolare quale problema risolve per gli utenti, non ne hai bisogno. Gli investitori sono già stanchi di prodotti "AI-powered" che sono solo app CRUD con un wrapper di ChatGPT.
- Costruire modelli personalizzati nella fase MVP: Il fine-tuning e l'addestramento sono costosi e lenti. Usa le API prima. Costruisci modelli personalizzati solo quando hai validato la funzionalità e hai bisogno di ottimizzazione delle prestazioni o dei costi.
Strumenti che raccomandiamo nel 2026
Per gli sviluppatori: GitHub Copilot o Cursor per la generazione di codice. Per le funzionalità AI: OpenAI API o Anthropic Claude per il testo, Pinecone o Weaviate per la ricerca vettoriale, LangChain solo se hai genuinamente bisogno di agenti. Per l'infrastruttura: Vercel AI SDK, AWS Bedrock o Google Vertex AI a seconda del tuo cloud provider.
La conclusione
Scegliere un tech stack non significa trovare la tecnologia "migliore". Significa trovare la tecnologia giusta per i tuoi vincoli specifici — il tuo budget, le tue tempistiche, il tuo team e il tuo prodotto. Il miglior stack è quello che ti permette di lanciare velocemente, iterare rapidamente e scalare quando (e solo quando) ne hai bisogno.
Inizia con cose noiose. Inizia semplice. Inizia a lanciare. Potrai sempre fare refactoring dopo, ma non potrai recuperare i sei mesi passati a discutere di linguaggi di programmazione mentre il tuo concorrente ha già lanciato.
Se non sai da dove iniziare, è una delle primissime cose che definiamo nella nostra fase di discovery. Analizzeremo la tua visione del prodotto, i tuoi vincoli e il tuo mercato, e ti consiglieremo lo stack più semplice che ti porti al lancio — e oltre.
“La migliore decisione tecnologica è quella che mette il tuo prodotto nelle mani degli utenti il più velocemente possibile. Tutto il resto è un'ottimizzazione prematura.”
— Michele Cimmino