Noioso e diffuso batte figo e di nicchia

Come scelgo lo stack tecnologico

Qualche settimana fa mi ha scritto una startup (lo so che sei curioso/a, ma si dice il peccato, non il peccatore). Il co-founder tecnico aveva costruito e validato tutto, i primi clienti paganti c’erano già. Poi, a un certo punto, il founder se n’è andato.

Quello che ha lasciato era un software che funzionava: gli utenti lo usavano e il business girava. Sotto il cofano, però, c’era un problema grosso. Il software non poteva evolvere. E non per colpa della tecnologia in sé, ma per come era stata scelta.

Mi sono ritrovato a pensare a quante volte mi capita di entrare in progetti dove il problema non è il codice, il team o altro, ma la scelta tecnologica fatta all’inizio senza farsi le domande giuste. Purtroppo è una roba che vedo in continuazione.

Quando lo stack diventa un muro

La prima cosa che faccio quando entro in un progetto è guardare sotto il cofano. E quello che ho trovato qui mi ha dato subito il quadro della situazione.

Utenti, transazioni, relazioni tra persone, dati che si collegano tra loro in continuazione. Il tipo di prodotto dove tutto dipende da tutto.

Il database che avevano sotto? MongoDB. Che è un ottimo strumento, ma per un tipo di lavoro diverso. Qui serviva qualcosa che gestisse le relazioni tra i dati in modo naturale e MongoDB non è pensato per quello.

Non voglio aprire il dibattito su MongoDB ovviamente, ma quando me ne sono accorto ho capito perché il team voleva cambiarlo. Ogni volta che dovevano costruire qualcosa che toccava le connessioni tra utenti, era una lotta. Workaround su workaround, soluzioni fragili, tempi di sviluppo che esplodevano. Il team non era scarso, però lo strumento che avevano sotto gli remava contro.

E qui il punto è che il costo di una scelta così non lo vedi subito. Lo vedi dopo mesi, quando ti accorgi che una feature che avrebbe dovuto prendere due settimane ne prende sei. Quando il team è frustrato e non capisce perché tutto è così faticoso. Quando un competitor che è partito dopo di te ti supera perché riesce a iterare più veloce. Il costo non è solo tecnico: sono mesi persi, opportunità che sfumano, e soldi bruciati in sviluppo che non doveva essere così complicato.

Mi è successo anche a me, anni fa, di trovarmi in una situazione simile su un progetto mio. Avevo scelto una tecnologia perché mi piaceva, perché volevo impararla, e dopo qualche mese mi sono ritrovato a combattere contro lo strumento invece che a costruire il prodotto. È una sensazione che riconosco al volo quando la vedo in altri.

La prima cosa che stiamo facendo insieme è costruire una strategia di migrazione verso PostgreSQL. Non perché sia “migliore” in assoluto, ma perché per quello che il loro prodotto deve fare è lo strumento giusto.

La trappola del “migliore”

Quando un founder deve scegliere la tecnologia per il suo prodotto, la domanda che si fa quasi sempre è: “Qual è la tecnologia migliore?”

Sembra ragionevole, eppure è la domanda sbagliata.

Non esiste la tecnologia migliore in assoluto, esiste quella più adatta al contesto in cui ti trovi. Sembrerà una differenza sottile, ma ti assicuro che non lo è. Questo cambia completamente il modo in cui affronti la scelta finale.

Quando cerchi “la migliore”, finisci per scegliere in base alla moda del momento, al post che hai letto su X, al consiglio dell’amico developer, o alla tecnologia che “tutti stanno usando”. Nessuna di queste è una buona ragione per prendere una decisione che condizionerà il tuo prodotto per anni.

Quando invece parti dal contesto, ti fermi a capire cosa ti serve davvero. Che tipo di prodotto stai costruendo? Come si comportano i tuoi dati? Come crescerà il prodotto nei prossimi dodici mesi? Quante persone ci lavoreranno sopra?

