Scegliere lo stack tecnologico per il tuo primo SaaS: una guida onesta per fondatori

Chiedi a dieci ingegneri quale stack tecnologico usare per il tuo primo SaaS e otterrai quindici risposte, tre delle quali pronunciate con la certezza di una religione. La maggior parte di queste risposte è giusta, per chi la dà. Nessuna riguarda te, il tuo margine di manovra o i clienti che non hai ancora acquisito. Se sei un fondatore che guarda questa decisione sentendosi leggermente a disagio, ecco ciò che nessuno dice ad alta voce: lo stack conta molto meno di quanto ti hanno fatto credere, e i pochi modi in cui conta non sono quelli di cui si discute online.

Ho aiutato parecchi fondatori alle prime armi a passare da una presentazione a un prodotto per cui persone reali pagano. Quasi nessuno era tecnico. Quasi tutti arrivavano avendo già assorbito una quantità spaventosa di folklore sugli stack: che servivano i microservizi, che un certo framework era "morto", che scegliere male li avrebbe condannati. E quasi ogni volta lo stack si è rivelato una delle decisioni meno determinanti prese in quell'anno. A uccidere i progetti erano l'ambito, la confusione sulle responsabilità e il costruire splendidamente la cosa sbagliata. Mai il framework.

Ecco quindi la guida che do a quei fondatori prima di scrivere una sola riga di codice. Non ti dirà di usare uno stack preciso, perché chiunque lo prometta senza conoscere la tua attività ti sta vendendo qualcosa. Ti darà invece un modo di ragionare, così che qualunque cosa tu scelga, o qualunque cosa proponga il tuo team, tu possa verificarla con buon senso, da adulto, invece di annuire nervosamente.

Perché questa decisione sembra più difficile di quanto sia

La questione dello stack sembra enorme perché è la prima scelta dall'aria irreversibile che fai, ed è avvolta in un linguaggio che non parli. Parole come Postgres, React, Kubernetes, serverless vengono lanciate come se scegliere tra esse fosse come scegliere le fondamenta di un edificio: sbagli e tutto crolla.

Ma il software non è un edificio. Assomiglia molto più a una cucina che puoi rifare mentre continui a cucinare. Le aziende di successo riscrivono di continuo parti del loro stack; la versione di un prodotto che trova i primi cento clienti non è quasi mai quella che ne serve i primi centomila. L'obiettivo del tuo primo stack non è durare per sempre. È permetterti di costruire, cambiare e rilasciare abbastanza in fretta da scoprire se qualcuno lo vuole davvero. È un'asticella del tutto diversa, e molto più bassa, di "perfetto per il prossimo decennio".

Una volta accettato questo, la pressione si dimezza. Non stai più cercando di prevedere il futuro. Stai cercando di fare una scommessa ragionevole e reversibile che ti porti a un prodotto funzionante e a utenti paganti. E le scommesse ragionevoli sono qualcosa che un fondatore non tecnico può assolutamente valutare.

Cosa è davvero uno "stack", in parole semplici

Prima di decidere qualsiasi cosa, conviene demistificare la parola. Uno stack tecnologico non è altro che l'insieme degli strumenti usati per costruire e far funzionare il tuo software. Puoi pensarlo in quattro livelli, e non devi capirne nessuno a fondo: ti basta sapere che esistono.

• Il frontend: ciò che gli utenti vedono e cliccano nel browser o nell'app. È la parte su cui tutti ti giudicano.
• Il backend: la logica e le regole che girano su un server: chi può fare cosa, cosa succede quando lo fa, come si muove il denaro.
• Il database: dove vivono davvero le tue informazioni: utenti, ordini, abbonamenti, tutto ciò che perdere ti devasterebbe.
• L'infrastruttura: i server e i servizi che tengono tutto quanto sopra online, con backup e raggiungibile alle 3 di notte.

Quando qualcuno dice "useremo uno stack JavaScript moderno" o "Rails su Postgres", sta descrivendo scelte su questi quattro livelli. Tutto qui. Ogni SaaS, dal progetto secondario di due persone all'azienda quotata, è una versione di queste quattro cose impilate. Gli altisonanti diagrammi di architettura sono proprio questo, disegnati con più riquadri.

Le cose che contano davvero (e quelle che no)

