Il mito del "SaaS è morto": lezioni da un fallimento nello sviluppo interno basato sull'IA

@emooove
GIAPPONESE14 ago 2026
134K
405
66
7
389

TL;DR

Un CEO condivide la sua esperienza nella creazione di strumenti interni con l'IA, sottolineando che, sebbene la creazione sia semplice, la manutenzione, la sicurezza e la UX rimangono ostacoli significativi che i SaaS continuano a risolvere meglio per la maggior parte delle aziende.

La frase "SaaS è morto" sta spopolando ultimamente. La tesi è che, vivendo in un'epoca in cui l'AI sa scrivere codice, dovremmo smettere di pagare abbonamenti mensili per i servizi SaaS e costruirci da soli ciò che ci serve, internamente.

Nella mia azienda, Emooove, abbiamo passato gli ultimi mesi completamente dedicati a costruire i nostri sistemi interni. Avendolo fatto davvero, ho sperimentato sia i successi che le lezioni dolorose. Oggi voglio condividere la mia prospettiva sulla narrazione del "SaaS è morto", basata su quell'esperienza reale.

Per essere chiaro, scrivo questo dal punto di vista di un utente/creatore di sistemi, non di un fornitore di SaaS.

Un'epoca straordinaria in cui chiunque può creare sistemi

Prima di tutto, come premessa: l'arrivo di Claude Code ha davvero inaugurato un'epoca in cui "chiunque può creare un sistema". Non è un'esagerazione.

In Emooove, una recruiter che era con noi da appena due mesi ha creato un ATS (Applicant Tracking System) interno. Non è un'ingegnera, ha zero esperienza tecnica. Eppure ha creato un sistema funzionante che gestisce tutto, dall'importazione dei candidati alla gestione della selezione fino alle dashboard.

Inoltre, stiamo attualmente sviluppando un sistema interno per migliorare l'efficienza operativa e la qualità del nostro core business, i servizi di agenzia di vendita. Mi dedico personalmente a questo ogni giorno e, a meno di due settimane dall'inizio, sento che siamo sul punto di creare qualcosa di molto buono.

È comprensibile che le persone vogliano dire "SaaS è morto" quando puoi costruire internamente qualcosa che altrimenti costerebbe decine o centinaia di migliaia di yen al mese in abbonamenti SaaS.

Tuttavia, non è tutto in discesa

Questo è il punto principale. Quando ci abbiamo provato davvero, non è stato tutto rose e fiori.

1. La manutenzione è incredibilmente difficile

Nel bene e nel male, puoi costruire le cose "al volo", quindi prendono forma rapidamente. Tuttavia, poiché i requisiti non sono completamente definiti, ci sono molti spigoli da smussare.

Nel caso del nostro ATS, abbiamo visto cose come:

  • Candidature che dovevano essere importate ma non lo erano.
  • Numeri della dashboard in qualche modo bacati.
  • Pulsanti critici mancanti, che bloccavano le operazioni.

Abbiamo incontrato molte "dimenticanze che abbiamo notato solo dopo aver iniziato a usarlo". Con il nostro sistema di supporto alle vendite interno, c'è stata persino una mattina in cui all'improvviso non riuscivamo ad accedervi e la schermata non si apriva.

Naturalmente, questi problemi si possono risolvere in una certa misura definendo i requisiti con più attenzione o apportando miglioramenti man mano. Tuttavia, durante quel periodo, le normali operazioni aziendali vengono interrotte. Se inizi a costruire con l'aspettativa che sia "facile e veloce", ti ritroverai nei guai. Ho capito che non dovresti iniziare con la mentalità di "costruire e finire", ma piuttosto di "costruire e continuare a sistemare".

Poiché la nostra scala di reclutamento è piccola, possiamo gestire anche se l'ATS si ferma per un po'. Ma rabbrividisco al pensiero se questo fosse un sistema con molti stakeholder. All'aumentare del numero di utenti e dell'ambito di impatto, la perdita derivante da un singolo guasto cresce e il livello di difficoltà sale alle stelle.

Anche se per i sistemi interni puoi tollerarlo, dovresti essere estremamente cauto nel costruire qualsiasi cosa per la vendita esterna o qualsiasi cosa che si rivolga al mondo esterno, come un modulo di contatto.

2. La UI/UX non viene mai rifinita

Me ne sono reso conto mentre costruivo il sistema io stesso: il risultato finale è piuttosto mediocre.

Le schermate che l'AI genera inizialmente sembrano "presentabili", ma quando le usi davvero, i dettagli sono goffi. Anche se alla fine puoi farle sembrare belle dando istruzioni più e più volte, questo richiede un'ossessione intensa e tempo. Molte persone probabilmente si accontenteranno a metà strada.

Le interfacce SaaS sono rifinite perché i designer professionisti hanno passato anni ad analizzare il feedback degli utenti; non è qualcosa che ottieni gratis.

3. Il problema della sicurezza

Questa è la parte più spaventosa.