È come un artigiano che sceglie l’attrezzo in base a quello che deve costruire. Non prende il martello più costoso perché è il “migliore”: prende quello che gli serve per il lavoro che ha davanti.

Anche io all’inizio della carriera ho fatto questo errore (ma tipo 100 volte almeno). Sceglievo le tecnologie che mi piacevano, quelle che volevo imparare, quelle che erano “cool” in quel momento. Poi ti ritrovi con un progetto costruito su uno stack che conosci solo tu e che il prossimo developer dovrà smontare per capirci qualcosa. E lì capisci che la scelta non è mai solo tua: è una scelta che condiziona tutti quelli che verranno dopo.

Nel caso della startup che ti ho raccontato il founder aveva fatto una scelta senza chiedersi dove il prodotto sarebbe dovuto andare. E quindi, quando il prodotto è cresciuto nella direzione naturale, lo stack non ha retto.

Cosa guardo davvero quando devo scegliere

Quando entro in un progetto e devo valutare o scegliere uno stack, seguo una logica che nel tempo si è consolidata. Non è una formula magica e si adatta caso per caso, ma ci sono delle variabili che peso sempre.

Il contesto di prodotto e di business

Questa è sempre la prima cosa. Che tipo di prodotto stai costruendo? Per chi? Come interagiscono i dati al suo interno?

Se stai costruendo un marketplace dove gli utenti hanno relazioni tra loro, hai bisogno di una tecnologia che gestisca quelle relazioni in modo naturale. Se stai costruendo un sistema che riceve milioni di eventi al secondo e deve solo registrarli, le tue esigenze sono completamente diverse.

La tecnologia segue il problema. Mai il contrario.

Sembra ovvio, eppure lo vedo succedere in continuazione: startup che scelgono il database perché “è quello che va adesso” senza mai chiedersi se è quello giusto per i dati che devono gestire. È come comprare un furgone quando ti serviva una bicicletta. O viceversa.

Chi trovi sul mercato

Questo è un fattore che un botto di persone sottovalutano. Puoi scegliere la tecnologia più elegante del mondo, ma se poi non riesci a trovare persone che la conoscono, hai un problema serio.

Non mi sto riferendo solo alle assunzioni a tempo pieno. Parlo anche di freelancer, consulenti, community online dove chiedere aiuto quando sei bloccato alle tre di notte, magari prima di un lancio. Parlo di documentazione fatta bene, di tutorial aggiornati, di risorse per formare il team quando arriva qualcuno nuovo.

Scegliere una tecnologia di nicchia quando sei una startup con budget limitato e devi muoverti veloce è un rischio che nella maggior parte dei casi non vale la pena correre. Lo so, fa meno figo dire “usiamo Go con questo framework che conoscono in dodici nel mondo”. Ma quando il tuo unico developer se ne va e devi trovare qualcuno che ci metta le mani, capisci perché “noioso e diffuso” batte “figo e di nicchia” nove volte su dieci.

La longevità

Questa tecnologia sarà ancora supportata tra tre anni? Chi c’è dietro? È un progetto open source con una community attiva e un’azienda che lo sostiene, o è il side project di qualcuno che potrebbe abbandonarlo da un giorno all’altro?

Non devi per forza scegliere qualcosa che durerà vent’anni. Ma devi almeno evitare di ritrovarti tra due anni con uno stack che nessuno mantiene più e una migrazione forzata nel momento peggiore. Tipo quando stai per chiudere un round. O quando hai appena assunto tre persone. O quando il cliente più grande ti chiede una feature urgente.

La migrazione forzata è una delle robe più dolorose che esistano nel mondo tech. Se puoi evitarla con una scelta più ragionata all’inizio, fallo.

Il fattore economico e il tempo

Quanto budget hai realmente? Quanto tempo ti separa dal prossimo round, dal prossimo lancio, dal prossimo obiettivo di business?

