Rimanere al passo con il mercato che evolve non è facile, le aziende per rimanere competitive hanno bisogno di innovazione e talvolta di coprire mercati adiacenti a quelli del core business.
In questo contesto c’è una domanda che ogni CEO di un’azienda tech si pone: costruire un nuovo prodotto o comprarlo?
Sviluppare internamente o acquistare una soluzione già pronta? Sembra una decisione puramente tecnica, ma in realtà questa scelta è lo specchio dell’anima della tua azienda.
Nella nostra visione imprenditoriale abbiamo sempre preferito costruire.
Anche quando sulla carta poteva sembrare sensato comprare qualcosa di già fatto. Ad esempio Taste, il nostro software per ristorante dell’hotel, ma anche Peak, la soluzione di revenue management, sono nati così.
Non perché non esistessero alternative sul mercato, ma perché volevamo il controllo totale della tecnologia.
Infatti quando si prende la decisione di comprare una soluzione software già presente sul mercato, stai facendo molto più che acquistare delle funzionalità di un software. Stai comprando le decisioni architetturali di qualcun altro, i loro compromessi tecnici, la loro visione del problema.
È come comprare un vestito, puoi sceglierne uno di seconda mano, se si è fortunati può anche andare benino, ma non sarà mai preciso come un abito cucito su misura.
Ah però il fascino del buy è innegabile, lo capisco.
Il mercato pressa e ti rendi conto che il tuo prodotto avrebbe bisogno proprio di quella funzionalità. Eccola, pronta da integrare. Niente mesi di sviluppo, niente stime che inevitabilmente sballano, niente incertezza.
I CFO adorano questo approccio perché è economicamente prevedibile e di conseguenza anche il consiglio di amministrazione generalmente non disdegna la cosa.
Ma poi arriva il momento della messa online e della successiva integrazione con i tuoi software esistenti, a questo punto ti accorgi che quella soluzione “esterna” deve parlare con il tuo sistema.
Deve condividere, autenticazione, pattern di UI, logiche di business, scambiare dati e sembrare anche esteticamente ben amalgamata con il tuo prodotto software. A questo punto, il team di ingegneria deve analizzare a fondo i pattern di sviluppo seguiti, oltre a framework e linguaggi di programmazione utilizzati.
Inoltre per complicare le cose spesso accade che, dopo l’acquisizione, molti membri chiave del team tecnico del software acquisito abbandonino rapidamente l’azienda, lasciando nelle mani dell’ingegneria un codice nuovo, scarsamente documentato e con tutte le complessità di manutenzione del caso.
Ed eccoci qua, quel tempo che pensavi di aver risparmiato si finisce per ripagarlo con gli interessi. E non è solo questione di ore di sviluppo, è questione di onboarding di debito tecnico e di appesantimento del tuo team.
La differenza tra aziende build e aziende buy non è solo tecnica, è filosofica.
Le prime sono guidate dal prodotto, le seconde dal budget. Le prime pensano in anni, le seconde in trimestri. Precisiamo che essere “tech” non significa assolutamente trascurare la dimensione finanziaria.
Al contrario, vuol dire saper sfruttare la tecnologia per far crescere il valore finanziario dell’azienda. Chi sceglie un approccio che chiamo “tech first” ha, sul lungo termine, molte più possibilità di ottenere multipli di valore più elevati.
Non sostengo che ci sia un’unica strada giusta, perché ogni business segue le proprie dinamiche, visioni e strategie.
Va detto però che l’approccio buy sembra essere preferito da aziende con una cultura maggiormente finanziaria rispetto a quella tecnologica.
Le aziende che invece hanno un’anima tech (non chiamiamola nerd mi raccomando) lo dimostrano sul campo avendo risorse per creare i propri strumenti e sviluppano soluzioni su misura alle necessità del mercato. Ma il problema di fondo è un aspetto tanto banale quanto sottovalutato: per poter costruire, devi avere spazio mentale e operativo.
Il vero problema di molte aziende è vivere in uno stato di urgenza permanente.
Si passa da un’emergenza all’altra: bug critici da risolvere, nuove feature richieste dai clienti, promesse fatte a prospect e clienti da mantenere. In mezzo a questo caos, non resta alternativa: bisogna restare concentrati sulle esigenze quotidiane senza mai alzare lo sguardo, rinunciando a dedicare risorse alla visione di lungo termine.
In questi contesti, le scorciatoie sembrano inevitabili, ma spesso finiscono per alimentare ulteriormente il problema, aggiungendo benzina sul fuoco e complicando ancora di più il futuro dell’azienda.
Noi abbiamo la fortuna di operare diversamente. Il nostro team può permettersi di lavorare su progetti nuovi senza trascurare l’esistente. Ma questa non è fortuna, è il risultato di scelte fatte negli anni. Abbiamo investito nella stabilità del sistema, nella qualità del codice, nei processi che riducono l’emergenza quotidiana.
È un circolo virtuoso: costruisci bene dall’inizio, hai meno problemi, hai più tempo per costruire altro.
Questo ti evita di rimanere imprigionato nel ciclo infinito della manutenzione d’emergenza, perdendo la possibilità di avere il lusso di innovare. E poi c’è il fattore umano.
Nessun software engineer ha piacere di passare le giornate a far comunicare sistemi incompatibili.
Vuole costruire, non patchare. Vuole risolvere problemi, non aggirare limiti imposti da altri. Un team che può creare è un team motivato, che si diverte e che crea valore.
Certo, se mettiamo da parte per un attimo i costi di acquisto del prodotto/azienda (l’aspetto prettamente finanziario), possiamo affermare che costruire una soluzione internamente comporta sicuramente un investimento iniziale maggiore.
Le stime temporali sui tempi di sviluppo sono sempre ottimistiche, le settimane di consegna slittano e i costi inevitabilmente lievitano. Ma comprare costa decisamente di più nel lungo termine. Ogni licenza è un costo ricorrente, ogni integrazione è un punto di rottura potenziale, ogni dipendenza esterna è un compromesso sulla tua visione.
Ovviamente non tutto va costruito internamente. Usare una libreria per gestire i PDF o integrare un payment processor ha senso. Ma quando si tratta del core business, della differenziazione competitiva, quelli li devi costruire tu.
La scelta build vs buy non è solo una decisione tecnica.
È una dichiarazione di intenti. Stai dicendo al mercato, al tuo team, a te stesso: “Noi non assembliamo, noi creiamo.”
È una posizione che richiede coraggio e lungimiranza. Ma soprattutto richiede organizzazione. Devi aver costruito un sistema che ti permette di avere tempo e risorse per innovare. Non tutte le aziende ci riescono, non tutte hanno questa disciplina.
E alla fine, quando vedi il tuo team lavorare su codice che conosce perfettamente, quando puoi implementare una feature richiesta dai clienti in una manciata di giorni invece che in mesi, quando non devi dipendere da fornitori esterni per la tua strategia di prodotto, capisci che quella scelta apparentemente più difficile era in realtà l’unica sensata.
