Comprare invece di costruire: le scelte tecniche che fanno risparmiare mesi a una startup

C'è una domanda che mi sento fare spesso, da founder e da sviluppatori: "Ma voi queste cose le costruite in casa, vero?"

No. O meglio: non tutte. E la parte più importante del mio lavoro come CTO è decidere quali no.

In uno studio come il nostro, dove sviluppiamo più prodotti in parallelo, il tempo di sviluppo è la risorsa più costosa che abbiamo. Ogni settimana passata a riscrivere qualcosa che qualcun altro ha già risolto (e risolto meglio di quanto faremmo noi in un mese) è una settimana tolta all'unica cosa per cui i clienti ci pagano: il valore del prodotto.

Il mito del "fatto in casa"

Nella cultura tecnica resiste un pregiudizio duro a morire: costruire tutto internamente sarebbe sinonimo di serietà, di controllo, di indipendenza. Comprare, invece, suona come una scorciatoia. Quasi un ammettere di non esserne capaci.

La realtà è l'opposto. Un componente non-core costruito in casa non è un asset: è un debito che matura interessi ogni giorno. Aggiornamenti di sicurezza, compatibilità, scalabilità, quegli edge case che scopri solo quando hai utenti veri in produzione (e sempre nel momento peggiore). Un sistema di autenticazione scritto da zero non lo scrivi una volta: lo mantieni per sempre.

La domanda giusta quindi non è "siamo capaci di costruirlo?" (quasi sempre sì), ma "questo componente è il motivo per cui i clienti ci pagano?". Se la risposta è no, il codice migliore è quello che non scriviamo.

E l'AI ha reso tutto più difficile

Fino a un paio d'anni fa questa decisione era relativamente semplice, perché costruire costava tanto ed era evidente a tutti. Oggi no.

Con gli strumenti di AI coding, uno sviluppatore bravo realizza in un pomeriggio quello che prima richiedeva settimane. E allora la tentazione diventa fortissima: perché pagare un canone mensile a Clerk se Claude mi genera un sistema di autenticazione in un'ora? Perché integrare un provider esterno quando "il prototipo funziona già"?

Il problema è che l'AI ha abbattuto il costo di scrivere il codice, non il costo di possederlo. Il prototipo dell'autenticazione fatto in un pomeriggio funziona, certo. Poi arriva il refresh dei token, il rate limiting, la rotazione delle chiavi, l'utente che si registra con Google e poi prova a entrare con email e password, il penetration test che ti chiede come gestisci le sessioni. Tutta roba che un fornitore specializzato ha già passato, e che tu ti sei appena messo in casa.

Paradossalmente, quindi, più l'AI rende facile costruire, più serve disciplina nel decidere cosa non costruire. La barriera tecnica si è abbassata; quella economica (manutenzione, sicurezza, costo-opportunità) è rimasta esattamente dov'era. Solo che adesso è più facile non vederla.

Come decidiamo in Startup Bakery

Il criterio che applichiamo a ogni nuova startup del portfolio si riassume in poche righe.

Si costruisce ciò che differenzia: la logica di business, l'esperienza utente, l'intelligenza specifica del dominio. È lì che nasce il vantaggio competitivo, e non si esternalizza il proprio vantaggio competitivo.

Si compra ciò che è commodity: autenticazione, invio di email, notifiche, integrazioni con provider esterni. Problemi già risolti da aziende che fanno solo quello, con team dedicati e anni di casi limite alle spalle.

E si valuta il costo totale, non il prezzo. Un servizio esterno ha un canone visibile in fattura. Un componente interno ha un costo che non vedi da nessuna parte: le ore di manutenzione e, soprattutto, tutto quello che non stai costruendo nel frattempo.

Sembra banale scritto così. Applicarlo con disciplina non lo è per niente, perché il "dai, lo facciamo noi, ci mettiamo poco" è sempre dietro l'angolo. E "poco" non è mai poco.

Due esempi concreti: autenticazione e notifiche