È qui che gran parte dei consigli sugli stack sbaglia: ottimizza cose che non incidono sui tuoi primi due anni e ignora quelle che lo fanno. Lascia che sia schietto su entrambe le liste.

Ciò che conta davvero

Chi può costruirlo e mantenerlo. Il fattore di gran lunga più importante non è la tecnologia: sono le persone. Lo stack migliore per te è quello in cui il tuo team (o il partner che ingaggi) può davvero lavorare, con scioltezza, oggi. Uno stack "perfetto" che capisce solo un raro specialista è una scelta peggiore di uno noioso che qualsiasi sviluppatore competente può raccogliere. Assunzioni e continuità battono ogni volta l'eleganza teorica.

Quanto in fretta puoi cambiare le cose. All'inizio sbaglierai costantemente sul tuo prodotto. Il vero compito dello stack è rendere economico il cambiare idea. Strumenti maturi, ben documentati e con grandi community ti fanno andare veloce perché le risposte ai tuoi problemi esistono già. Gli strumenti all'avanguardia fanno di te la persona che scopre i bug.

Se puoi assumere per esso. Scegli qualcosa di oscuro e leghi il tuo futuro a chi l'ha costruito. Scegli qualcosa di comune e noioso e potrai sempre trovare il prossimo sviluppatore, la prossima agenzia, la prossima persona che subentra. Noioso è un pregio quando la tua attività ne dipende.

Ciò che conta molto meno di quanto si dica

Le prestazioni pure e la "scala". Non hai un problema di scala. Hai un problema di nessuno-lo-usa-ancora, che è il problema opposto. Architetture progettate per milioni di utenti ti rallenteranno quando ne avrai undici. Le famose aziende che imiti hanno costruito prima la versione semplice e l'hanno ricostruita dopo, finanziate dal successo. Anche tu dovresti.

Quale framework specifico stia "vincendo" quest'anno. I framework salgono e scendono in un ciclo di moda che non ha quasi nulla a che vedere con la loro capacità di costruire bene il tuo SaaS di fatturazione. Una qualsiasi delle opzioni diffuse e largamente usate farà il lavoro. La tendenza è rumore; scegli dal mezzo noioso e popolare e vai avanti.

Perché la tecnologia "noiosa" di solito vince

C'è una saggezza sommessa tra i costruttori esperti che i nuovi arrivati trovano deludente: la tecnologia migliore per una nuova attività è di solito quella noiosa, collaudata, leggermente fuori moda. Non perché gli strumenti nuovi siano cattivi, ma perché ogni scelta che fai spende un budget limitato di novità: il numero di cose sconosciute, non supportate e sorprendenti che il tuo piccolo team può gestire in una volta.

Spendi quel budget su ciò che rende speciale la tua attività: il prodotto vero, l'intuizione che solo tu hai. Non spenderlo su un database di cui nessuno ha sentito parlare solo per sentirti moderno. Uno stack noioso e maturo significa che i problemi sono già stati risolti, la documentazione esiste, assumere è facile e lo strumento non sparirà l'anno prossimo quando il suo unico manutentore perderà interesse. Il noioso ti permette di mettere tutto il tuo entusiasmo dove rende: nel cliente.

È anche qui che l'IA cambia un po' il quadro, e non come suggerisce l'hype. Gli assistenti di codice basati su IA sono nettamente migliori con le tecnologie noiose e popolari, perché sono stati addestrati su un decennio di risposte pubbliche su di esse. Scegli uno stack diffuso e il tuo team (e i tuoi strumenti) ricevono aiuto più rapido gratis. Scegli qualcosa di esotico e sei solo proprio quando puoi permettertelo di meno.

Un metodo decisionale che puoi davvero usare

Basta principi. Ecco un modo concreto per arrivare a una decisione, sia che tu scelga da solo, briefi un freelance o valuti ciò che propone un'agenzia. Niente di tutto questo richiede di scrivere codice: solo di chiedere le cose giuste e soppesare le risposte.

1. 1
   Parti dal team, non dalla tecnologia

   Chiediti: chi costruirà e manterrà tutto questo nei prossimi due anni? Ciò che già padroneggiano bene è la tua opzione predefinita più solida. Cambiare stack per rincorrere una moda batte di rado la scioltezza.
2. 2
   Per impostazione predefinita, il diffuso e collaudato

   Scegli dal mezzo popolare e ben documentato di ogni livello. Se non trovi in fretta tutorial, offerte di lavoro e grandi community per uno strumento, prendilo come un avvertimento, non come un pregio.