Ti faccio un esempio concreto: se devi mettere in piedi l’infrastruttura del tuo prodotto e non hai né il budget né il tempo per trovare un DevOps che ti gestisca tutto su AWS, andare su una Platform as a Service come Railway o Render non è una scelta pigra. È una scelta intelligente.

Stai delegando una complessità che in questo momento non puoi permetterti di gestire internamente, e questo ti libera tempo e risorse per concentrarti su quello che conta davvero: il prodotto. Quando crescerai e avrai le risorse per farlo, potrai sempre valutare se portare l’infrastruttura in-house.

Il fattore che nessuno sta considerando

C’è una variabile relativamente nuova che secondo me pochissime persone stanno mettendo sul piatto. Ed è una di quelle che nei prossimi anni farà sempre più differenza.

Quanto materiale ha l’AI su quella tecnologia?

L’AI ormai è diventata un collaboratore reale nello sviluppo di un software; non si tratta più di un giocattolo, ma di uno strumento che uso ogni giorno. Bisogna ricordarsi, però, che l’AI funziona bene su tecnologie sulle quali è stata allenata con tanto materiale: documentazione, codice open source, tutorial, discussioni su StackOverflow ed esempi reali di implementazione.

Se scegli una tecnologia di nicchia, con poca documentazione e poca community, l’AI avrà poco materiale su cui basarsi per aiutarti. E questo si traduce in qualcosa di molto concreto: il tuo team sarà più lento nel risolvere problemi, farà più errori che avrebbe potuto evitare, e dovrà investire più tempo su cose che con una tecnologia più diffusa l’AI avrebbe gestito in pochi secondi.

Ci penso spesso, perché è un circolo che si autoalimenta. Più una tecnologia è diffusa, più materiale c’è, più l’AI è brava ad aiutarti, più il tuo team è produttivo, più la tecnologia diventa attraente. E viceversa: meno una tecnologia è diffusa, meno l’AI ti aiuta, più sei lento, meno conviene sceglierla.

Attenzione, non ti dico che non devi scegliere una tecnologia solo perché l’AI la conosce bene, il punto è che oggi ha senso mettere questo fattore nella valutazione finale. È uno di quei ragionamenti che tra qualche anno ti sembreranno anche ovvi, ma che adesso pochi stanno facendo.

La scelta sbagliata non è la fine del mondo

Questa è la parte che volevo aggiungere, perché rischia di passare il messaggio sbagliato.

Non tutte le scelte tecnologiche sbagliate sono fatali. Ho visto startup sopravvivere e crescere con stack discutibili. Ho visto prodotti di successo costruiti su fondamenta traballanti che sono state sistemate nel tempo, pezzo dopo pezzo, senza mai fermare il business.

La startup di cui ti ho parlato all’inizio ne è la dimostrazione: hanno validato il prodotto, hanno trovato clienti paganti, il business funziona. Lo stack non era quello giusto, ma non li ha uccisi. Li ha rallentati.

Quando arrivo in un progetto dove le scelte sono già state fatte, il mio lavoro non è giudicare chi le ha fatte. Sarebbe inutile e pure un po’ da stronzi. Il mio lavoro è capire se quelle scelte reggono per dove il business vuole andare. Se reggono le rafforzo e se non reggono costruisco una strategia per migrare senza fermare tutto.

E questa è la parte che mi piace di più del mio lavoro, tra l’altro. Non è scegliere la tecnologia perfetta il primo giorno. È navigare la complessità di scelte già fatte, vincoli reali, budget limitati e obiettivi ambiziosi. È trovare il percorso migliore con le carte che hai in mano.

Perché alla fine la tecnologia è uno strumento. E come ogni strumento, il suo valore non dipende da quanto è sofisticato o alla moda. Dipende da quanto ti permette di fare quello che devi fare, con le risorse che hai, nel tempo che hai.

Il tuo stack tecnologico è stato scelto partendo dal business o da una preferenza tecnica?

Rispondi a questa mail, sono curioso di sapere com’è andata nel tuo caso.

Ci vediamo alla prossima newsletter.

Senza filtri,
Chri