Costruire tutto in casa non è autonomia. È una lista di prodotti che dovrai manutenere per anni. Si sviluppa il vantaggio. Si compra il resto.
Si sviluppa ciò che rende il prodotto diverso. Si compra ciò che è commodity: autenticazione, pagamenti, CMS, invio email, a meno che quello non sia il prodotto. Build or buy non è una questione di orgoglio tecnico. È una questione di cosa si è disposti a manutenere per anni, e di quanto costa uscirne il giorno in cui la scelta si rivela sbagliata.
In breve: il criterio è il vantaggio competitivo, non "sappiamo scriverlo". Ciò che i clienti pagano, si può costruire. Ciò che ogni sito deve comunque avere, si compra, si integra, si governa. Il costo vero sta nel ciclo di vita e nel lock-in, non nella prima fattura. Senza un piano di uscita, si è scelto un fornitore, non una piattaforma.
Cosa trovi in questo articolo
Il criterio: differenziatore contro commodity
La domanda utile non è "quanto siamo bravi". È: se questa funzione fosse identica a quella del concorrente, il cliente se ne accorgerebbe? Se no, è commodity. L'autenticazione, il checkout PCI, l'editor dei contenuti, la coda delle email transazionali: il cliente non compra "il nostro login". Compra ciò che succede dopo. Costruire il dopo. Comprare il login.
Il criterio è vecchio quanto l'ingegneria del software, e resta scomodo perché costruire è visibile e soddisfa il team. Comprare sembra una rinuncia. In realtà è una scelta di capacità: ogni pezzo costruito in casa diventa un prodotto interno, con bug, patch, on-call, documentazione. Il team che lo ha scritto dovrà viverci. Lo stack si sceglie sugli stessi vincoli: chi lo opera tra tre anni, non chi si entusiasma questa settimana.
OWASP, nella Authentication Cheat Sheet, è esplicita sul non inventarsi schemi di autenticazione. Sui pagamenti, PCI DSS chiede controlli che un sito vetrina non deve replicare in proprio: si usa un PSP, non si diventa una banca. Sono due esempi dello stesso principio. Il rischio regolamentare e il rischio crittografico non sono un "nice to have" da riscrivere nel backlog.
Cosa si compra, e perché
Si compra quando esiste un mercato maturo, un contratto, un'export dei dati, un ritmo di patch che non si è disposti a replicare. CMS, identità, pagamenti, search, CDN, email: per la maggior parte dei siti sono infrastruttura di prodotto, non il prodotto.
Un CMS è il caso più frequente. Scriverne uno "perché così è nostro" produce, in pochi anni, un editor, un media manager, un sistema di permessi, un ciclo di patch, un problema di accessibilità. Tutto questo è il mestiere di una piattaforma, non il mestiere del sito del cliente. Scegliere un CMS, open source, SaaS o una piattaforma gestita come la piattaforma KeideaCMS, è comprare quel mestiere. Il confronto tra i tre modelli (chi patcha, chi possiede i dati, come si esce) sta in CMS proprietario, open source o SaaS. Qui basta il criterio: se il contenuto è il canale e non il motore, non si scrive il motore.
Comprare non significa "non toccare". Significa integrare, configurare, rifiutare le estensioni inutili, tenere un piano di uscita. Il fornitore ha una roadmap che non è la vostra. Va bene, finché quella roadmap non è il differenziatore. Se lo diventa, si è comprato nel posto sbagliato.
Cosa si costruisce, e con chi
Si costruisce il pezzo che, se identico al concorrente, farebbe perdere il cliente. Un configuratore, un flusso di prenotazione, una logica di prezzo, un'integrazione con il gestionale che è il vero processo. Lì il codice è il prodotto. Lì ha senso un team, interno o con i servizi di sviluppo web di Keidea, che scriva, testi, rilasci, resti owner. Non per "avere il sito fatto su misura" in astratto. Per possedere il vantaggio.
Costruire ha un costo che non sta nella prima consegna. Sta nelle versioni successive, nei buchi di sicurezza, nel debito. La guida sul debito tecnico misura proprio questo: cycle time, difetti, stime. Ogni funzione costruita in casa entra in quei tre conti. Se il team non ha capacità di operarla, si è comprato un problema con la forma di un repository.
Una regola pratica: se non si è disposti a tenere on-call su quel pezzo, non si dovrebbe scriverlo. Il vendor commodity ha già quell'on-call, inclusa nel prezzo. Il codice interno ce l'ha solo se lo si finanzia.
Switching cost: il prezzo che non sta nel preventivo
Entrare è un'integrazione. Uscire è una migrazione. I dati in un formato proprietario, gli URL, gli shortcode, i webhook, la formazione della redazione, i contratti laterali (DNS, pagamenti, identità): tutto questo è switching cost. Non ha un prezzo di listino. Si scopre quando il vendor alza il canone, chiude il piano, cambia le API, oppure quando il differenziatore è cresciuto e la piattaforma lo frena.
Si riduce in tre mosse, tutte in ingresso, non in uscita. Uno: i contenuti in un formato esportabile (HTML, Markdown, un dump, non solo "l'export del vendor"). Due: identità e pagamenti dietro un contratto proprio, non incollati al CMS. Tre: il differenziatore nel codice che si possiede, con test, non in uno script nel pannello del fornitore. Se queste tre mancano, si è scelto un lock-in. Può essere un lock-in accettabile. Deve essere dichiarato.
Il lock-in non è un insulto. È un termine di scambio. Un SaaS che spedisce in una settimana e tiene le patch può valere dieci anni di canone. Un CMS da cui non si esce, con i contenuti prigionieri, vale meno di quanto sembrava il giorno del go-live.
Ha senso quando. Non serve quando
Ha senso comprare autenticazione, pagamenti, CMS, email, search, osservabilità di base, tutto ciò che ha standard, vendor multipli e un costo di errore alto. Ha senso anche comprare un pezzo che si saprebbe scrivere, se scriverlo mangerebbe il tempo del differenziatore.
Ha senso costruire il flusso per cui il cliente paga, le integrazioni col processo reale, ciò che il mercato non vende senza piegarlo fino a romperlo. Ha senso quando c'è un owner e un ritmo di rilascio. Non quando "in casa qualcuno programma".
Non serve costruire un CMS per un sito editoriale. Non serve comprare una suite "enterprise" per un vantaggio che sta in cinquecento righe di codice. Non serve una decisione unica per tutto lo stack: si decide pezzo per pezzo, e si rivede quando il prodotto cambia.
Errori da evitare
Costruire per orgoglio. "Lo sappiamo fare" non è un criterio. "Lo dobbiamo operare per cinque anni" lo è.
Comprare il differenziatore. Si finisce a chiedere al vendor la roadmap del proprio mestiere. Non arriverà, o arriverà anche ai concorrenti.
Ignorare l'uscita. Un'integrazione senza export è un matrimonio. Si celebra in un pomeriggio. Si scioglie in un trimestre.
Sommare plugin fino a simulare un prodotto. Si è comprato rumore, non una piattaforma. Il totale dei canoni non è un'architettura.
Stimare solo la prima fattura. Build e buy si confrontano sul ciclo di vita. La prima fattura mente sempre, in entrambe le direzioni.
In sintesi
Build or buy si decide sul vantaggio, non sul curriculum del team. Si compra il commodity, si costruisce il differenziatore, si paga l'on-call di ciò che si è scritto, si tiene un'uscita per ciò che si è comprato. Il resto è rumore: suite, orgoglio, "su misura" senza owner. Pezzo per pezzo, con un piano di vita e un piano di fuga. Poi si misura se il prodotto esce più in fretta. Quello è il verdetto. Non il repository.
Fonti
OWASP, Authentication Cheat Sheet (non inventare schemi di autenticazione).
PCI Security Standards Council, PCI DSS (pagamenti: controlli a carico di chi processa, non del sito vetrina).
Martin Fowler, Technical Debt (ciclo di vita di ciò che si costruisce in casa).
Questo contenuto è stato realizzato con il supporto di sistemi di intelligenza artificiale e successivamente verificato secondo le linee editoriali della redazione.
