Capire la terminologia tecnica non significa saper programmare. Significa poter prendere decisioni informate, valutare le scelte del tuo team, e non essere dipendente da chi ti spiega le cose. Secondo First Round Capital (2024), i founder con competenze tecniche di base raccolgono in media il 30% di funding in più rispetto a chi delega ogni decisione tecnica senza comprenderla. Un report di Atomico (2024) conferma che il 68% degli investitori europei considera la technical literacy del founder un fattore determinante nella decisione di investire.
Questo glossario ti dà il vocabolario essenziale. Non per farti diventare tecnico, ma per farti smettere di annuire quando non capisci cosa ti stanno dicendo. Se vuoi una visione più ampia su come muoverti da founder non tecnico nel 2026, parti da lì.
Cosa sono frontend e backend?
Il frontend è tutto quello che l’utente vede e tocca. Il backend è la logica invisibile che gira sui server. Secondo il sondaggio Stack Overflow Developer Survey (2024), React resta il framework frontend più usato al mondo con il 40% di adozione, seguito da Vue e Svelte. Capire questa distinzione ti permette di valutare i preventivi e le scelte tecnologiche del tuo team.
Frontend comprende le schermate, i bottoni, la navigazione. Gira nel browser o nel telefono dell’utente. Quando qualcuno dice “il frontend è lento”, intende che l’interfaccia risponde con ritardo ai comandi. Le tecnologie frontend più comuni nel 2026 sono React, Vue, Svelte e Astro per il web. Per le app mobile: Swift (iOS), Kotlin (Android), oppure framework cross-platform come React Native e Flutter.
Backend è la logica che gira sui server: calcoli, autenticazione, accesso al database, invio email. L’utente non lo vede mai direttamente. Quando il backend ha problemi, l’utente vede messaggi di errore o schermate che non caricano, ma non può “vedere” dove sta il problema. Le tecnologie backend più diffuse includono Node.js, Python, Go e Ruby.
La scelta del linguaggio backend influenza i costi di sviluppo, la velocità del prodotto e la facilità di trovare sviluppatori. Sai qual è il costo reale della scelta sbagliata? Molte decisioni di prodotto hanno implicazioni diverse su frontend e backend. Aggiungere un filtro di ricerca sembra semplice lato frontend, ma se il database non è strutturato per supportarlo, il backend diventa complicato. Per capire come queste scelte impattano il tuo prodotto, leggi cosa devi sapere sullo stack tecnico prima di costruire la tua app.
Database: SQL e NoSQL
Un database è dove vengono salvati i dati della tua applicazione. Secondo il DB-Engines Ranking (2025), PostgreSQL è il database in più rapida crescita da cinque anni consecutivi ed è la scelta predefinita della maggior parte delle startup SaaS in fase early-stage. La scelta del database non è un dettaglio tecnico: impatta la struttura di ogni feature futura.
Senza un database, la tua app non ricorda niente. Ogni volta che un utente chiude l’app e la riapre, tutto quello che ha fatto sarebbe perso.
SQL (PostgreSQL, MySQL) organizza i dati in tabelle con relazioni rigide. Pensa a un foglio Excel molto potente: ogni riga è un record, ogni colonna è un campo, e puoi creare collegamenti tra tabelle diverse. Un utente ha molti ordini, ogni ordine ha molti prodotti. Queste relazioni sono definite in modo esplicito e il database le protegge: non puoi creare un ordine per un utente che non esiste. È il default per la maggior parte delle applicazioni business: stabile, prevedibile, facile da interrogare.
NoSQL (MongoDB, Firebase) è più flessibile nella struttura dei dati. Invece di tabelle rigide, salva documenti (simili a file JSON) che possono avere strutture diverse tra loro. Comodo per prototipi veloci, ma può diventare caotico senza disciplina. Non è “più moderno”. È diverso, con trade-off diversi.
Un errore frequente: scegliere NoSQL perché “è più flessibile” senza considerare che quella flessibilità diventa un problema quando devi fare query complesse o garantire la coerenza dei dati.
Come funzionano le API?
Un’API (Application Programming Interface) è un contratto che definisce come due sistemi si parlano. Secondo ProgrammableWeb, nel 2024 esistono oltre 24.000 API pubbliche documentate. Ogni volta che la tua app manda un’email tramite SendGrid o elabora un pagamento con Stripe, sta usando un’API. Il contratto dice: “mandami questi dati in questo formato e io ti restituisco questo risultato”.
Perché ti interessa? Perché quasi ogni funzionalità del tuo prodotto che interagisce con il mondo esterno passa da un’API. Pagamenti, email, SMS, mappe, analytics, autenticazione social. Capire cos’è un’API ti permette di valutare i costi (molte API hanno pricing a consumo) e i rischi (se l’API di un fornitore va giù, la tua funzionalità va giù).
REST e GraphQL sono i due standard principali per costruire API. REST è il più diffuso: ogni risorsa ha un indirizzo (URL) e usi comandi standard per leggerla, crearla, modificarla o cancellarla. GraphQL è più flessibile, ti permette di chiedere esattamente i dati che ti servono. Ma è più complesso da implementare e mantenere.
Webhook: invece di chiedere “ci sono novità?” ogni N secondi, un webhook ti notifica in tempo reale quando succede qualcosa. Stripe ti manda un webhook quando un pagamento va a buon fine. È come la differenza tra controllare la cassetta della posta ogni 5 minuti e avere un campanello che suona quando arriva una lettera. I webhook sono fondamentali per la gestione dei pagamenti, un tema approfondito in quanto costa sviluppare un’app nel 2026.
Cosa significa scalabilità?
Scalabilità non significa “regge 10 milioni di utenti”. Significa che puoi aumentare la capacità del sistema senza riscrivere tutto. Secondo un’analisi di AWS (2024), le startup che investono in architettura scalabile dal primo anno risparmiano in media il 40% sui costi infrastrutturali nei tre anni successivi. Un’app scalabile costa di più ora, ma ha costi prevedibili quando cresce.
Un’app non scalabile costa meno all’inizio. A un certo punto colpisce un muro: per gestire più utenti devi rifare tutto da zero. Hai idea di quante startup si trovano in questa situazione dopo 18 mesi?
In pratica, la scalabilità dipende da come è architettato il backend e il database. Se ogni richiesta utente fa 20 query al database quando ne basterebbero 3, l’app si impalla con poche centinaia di utenti. Se le query sono ottimizzate, lo stesso server regge migliaia di utenti senza problemi.
Latenza è il tempo che passa tra una richiesta e la risposta. Alta latenza = app lenta. Dipende da dove girano i server, da come è strutturato il database, e da quanti dati vengono trasferiti. Per un’app che serve utenti italiani, un server in Europa avrà latenza più bassa di uno negli Stati Uniti. Sembra ovvio, ma molti servizi di hosting mettono i server in Virginia per default.
Cache: invece di ricalcolare lo stesso dato ogni volta, lo salvi temporaneamente. Riduce la latenza e il carico sul database. Esempio pratico: la homepage del tuo prodotto mostra le statistiche aggregate degli ultimi 30 giorni. Senza cache, ogni utente che apre la homepage fa ricalcolare tutto. Con cache, il calcolo avviene una volta e il risultato viene servito a tutti per un periodo definito (5 minuti, un’ora, dipende dal caso).
Le parole che senti spesso
- Deploy: mettere il codice in produzione (renderlo accessibile agli utenti). Ogni modifica al prodotto richiede un deploy. Un processo di deploy ben fatto è automatizzato e richiede pochi minuti. Uno fatto male è manuale, rischioso e può causare disservizi.
- Staging: ambiente di test che replica la produzione prima del deploy. Serve a verificare che le modifiche funzionino in un contesto realistico prima di mostrarle agli utenti. Se il tuo team non ha un ambiente di staging, sta testando direttamente in produzione, il che significa che i tuoi utenti vedono i bug prima del team.
- Bug: errore nel codice che causa comportamento inatteso. I bug sono inevitabili. La differenza è tra un progetto che li trova velocemente (grazie a test e monitoring) e uno che li scopre quando un utente si lamenta.
- Refactoring: riscrivere codice esistente per renderlo più pulito, senza cambiarne il comportamento. Non aggiunge funzionalità, non corregge bug. Migliora la qualità del codice per rendere più facili le modifiche future. Se il tuo sviluppatore ti chiede tempo per fare refactoring, è un buon segno: significa che gli importa della qualità a lungo termine.
- Pull Request (PR): proposta di modifica al codice che viene revisionata prima di essere integrata. Uno sviluppatore scrive il codice, crea una PR, e un altro sviluppatore la controlla prima di approvarla. È un meccanismo di controllo qualità. Se il tuo team non usa le PR, ogni modifica entra nel codice senza che nessuno la verifichi.
- CI/CD: automazione che testa e distribuisce il codice in modo continuo. Ogni volta che uno sviluppatore propone una modifica, il sistema esegue automaticamente i test. Se i test passano, il codice viene distribuito. Se falliscono, la modifica viene bloccata. Riduce gli errori umani e velocizza il ciclo di sviluppo.
Quali metriche devi conoscere?
Le metriche sono il linguaggio con cui misuri la salute del tuo prodotto. Secondo Recurly Research (2024), il churn medio per i SaaS B2B è tra il 3% e il 5% mensile. Se non conosci i tuoi numeri, stai navigando alla cieca. Ecco le metriche fondamentali che ogni founder dovrebbe monitorare.
- Churn rate: la percentuale di utenti che smette di usare il tuo prodotto in un dato periodo. Se hai 100 utenti a gennaio e a febbraio ne restano 90, il tuo churn mensile è del 10%. Un churn alto significa che acquisisci utenti ma non li trattieni. Se il tuo è più alto del 3-5% mensile, hai un problema di retention che va risolto prima di investire in acquisizione.
- Burn rate: quanto denaro spendi al mese. Se hai €100.000 in cassa e il tuo burn rate è €10.000 al mese, hai 10 mesi di pista prima di restare senza soldi. Ogni founder dovrebbe conoscere il proprio burn rate al centesimo.
- Runway: quanti mesi puoi andare avanti con la cassa attuale al burn rate attuale. È il numero che determina l’urgenza di ogni decisione. Con 18 mesi di runway puoi sperimentare. Con 4 mesi devi prendere decisioni drastiche.
- Technical debt (debito tecnico): le scorciatoie prese nel codice per andare più veloci. Non è sempre negativo, a volte è una scelta consapevole per validare un’ipotesi rapidamente. Diventa un problema quando si accumula senza essere gestito. Un prodotto con troppo debito tecnico diventa lentissimo da modificare: ogni nuova feature richiede il doppio del tempo perché devi lavorare attorno ai problemi esistenti.
- Uptime: la percentuale di tempo in cui il tuo servizio è disponibile. Un uptime del 99.9% significa circa 8 ore di disservizio all’anno. Sembra tanto, ma la maggior parte dei provider cloud garantisce questo livello. Se il tuo prodotto gestisce transazioni finanziarie o dati sanitari, potresti aver bisogno del 99.99% (circa 52 minuti di disservizio all’anno), che costa significativamente di più.
- MRR (Monthly Recurring Revenue): il ricavo ricorrente mensile. Se hai 50 utenti che pagano €20 al mese, il tuo MRR è €1.000. È la metrica più importante per un prodotto SaaS perché rappresenta il ricavo prevedibile.
- LTV (Lifetime Value): quanto vale un cliente nel corso della sua intera relazione con il tuo prodotto. Se un cliente resta in media 14 mesi e paga €20 al mese, il suo LTV è €280. Confrontalo con il costo di acquisizione (CAC) per capire se il tuo modello è sostenibile: il LTV dovrebbe essere almeno 3 volte il CAC.
Per capire come usare queste metriche in pratica dopo il lancio, leggi le 5 metriche da tracciare nei primi 90 giorni.
Vuoi fare il prossimo passo? Se questi termini sono ancora nuovi per te, una conversazione chiarisce tutto. Parliamone, 30 minuti, zero impegno.