La scorsa settimana ho visto uno sviluppatore junior del nostro team creare un'applicazione CRUD funzionante, con autenticazione, migrazioni di database e un'interfaccia utente quasi decente, in circa 90 minuti. Con Copilot. Da zero.
Cinque anni fa, lo stesso compito avrebbe richiesto una settimana. Forse due, se si contano le operazioni di razionalizzazione delle configurazioni di distribuzione e dei flussi OAuth. E questo cambiamento, questa compressione del tempo di costruzione da giorni a ore, sta silenziosamente smantellando una delle domande più antiche del software: meglio costruire o comprare?
Il vecchio schema è morto
Per decenni, la questione "costruire o comprare" è stata un calcolo dei costi. Si stimava il numero di mesi-sviluppatore necessari per costruire una cosa, si moltiplicava per il salario caricato, si aggiungeva un po' di buffer per la manutenzione e si confrontava con il costo della licenza annuale di qualsiasi prodotto SaaS che facesse più o meno la stessa cosa. Se il SaaS era più economico, si comprava. Se i suoi requisiti erano abbastanza strani, ha costruito.
Questa strutturazione presupponeva che la costruzione fosse costosa. E lo era. Ma secondo i dati Octoverse 2025 di GitHub, lo sviluppo assistito dall'AI produce oggi un aumento del 20-30% del rendimento. L'80% dei nuovi sviluppatori su GitHub utilizza Copilot entro la prima settimana. Oltre 1,1 milioni di repository pubblici integrano già gli SDK di LLM. La costruzione è diventata drammaticamente più economica, quasi da un giorno all'altro.
Quindi la domanda non è più "costruire o comprare". È più simile a: per cosa si paga effettivamente quando si acquista un SaaS?
Il nuovo calcolo
Ecco ciò che penso che la maggior parte dei fondatori di SaaS (me compreso, onestamente) non voglia sentire: se la sua intera proposta di valore è "le abbiamo evitato di costruirla", è nei guai. Perché quel fossato è appena diventato molto meno profondo.
Quando un team può prototipare uno strumento interno funzionale in un giorno, l'asticella di ciò che giustifica un abbonamento mensile si alza notevolmente. Non deve solo essere migliore di quello che potrebbero costruire loro. Deve essere migliore di quello che potrebbero costruire con l'aiuto dell'AI.
Gartner ha previsto nell'aprile 2026 che entro il 2028, oltre la metà di tutte le aziende smetterà di pagare per l'intelligenza assistiva e favorirà le piattaforme che si impegnano a ottenere risultati dal flusso di lavoro. Ancora più grave: si prevede che entro il 2030, le aziende di software che sovrappongono l'AI alle applicazioni esistenti, anziché riprogettarle per l'esecuzione agenziale, subiranno una compressione dei margini fino all'80%.
Ottanta per cento. Non è un errore di arrotondamento.
Quindi cosa sopravvive davvero?
Ho riflettuto molto su questo aspetto, in parte perché stiamo costruendo Rasepi e devo essere onesto con me stesso su dove si colloca il nostro valore. E credo che la risposta si riduca a tre cose che sono davvero difficili da replicare con uno sprint di codifica nel fine settimana, a prescindere dalla bravura dell'assistente AI.
La profondità del dominio che non si può falsificare. Chiunque può costruire un editor di testo. Costruire un sistema di traduzione che tenga traccia delle modifiche del contenuto a livello di paragrafo, che rilevi le traduzioni obsolete attraverso l'hashing del contenuto e che gestisca l'adattamento strutturale tra le lingue? Questo richiede anni di conoscenza del dominio, incorporata nell'architettura. L'AI può aiutarla a scrivere il codice più velocemente, ma non può dirle cosa costruire.
**Il punto è che costruire è divertente. Mantenere? Non è affatto divertente. Gestire i casi limite nei sistemi di permessi multi-tenant, tenere il passo con le stranezze dei browser, gestire le migrazioni dei database tra le varie versioni, correggere i CVE alle 2 del mattino, gestire il bug dell'esportazione dei PDF che si presenta solo in Safari. L'AI rende più veloce la creazione iniziale, certo. Ma la ricerca di Forrester dell'aprile 2026 mostra che la maggior parte delle aziende non riesce ancora a trasformare l'adozione dell'AI in un impatto misurabile, in parte perché la parte difficile non è mai stata la scrittura del codice. Si tratta di mantenere l'oggetto in funzione, aggiornato e funzionante per anni. La costruzione è la parte facile. Sono i tempi di attività, i turni di reperibilità e le correzioni incrementali a costare.
Fiducia, sicurezza e privacy dei dati. Questo aspetto è sottovalutato. Quando costruisce qualcosa da solo, la sicurezza è di sua proprietà. È responsabile della crittografia a riposo, della registrazione degli audit, dei test di penetrazione, della conformità GDPR, SOC 2 e della prossima normativa di cui nessuno ha ancora sentito parlare. Un buon fornitore SaaS ha un intero team il cui unico compito è quello di assicurarsi che i suoi dati non finiscano in un posto dove non dovrebbero essere. Per la maggior parte delle aziende, questo non è un costo che vogliono sostenere internamente. E onestamente, la maggior parte degli strumenti interni che ho visto non dispone nemmeno di controlli di accesso adeguati, per non parlare di una traccia di audit di sicurezza.
La via di mezzo compostabile
L'aspetto interessante è che sempre più spesso la risposta non è "costruire" o "comprare". Si tratta di comporre. Scelga gli strumenti SaaS che fanno bene le cose difficili, espongono buone API e le permettono di costruire intorno a loro.
Questo è il motivo per cui le architetture di plugin sono così importanti in questo momento (e sì, questo è esattamente ciò in cui abbiamo investito con il sistema di plugin di Rasepi). I prodotti SaaS che prospereranno sono quelli che dicono: "Noi ci occupiamo del nucleo duro e specifico del dominio. Lei personalizza tutto il resto". Non "Ecco il nostro monolite, prendere o lasciare".
Il rapporto di Forrester dell'aprile 2026 ha rilevato che la maggior parte delle aziende sta ancora lottando per trasformare l'adozione dell'AI in un impatto aziendale misurabile. I grandi adottatori hanno il 47% di probabilità in più di collaborare con partner di consulenza per preparare i loro dati e sistemi. Il messaggio è chiaro: la capacità di costruzione grezza non è il collo di bottiglia. Sapere cosa costruire e avere l'infrastruttura per supportarlo è il vero vincolo.
Cosa significa per SaaS
Se gestisce un'azienda SaaS nel 2026, credo che ci siano alcune verità scomode:
- Il risparmio di tempo era la classica vendita SaaS. Ma quando l'AI comprime il tempo di costruzione del 20-30%, il numero di "tempo risparmiato" nel suo foglio di calcolo del ROI si riduce proporzionalmente. Ha bisogno di una storia diversa.
- Le caratteristiche sono la posta in gioco, i risultati sono il prodotto.** A nessuno interessa che lei abbia 47 integrazioni. A loro interessa che la documentazione sia aggiornata, che le traduzioni siano accurate, che il team utilizzi effettivamente lo strumento. Il linguaggio di Gartner sul "flusso di lavoro incentrato sui risultati" non è solo un gergo da analista. È la direzione che sta prendendo il mercato.
- L'istinto di chiudere la piattaforma e di rendere difficile il passaggio è comprensibile. Ma Gartner ha esplicitamente avvertito che "i fornitori SaaS legacy che tentano di chiudere i sistemi di record rischiano di essere aggirati dai livelli di orchestrazione di cui le aziende si fidano di più". Ahi.
La versione onesta
Sarò schietto sulla mia posizione in merito. Costruire o comprare non ha mai riguardato la tecnologia. Si è sempre trattato di fiducia. Mi fido del fatto che questo fornitore comprenda il mio problema in modo così profondo che la sua soluzione sarà migliore di quella che potrei mettere insieme io?
Nel 2026, il "cobble together" è stato aggiornato in modo massiccio. Quindi anche la barra della fiducia si è alzata.
Per noi di Rasepi, questo significa che non possiamo essere solo uno strumento di documentazione che supporta le traduzioni. Dobbiamo essere così profondamente bravi nei problemi difficili, il monitoraggio delle traduzioni a livello di blocco, l'applicazione della freschezza dei contenuti, la complessità multi-tenant, che la costruzione di un sostituto sarebbe davvero dolorosa anche con i migliori strumenti di intelligenza artificiale del mondo.
Questo è il nuovo "build vs buy". Non "può costruirlo?", ma "deve spendere le sue energie per costruirlo quando qualcun altro ha già risolto le parti difficili?".
La domanda non ha mai riguardato il costo. Si trattava di capire dove si vuole spendere la propria attenzione. E in un mondo in cui la costruzione è economica, l'attenzione è l'unica risorsa scarsa rimasta.