Prendiamo il caso più classico: l'autenticazione. Login, sessioni, accesso con Google o Microsoft, recupero password, autenticazione a due fattori. È un dominio dove un errore si paga carissimo e dove, francamente, non c'è niente da inventare: piattaforme come Clerk o Auth0 fanno solo questo, da anni, con team di sicurezza dedicati. Costruirsela in casa significa diventare responsabili a vita di uno dei pezzi più attaccati di qualsiasi applicazione. Nei nostri prodotti l'autenticazione non la scriviamo: la integriamo, e in un giorno abbiamo qualcosa che internamente richiederebbe settimane solo per la prima versione (quella ingenua, che poi va rifatta).

Stesso discorso per le notifiche. Sembra il classico componente "facile": mandi un'email, al massimo un messaggio. Poi arrivano i problemi veri: la deliverability, i template multilingua, l'utente che vuole ricevere gli avvisi su un canale e non su un altro, i retry quando un provider è giù. Piattaforme di orchestrazione come Courier hanno già risolto tutto questo. Noi dobbiamo solo decidere cosa dire all'utente e quando, che è l'unica parte in cui il nostro prodotto c'entra qualcosa.

E cosa costruiamo noi, allora? Tutto il resto: la logica di dominio, quella per cui il cliente sceglie il nostro prodotto e non un altro. Il criterio è sempre lo stesso: il talento del team va dove nessun fornitore può arrivare, perché nessun fornitore conosce il problema dei nostri clienti meglio di noi.

Il beneficio che non ti aspetti: la compliance

C'è poi un vantaggio di questo approccio che nei post di tecnologia si vede poco, ma che per chi fa B2B vale oro.

Una delle startup del nostro portfolio accede ai dati email dei propri utenti usando gli scope più sensibili di Gmail. Per farlo, Google richiede la certificazione CASA (Cloud Application Security Assessment): questionari di sicurezza, scansioni dell'applicazione, evidenze documentali. Un processo serio, come è giusto che sia.

Ora, affrontare una certificazione del genere con uno stack interamente fatto in casa significa dimostrare la sicurezza di ogni singolo pezzo: come conservi le credenziali, come gestisci le sessioni, come cifri i dati. Con uno stack di fornitori specializzati, buona parte di quel perimetro è già coperta da aziende che di sicurezza vivono, e che quelle verifiche le hanno superate ai massimi livelli prima di noi.

Risultato: abbiamo ottenuto la CASA in tempi che da soli non sarebbero stati nemmeno pensabili. E senza CASA niente accesso ai dati Gmail; senza dati, niente prodotto. Le scelte di buy vs. build, insomma, non decidono solo quanto vai veloce a sviluppare: decidono quanto vai veloce a poter stare sul mercato.

Quando invece costruire ha senso

Non è un'apologia dell'outsourcing totale, sia chiaro. Costruire resta la scelta giusta quando il componente è il prodotto: esternalizzarlo vorrebbe dire esternalizzare la propria differenziazione. Oppure quando la dipendenza da un fornitore diventa un rischio concreto: costi che crescono più in fretta del fatturato, o una roadmap altrui che vincola la tua. E poi ci sono i volumi: quello che a 100 clienti conviene comprare, a 10.000 può convenire costruirlo. Ma questo è un bel problema da avere, e si affronta quando arriva. Non prima.

Anche le eccezioni, però, confermano il metodo: la decisione va presa ogni volta in modo esplicito, guardando i numeri. Non per inerzia, e nemmeno per orgoglio ingegneristico.

Il codice migliore è quello che non scrivi

In Startup Bakery ogni startup nasce da una ricetta, e in ogni ricetta ci sono ingredienti che prepariamo noi e ingredienti che scegliamo dai migliori fornitori. Nessun pasticcere serio macina la propria farina: la sceglie bene, e mette il talento dove fa la differenza.

Per un CTO vale lo stesso. La maturità tecnica non si misura da quanto codice scrivi. Oggi meno che mai, visto che a scriverlo ci pensa sempre più spesso l'AI. Si misura da quanto valore consegni. E a volte il modo più veloce per consegnarlo è avere il coraggio di non scrivere nemmeno una riga.