Anche i non ingegneri possono usare Claude Code per creare funzioni e UI/UX con un approccio "improvvisato". Ma è possibile recuperare terreno sulla sicurezza allo stesso modo? Almeno per me, no. Autenticazione, gestione dei permessi, risposta alle vulnerabilità — "funzionare" ed "essere sicuro" sono due cose completamente diverse.

Nel nostro caso, fortunatamente abbiamo qualcuno con esperienza come ingegnere della sicurezza, quindi ci assicuriamo che sia lui a occuparsi di questa parte. Anche così, rimane un po' di ansia. Il solo pensiero di un'organizzazione senza esperti che mette i dati dei clienti su un sistema costruito per capriccio e lo rende pubblico mi fa sudare freddo.

La logica binaria "vivere o morire" è sbagliata

Ho elencato gli aspetti negativi dello sviluppo interno, ma onestamente ci sono anche molte cose buone.

  • Puoi costruire qualcosa che si adatta perfettamente alla tua attività.
  • Se vuoi sistemare qualcosa, puoi farlo il giorno dopo.
  • Non ci sono quasi costi mensili.
  • L'azienda acquisisce know-how e la fiducia che "possiamo costruire sistemi da soli".

Il problema è cercare di ridurre tutto a "Il SaaS vivrà o morirà?". La scelta tra adottare un SaaS o costruire internamente dipende dalla situazione dell'azienda. In base alla mia esperienza, ecco i cinque punti da considerare:

Punto 1: Hai ingegneri in casa?

Se non li hai, fallirai in aree come la sicurezza, che i non ingegneri non possono gestire con leggerezza. La parte più spaventosa è riuscire a costruire le funzioni senza rendersi conto dei pericoli. Il punto di svolta è se riesci a trovare una persona esperta che riveda le aree critiche.

Punto 2: Numero di stakeholder

Se sono troppi, la perdita quando si verifica un guasto è enorme e il livello di difficoltà aumenta notevolmente. Al contrario, le organizzazioni piccole possono sperimentare più facilmente perché possono semplicemente scusarsi se qualcosa si ferma. È realistico iniziare con operazioni che hanno un ambito di impatto ridotto.

Punto 3: Sistemi esterni vs. interni

Con i sistemi interni, il rischio è limitato se succede qualcosa. Tuttavia, per qualsiasi cosa esterna, una singola fuga di informazioni può essere irreversibile. Mentre il SaaS ti permette di scaricare parte della responsabilità sul fornitore, con lo sviluppo interno tutto è responsabilità tua. Il valore della "tranquillità comprovata" del SaaS cresce per qualsiasi cosa rivolta all'esterno.

Punto 4: Riesci a dedicare tempo alla manutenzione?

La manutenzione richiede più tempo di quanto immagini. Lo sviluppo interno non è "costruire e finire" ma "continuare a sistemare". Riesci a iniziare con questa consapevolezza? Se inizi con un atteggiamento superficiale, verrai sommerso dai difetti da correggere e metterà sotto pressione il tuo core business.

Punto 5: Ti piace/vuoi sviluppare con l'AI?

Alla fine, tutto si riduce a questo. È più noioso e difficile di quanto pensi, ed è frustrante quando l'AI non ascolta (ride). Riesci a portarlo a termine comunque? È un'epoca fantastica per chi si diverte, ma non credo che possa essere sostenuta solo dal senso del dovere.

Sintesi: il SaaS non è morto. Ci sono solo più opzioni.

Ho usato la parola "fallito" nel titolo, ma per essere più precisi, è stato "quasi fallito molte volte". Continuiamo lo sviluppo interno perché abbiamo ingegneri esperti, la nostra organizzazione è ancora piccola, è principalmente per uso interno, siamo pronti a impegnarci nella manutenzione e, soprattutto, io voglio farlo. Si potrebbe dire che lo facciamo perché siamo in un ambiente privilegiato in cui tutti e cinque i punti sono soddisfatti.

Al contrario, se un'azienda che non soddisfa queste condizioni prende alla lettera "SaaS è morto" e cerca di costruire internamente le proprie attività principali, fallirà davvero.

Il SaaS non è morto. È solo che l'opzione di "costruire" è ora aperta a tutti. Valuta con calma la situazione della tua azienda e usa sia il SaaS che lo sviluppo interno. Non è forse questo il modo giusto di affrontare quest'epoca tanto comoda quanto precaria?

Rielabora in YouMind

Turn one viral article into a full content workflow

Collect the source, decode the pattern, create assets, draft the story, and distribute from one AI workspace.

Explore YouMind
Per i creator

Trasforma il tuo Markdown in un articolo 𝕏 pulito

Quando pubblichi i tuoi testi lunghi, formattare immagini, tabelle e blocchi di codice per 𝕏 è una seccatura. YouMind trasforma un'intera bozza Markdown in un articolo 𝕏 pulito e pronto da pubblicare.

Prova Markdown verso 𝕏

Altri pattern da decodificare

Articoli virali recenti

Esplora altri articoli virali