Costruire o comprare: lo schema decisionale

Costruire o comprare non è una decisione tecnica. È strategica. E la maggior parte dei PM la sbaglia per abitudine — chi ama costruire vuole costruire tutto, chi teme il rischio vuole comprare tutto.

Ho visto entrambi gli errori. La decisione dipende da quattro domande, in quest'ordine. Sbagliare la sequenza significa ottimizzare la cosa sbagliata.

Domanda 1: Qual è il vincolo reale?

Di solito non se l'aspetta nessuno, perché la risposta è quasi sempre "tempo", non "non sappiamo come costruirlo".

Quando stavo costruendo CasaHunter, potevo fare tutto da solo: lo scraper, la deduplica, la classifica. Avevo sere e weekend. Nessun vincolo di tempo. Quindi ho costruito.

Nel Payments Rescue a QubicaAMF, il sistema era in crisi. 44 problemi aperti, clienti scontenti, il team in difficoltà. Il tempo era il vincolo dominante. Non avevamo sei mesi per valutare fornitori. Dovevamo stabilizzare, altrimenti il prodotto non sarebbe sopravvissuto al trimestre successivo.

Il caso opposto: quando abbiamo valutato i fornitori cashless, il tempo non era il vincolo. Lo erano i soldi. Confrontare tre fornitori in profondità, verificare le integrazioni, fare dei pilota. Questo richiede mesi. Il nostro vincolo era decidere entro il Q3 e lanciare entro il Q4. Avevamo un budget per accelerare con pilota e risorse dedicate alla partnership. Comprare dal partner giusto aveva senso.

Non perché non fossimo capaci di costruire. Perché non avevamo tempo, e il tempo era la risorsa più costosa.

Domanda 2: È un punto di forza o qualcosa che fanno tutti?

Nel Payments Rescue, la riconciliazione contabile era un punto di forza. I clienti si lamentavano di continuo. Era il motivo per cui alcuni centri stavano per cancellare. Quindi l'abbiamo costruita internamente. Abbiamo tenuto il controllo dell'intero flusso.

Ma l'elaborazione dei pagamenti in sé? Quella l'abbiamo comprata. L'elaborazione pagamenti di Square è un servizio standard. Migliaia di aziende la usano. Non saremmo stati più bravi di Square a elaborare pagamenti. Abbiamo comprato il servizio e ci siamo differenziati sopra.

CasaHunter: l'algoritmo di valutazione è il vero punto di forza. Quello l'ho costruito. L'infrastruttura di scraping? Sta diventando sempre più un servizio standard man mano che emergono nuovi fornitori. Ma la valutazione — è lì che conta il giudizio. Quella la tengo.

Questa domanda ti salva dal costruire cose costose e complesse solo perché "sembra un successo", anche quando non vale la pena differenziarsi su quel fronte.

Domanda 3: Quanto costa davvero mantenerlo?

Qui la maggior parte dei PM perde la visione d'insieme.

"Costruire ci costa un ingegnere per 3 mesi. Comprare costa 50K euro." Sembra un calcolo facile. Finché non consideri che:

• Quell'ingegnere diventa l'unico che capisce il sistema. Lo possiede per sempre.
• Quando si rompe (e si romperà), molla tutto per ripararlo.
• Quando il business chiede una modifica, solo lui può farla.
• Quando se ne va, le competenze escono dalla porta con lui.

A QubicaAMF abbiamo abbandonato OneCashless — un prodotto interno su cui avevamo investito parecchio — e siamo passati ad Amusement Connect (un partner). Il confronto dei costi era questo:

OneCashless (il nostro prodotto):

• Sviluppo: 150K euro già spesi, irrecuperabili.
• Costi ricorrenti: un ingegnere al 30% del suo tempo, circa 50K euro l'anno.
• Manutenzione, assistenza clienti, richieste di modifica: circa 100K euro l'anno.
• Rischio: se quell'ingegnere se ne va, sei mesi per sostituirlo più la perdita di conoscenza.

Amusement Connect (partner):

• Configurazione e integrazione: 40K euro, una tantum.
• Licenza annuale: 60K euro.
• Assistenza 24/7 inclusa.
• Le nuove funzionalità sono un problema di qualcun altro.

In tre anni, costruire ci è costato 300K+ euro di lavoro (senza contare gli investimenti iniziali) più il rischio di perdere le competenze. Comprare ci è costato 220K euro con meno rischi. Abbiamo comprato.

Domanda 4: Puoi tornare indietro entro 6 mesi?

Questa domanda cambia tutto.

Se compri uno strumento e ti accorgi che è sbagliato, quanto è difficile cambiare? Con Amusement Connect, l'integrazione era progettata per essere reversibile. Potevamo passare a un altro fornitore in tre mesi. Costo di transizione moderato, rischio gestibile.

Se costruisci qualcosa e poi devi sostituirlo con un prodotto esterno, qual è il costo? Hai già costruito secondo le tue specifiche. Dovresti ricostruire secondo quelle del fornitore. L'investimento fatto è reale.

L'algoritmo di valutazione di CasaHunter: è mio. Se smette di funzionare, lo sistemo io. Passare a un servizio esterno mi costerebbe tre settimane di lavoro. La decisione è reversibile.

Payments Rescue: dovevamo stabilizzare in fretta. Non potevamo dire "compriamo da un fornitore e vediamo se funziona" perché non potevamo permetterci di aspettare tre mesi per scoprire che non funzionava. Eravamo in una situazione dove la reversibilità era un lusso. Abbiamo costruito.

La domanda sulla reversibilità non è "potremmo farlo in teoria?" È "potremmo farlo con i vincoli e le risorse che abbiamo adesso?"

Lo schema in ordine

1. Qual è il vincolo? (Tempo, soldi, capacità)
2. È un punto di forza? (Sì = costruisci. No = considera di comprare)
3. Quanto costa mantenerlo su 3-5 anni? (Incluso lavoro, rischio, costo di non fare altro)
4. La decisione è reversibile? (No = alza la soglia per decidere. Sì = abbassala.)

Sbagliare la sequenza e ottimizzi la cosa sbagliata. Saltare il vincolo e risolvi un problema che non hai.

CasaHunter: avevo tempo, la valutazione è il punto di forza, costruire è l'unico modo di possederla, e posso tornare indietro se serve. Costruisci.

OneCashless → Amusement Connect: non avevamo tempo per una valutazione approfondita dei fornitori, il cashless non è il nostro punto di forza, il costo di mantenerlo internamente era insostenibile, e abbiamo progettato il passaggio perché fosse possibile in tre mesi. Compra.

Le decisioni migliori non nascono dalla convinzione. Nascono dal vincolo.

---

Vedi in pratica: Il framework build-vs-buy si è concretizzato in modo diverso su tre progetti: Cashless System (compra), Payments Rescue (costruisci), e CasaHunter (costruisci). Ogni decisione è dipesa da un vincolo diverso.