Lo stack tecnologico per startup, elemento per elemento
La tavola
Con quali tecnologie costruiamo i prodotti?
Quattordici elementi in sei famiglie: sono le tecnologie che il gruppo usa davvero, nei progetti di My Web Lab e Giallo Studio, in Athleex e in questo sito. Seleziona una tessera: accanto trovi perché la usiamo, quando scegliamo altro e dove l'abbiamo usata.
Come si legge
Famiglia in alto, sigla al centro, nome in basso. Il colore indica la famiglia.
- Frontend
- Backend e dati
- Mobile
- AI e automazione
- Infrastruttura
- Motion e 3D
Next.js
Famiglia: Frontend
- Perché la usiamo
- Un solo framework per sito, web app e API, con pagine statiche veloci e indicizzabili: la SEO parte dal codice.
- Quando no
- Per uno strumento interno che nessuno cerca su Google può bastare qualcosa di più semplice; per un sito vetrina aggiornato da chi non scrive codice, un CMS.
- Dove l'abbiamo usata
- Nei siti e nelle web app su misura di My Web Lab, nella web app di Athleex e in questo sito.
React
Famiglia: Frontend
- Perché la usiamo
- Interfacce fatte di componenti riusabili, un ecosistema enorme e sviluppatori facili da trovare.
- Quando no
- Su pagine fatte quasi solo di testo è più di quanto serve: lì conta mandare al browser meno JavaScript possibile.
- Dove l'abbiamo usata
- Ovunque usiamo Next.js: progetti di My Web Lab, Athleex, questo sito.
TypeScript
Famiglia: Frontend
- Perché la usiamo
- Tipi dall'interfaccia al database: tanti errori emergono mentre scrivi il codice, non quando li trova un utente.
- Quando no
- Per uno script da usare una volta o un esperimento da buttare.
- Dove l'abbiamo usata
- In tutto lo stack condiviso del gruppo.
PostgreSQL
Famiglia: Backend e dati
- Perché la usiamo
- Database relazionale solido e open source: transazioni, vincoli, ricerca nel testo ed estensioni, senza legarti a un fornitore.
- Quando no
- Per una cache o per grandi volumi di dati davvero non strutturati esistono strumenti più adatti, da affiancare.
- Dove l'abbiamo usata
- È il database di Athleex, con backup notturni e una copia fuori sede.
Prisma
Famiglia: Backend e dati
- Perché la usiamo
- ORM per TypeScript: schema del database leggibile, query tipizzate, migrazioni versionate insieme al codice.
- Quando no
- Per query analitiche molto complesse scriviamo SQL a mano, accanto a Prisma.
- Dove l'abbiamo usata
- Nella web app di Athleex.
Capacitor
Famiglia: Mobile
- Perché la usiamo
- Porta la stessa base web su iOS e Android come app vere, con accesso alle funzioni del telefono: un solo codice, un solo team.
- Quando no
- Per giochi, grafica 3D pesante o un uso molto intenso delle funzioni native conviene un'app nativa o un altro framework.
- Dove l'abbiamo usata
- Le app iOS e Android di Athleex.
StoreKit 2
Famiglia: Mobile
- Perché la usiamo
- Il framework di Apple per gli acquisti in-app: serve quando vendi contenuti o funzioni digitali dentro un'app iOS.
- Quando no
- Se l'app non vende nulla al suo interno, o vende beni e servizi fisici.
- Dove l'abbiamo usata
- In Athleex: la revisione di Apple aveva respinto una versione per le regole sugli acquisti in-app (linea guida 3.1.1); con StoreKit 2 è passata.
Agenti AI
Famiglia: AI e automazione
- Perché la usiamo
- Modelli linguistici collegati agli strumenti, con permessi stretti e ogni passo registrato: fanno lavoro ripetitivo che chiede di leggere e scrivere testo.
- Quando no
- Se il processo è sempre uguale basta un workflow, più economico e prevedibile; se un errore costa caro, decide una persona.
- Dove l'abbiamo usata
- Nei progetti di Giallo Studio per le PMI italiane.
n8n
Famiglia: AI e automazione
- Perché la usiamo
- Orchestratore di workflow: collega app e API con flussi visibili, facili da modificare e da controllare.
- Quando no
- Per la logica centrale del prodotto, che va nel codice dell'applicazione con i suoi test.
- Dove l'abbiamo usata
- Nelle automazioni dei processi del gruppo, con Giallo Studio.
Hetzner
Famiglia: Infrastruttura
- Perché la usiamo
- Server in Europa a costi prevedibili, che gestiamo noi: i dati restano nell'Unione europea.
- Quando no
- Se nessuno nel team vuole gestire server, una piattaforma gestita costa di più ma toglie lavoro.
- Dove l'abbiamo usata
- Ospita Athleex, su server europei che gestiamo noi.
GitHub Actions
Famiglia: Infrastruttura
- Perché la usiamo
- CI automatica: a ogni modifica test, controlli dei tipi e build girano da soli prima della produzione.
- Quando no
- Per un sito statico minimo basta il deploy automatico della piattaforma che lo ospita.
- Dove l'abbiamo usata
- La CI di Athleex.
Three.js
Famiglia: Motion e 3D
- Perché la usiamo
- 3D nel browser con WebGL: scene, materiali e luci per esperienze che un'immagine ferma non rende.
- Quando no
- Dove la velocità conta più della scena, o quando un'immagine renderizzata dice la stessa cosa.
- Dove l'abbiamo usata
- Le scene 3D di questo sito.
GSAP
Famiglia: Motion e 3D
- Perché la usiamo
- Animazioni precise e legate allo scroll, che rispettano chi preferisce meno movimento sullo schermo.
- Quando no
- Per una transizione semplice basta il CSS.
- Dove l'abbiamo usata
- Nello stack condiviso del gruppo, compreso questo sito.
Blender Cycles
Famiglia: Motion e 3D
- Perché la usiamo
- Rendering fotorealistico per immagini e sequenze: luce e materiali credibili senza appesantire la pagina.
- Quando no
- Quando serve interazione in tempo reale: lì si usa Three.js.
- Dove l'abbiamo usata
- Le immagini di questo sito.
Le combinazioni
Quale stack per un MVP, un SaaS o un'app?
Gli stessi elementi si combinano in modo diverso a seconda di cosa costruisci. Sono i punti di partenza, da adattare al progetto.
| Cosa costruisci | Elementi | Perché |
|---|---|---|
| MVP web |
| Una sola base per interfaccia e API e dati relazionali da subito: si cambia in fretta e non si butta via tutto quando arrivano i clienti. |
| SaaS |
| Abbonamenti, ruoli e dati di più clienti chiedono un database solido, la CI e un'infrastruttura di cui controlli i costi. |
| App iOS e Android |
| La stessa base web diventa un'app per gli store; StoreKit 2 entra se vendi contenuti digitali dentro l'app iOS. |
| Funzioni AI e automazioni |
| Il modello lavora dal backend, i flussi ripetitivi in un orchestratore, i dati dove li controlli tu. |
| Sito di lancio |
| Pagine statiche veloci e indicizzabili; motion e 3D solo se aiutano a capire il prodotto. |
I criteri
Come scegliere lo stack tecnologico di una startup?
Scegli tecnologie mature, conosciute da molti sviluppatori e che non ti chiudono in un fornitore: lo stack deve farti uscire presto e permettere a un team nuovo di andare avanti.
- Persone
- Quanti sviluppatori lo conoscono? Uno stack raro rende difficile assumere e cambiare fornitore.
- Maturità
- Documentazione, aggiornamenti, una comunità che risponde. La novità del mese si paga in manutenzione.
- Una base, più canali
- Web, app e API dallo stesso codice: meno lavoro e meno errori quando il prodotto cresce.
- Costi di esercizio
- Hosting, database e chiamate ai modelli AI devono restare prevedibili mentre crescono gli utenti.
- Uscita
- Codice e dati devono restare tuoi e spostabili: niente piattaforme da cui non si esce.
Devi decidere senza un socio tecnico? È il lavoro del CTO as a service.
Domande sullo stack tecnologico
Qual è il miglior stack tecnologico per una startup?
Non ne esiste uno valido per tutte: conta che sia maturo, conosciuto da molti sviluppatori e adatto a quello che costruisci. Per web app e SaaS una combinazione molto diffusa è TypeScript con Next.js, React e PostgreSQL, che è anche la nostra base.
Next.js va bene per un SaaS?
Sì, per la maggior parte dei SaaS: tiene insieme interfaccia, API e pagine pubbliche indicizzabili in un solo progetto. Lo usiamo per la web app di Athleex, il nostro SaaS. Per carichi molto particolari si affiancano servizi dedicati.
Perché PostgreSQL e non un database NoSQL?
Perché quasi tutti i prodotti per startup hanno dati relazionali: utenti, abbonamenti, ordini, permessi. PostgreSQL li gestisce con transazioni e vincoli e tiene anche dati semi-strutturati in JSON. Un database NoSQL si affianca quando c'è un bisogno specifico.
Capacitor, React Native o Flutter per l'app di una startup?
Capacitor conviene quando hai già una web app e vuoi le app iOS e Android sulla stessa base, con un solo team: è la scelta che abbiamo fatto per Athleex. React Native o Flutter hanno senso quando l'app è il prodotto principale e chiede interfacce native molto curate.
Usate sempre queste tecnologie?
No: sono il punto di partenza, non un obbligo. Se il tuo progetto ha già uno stack che funziona, o un requisito che queste tecnologie non coprono bene, ne parliamo prima di scrivere codice.
Devi scegliere lo stack del tuo prodotto?
Rispondiamo entro un giorno lavorativo.
Parliamone