3. 3
   Ottimizza per il cambiamento, non per la scala

   Prediligi la scelta che rende modificare il prodotto rapido ed economico. Sbaglierai ripetutamente sul prodotto: il compito dello stack è rendere lo sbagliare sopravvivibile.
4. 4
   Mantieni l'architettura più semplice possibile

   Un database. Un backend. Un frontend. Niente microservizi, niente furbi sistemi distribuiti, finché un problema reale e misurato non ti costringe. La semplicità è l'obiettivo, non il compromesso.
5. 5
   Scrivi perché l'hai scelto

   Un paragrafo: chi lo costruisce, cosa hai scelto e cosa dovrebbe cambiare perché tu lo riconsideri. Questa nota ti risparmia di rimettere in discussione la decisione ogni volta che qualcuno legge un'opinione forte.

Se non segui nient'altro, segui i passi uno e quattro. Costruisci con le persone che hai, sull'architettura più semplice che funziona. Questa combinazione evita in silenzio le due modalità di fallimento che affondano la maggior parte dei primi prodotti SaaS: nessuno in grado di mantenerlo e un sistema troppo complicato per la sua dimensione.

Domande da porre a chi propone uno stack

La maggior parte dei fondatori non sceglie lo stack da sola: uno sviluppatore, un'agenzia o un amico CTO ne propone uno. Non devi verificare tu stesso la tecnologia. Devi porre una manciata di domande e ascoltare come rispondono. Risposte sicure e in linguaggio chiaro sono un buon segno. Il gergo difensivo no.

• "Perché questo e non la noiosa opzione popolare?" — una buona risposta riguarda le tue esigenze specifiche, non ciò che è di moda.
• "Se venissi investito da un autobus, con quanta facilità potrebbe subentrare qualcun altro?" — la risposta rivela quanto la scelta sia rara e rischiosa.
• "Qual è la versione più semplice di questa architettura che funziona ancora?" — osserva se punta alla semplicità o alla complessità.
• "Quanto sarà facile assumere il prossimo sviluppatore per questo?" — competenze comuni significano un mercato sano; competenze esotiche significano dipendenza.
• "Cosa succede quando dovremo cambiare una funzionalità centrale fra tre mesi?" — vuoi sentirti dire che il cambiamento è economico, non temuto.

Trappole comuni che sembrano buone idee

Alcuni schemi ricorrono così spesso che vale la pena nominarli, perché ciascuno sembra responsabile sul momento e ti costa caro dopo.

Costruire per una scala che non hai. La voglia di "farlo per bene" spinge i fondatori a progettare per milioni di utenti prima di averne dieci. Ogni briciolo di quella preveggenza è complessità che paghi ora, in tempo e denaro, per risolvere un problema che potrebbe non arrivare mai. Costruisci per i prossimi cento utenti. Riprogetta quando la crescita lo rende necessario, e che sia un bel problema.

Rincorrere la novità. Un framework scintillante uscito il mese scorso non ha storia, ha documentazione scarna e una community minuscola. Passerai le notti a fare il debug dello strumento invece di costruire il prodotto. Lascia che siano altri i primi adottanti; tu hai un'attività da rilasciare.

Affidare a chi costa meno, su ciò che preferisce. L'offerta più bassa arriva spesso con uno stack oscuro che conosce solo quel team. Il giorno in cui vi separate, il tuo prodotto diventa un'isola che nessun altro può raggiungere. Economico all'inizio, rovinoso dopo. Pretendi tecnologia diffusa e con mercato di assunzione anche quando affidi all'esterno, soprattutto quando affidi all'esterno.

Quando è davvero ora di rivedere lo stack

Niente di tutto questo significa "non cambiare mai". Significa cambiare per ragioni reali, misurate, non immaginate. Saprai che è davvero ora di far evolvere lo stack quando compaiono segnali concreti, non quando un articolo di blog ti mette in ansia.

Nota lo schema: le ragioni vere riguardano un dolore misurato nella tua attività reale. Quelle false riguardano moda, confronto e irrequietezza. Quando compare un segnale vero, cambi un pezzo per volta, non l'intero stack in una riscrittura eroica che blocca tutto per sei mesi. Evoluzione, non rivoluzione.

Domande frequenti