Usi un software as a service e hai iniziato a chiederti se potresti sostituirlo con l'AI? Ecco, anche noi. Questa è la nostra storia (a lieto fine!) e, per andare fino in fondo con il meta, abbiamo sostituito un tool di "SaaS management" con un software su misura scritto interamente con l'AI.

Cosa sono i tool di SaaS management e qual è il nostro problema con loro

La maggior parte delle aziende usa diversi tool SaaS per lavorare, e Buildo non fa eccezione. Man mano che il numero di questi strumenti cresce, cresce anche la complessità di gestione: come gestiamo i pagamenti di questi tool (carte di credito, bonifici?), come teniamo traccia degli strumenti che usiamo, come ci assicuriamo di non pagare troppo per un tool, ecc.

Ecco perché esistono i tool di SaaS management: un SaaS per gestire tutti gli altri. Le funzionalità principali di questa categoria di strumenti di solito sono:

• Emissione di carte virtuali per ogni tool
• Possibilità di impostare limiti hard/soft su queste carte
• Riconciliazione delle fatture
• Panoramica dei tool approvati in uso
• Scoperta dei tool "non approvati" usati in azienda

Sembrava molto interessante, così un paio di anni fa ci siamo iscritti a uno dei più diffusi e lo abbiamo usato fino all'inizio di quest'anno: i dipendenti hanno accesso al SaaS manager, possono richiedere carte per pagare i tool di cui hanno bisogno e impostare i limiti in modo appropriato.

Arriviamo a oggi e, guardandoci indietro, ecco la mia valutazione di quali funzionalità contano davvero per noi e quali no:

• ✅ Emissione di carte virtuali. È comodo: in un'azienda piccola come la nostra potresti essere tentato di emettere un'unica carta "tool" e usarla per tutto, ma questo approccio è miope: se quella carta viene compromessa o scade, l'impatto ricade su tutti i tool in una volta sola. Allo stesso modo, impostare limiti di spesa tool per tool diventa molto difficile.
• ✅ Impostazione di limiti hard/soft sulle carte. Molto comodo e ci ha fatto risparmiare centinaia di euro lungo il percorso: rinnovi accidentali o improvvisi aumenti nei prezzi degli abbonamenti ora fanno scattare un avviso chiaro (nel caso dei limiti soft) o bloccano direttamente il pagamento (limiti hard), rendendoci immediatamente consapevoli di qualsiasi problema di budget.
• ❌ Riconciliazione delle fatture. Concettualmente interessante, ma alla fine non l'abbiamo usata affatto. L'idea è che ogni transazione genera un "task" e il task si completa quando ci alleghi la fattura corrispondente. Ci sono poi alcune integrazioni (come uno scraper delle email) che provano a trovare le fatture automaticamente. Il punto è questo: la storia dei task non funziona perché le persone non vogliono l'ennesimo-tool-di-task-management da monitorare: viene semplicemente ignorato. Le integrazioni funzionano a volte, ma in modo abbastanza inaffidabile da non poterci davvero contare. Così, pur avendo un tool dedicato, abbiamo continuato a fare quello che facevamo prima: inoltrare ogni fattura al nostro commercialista e lasciare che ci avvisi se ne manca qualcuna. È deludentemente noioso e probabilmente possiamo migliorare, ma non è davvero un grande punto dolente 🤷
• ❌ Panoramica dei tool approvati in uso. Di nuovo, concettualmente interessante, ma manteniamo già un database Notion dei tool che usiamo, con una descrizione, un owner, le procedure correlate, guide interne, ecc. È tutto molto integrato e cucito sui nostri processi, e la "lista SaaS" fornita da un altro vendor è per noi solo un corpo estraneo (e non è possibile integrarla via API perché… non ne hanno una). Quello che offre il tool di SaaS management è solo un elenco di roba con alcune proprietà che posso filtrare e aggregare: impallidisce rispetto a ciò che possiamo già fare con Notion.
• ❌ Scoperta dei tool "non approvati" usati in azienda: questa non è una funzionalità che il nostro attuale tool di SaaS management ha, ma ne ho provati altri ed è fondamentalmente un gran caos. L'idea è che il tool di management si infila nei dati della tua azienda (per esempio controllando i login Google dei dipendenti) e prova a dedurre se qualcuno sta usando tool "sconosciuti". Suona davvero fico se vuoi un falso senso di controllo, ma primo, quelli che abbiamo provato erano estremamente rumorosi e imprecisi, devi setacciare troppi falsi positivi per tirar fuori qualcosa che ti interessa; secondo, i tool che ti interessano sono già mappati: se qualcuno doveva pagarli, ha dovuto chiedere una carta, e questo di norma è tracciato su Notion. Se il tool è gratuito: mi interessa davvero? Voglio dire, sperimentare con nuovi tool è una cosa che incoraggiamo attivamente e per un'azienda delle nostre dimensioni non ha senso essere estremamente prescrittivi su cosa si può e non si può usare

In sostanza, sembra che ci interessi una cosa sola: emettere carte virtuali su richiesta e impostarci dei limiti.

Il tool di SaaS management che usiamo oggi lo fa bene, ma:

• È l'ennesimo tool che le persone devono conoscere, in cui fare login, ecc.
• È integrato male con il nostro database di tool già esistente su Notion.
• Costa! Attualmente paghiamo 125$/mese ma stiamo per aver bisogno di un piano più grande per continuare ad aggiungere tool, il che porterebbe il prezzo a 200$/mese. E una volta superata quella soglia (cosa del tutto plausibile, visti i nostri numeri), il prezzo schizza a 500$/mese.

E quindi?

A prima vista, spendere tra i 2000$ e i 5000$/anno per un tool di questo tipo sembra spaventoso, ma non è l'unico tool su cui spendiamo cifre del genere, quindi non è un problema in termini assoluti.

Qual è l'alternativa? Siamo un'azienda di software, quindi è lecito chiedersi quanto costa costruire un tool interno che ci dia le stesse funzionalità.

Ci ho pensato un paio di volte negli ultimi due anni, e fino a oggi avevo sempre stimato che il costo non lo giustificasse: ci vorrebbero forse un paio di settimane per costruirlo e poi va mantenuto, ecc. E anche quando i conti tornano, è difficile trovare il tempo e la concentrazione per incastrare un progetto del genere.

Tutto questo è cambiato con l'avvento della programmazione agentica e di Claude Code.

Vibe Engineering per il tooling interno

Ho iniziato a sperimentare con Claude Code alla fine del 2025, e questo mi è sembrato un buon caso d'uso per metterlo alla prova: se riesco a tirar fuori un tool alternativo in 1-2 giorni, allora l'economia dell'intera faccenda cambia in modo significativo e il break-even ha molto più senso.

Quindi, come l'ho affrontato?

Step 1

Chiacchierare con Claude. Non ero al computer quando mi è venuta l'idea, quindi non avevo accesso a Claude Code — probabilmente un bene, visto che mi ha costretto a ragionare a fondo sul design prima di scrivere una riga di codice. Ecco il mio prompt iniziale a Claude (usando Opus 4.5, il modello di frontiera all'epoca):

Nella mia azienda usiamo XXX, un SaaS per emettere carte virtuali per i tool che utilizziamo. XXX offre molte funzionalità ma quelle più interessanti per noi sono: poter emettere carte virtuali ai dipendenti da usare per vari tool; poter impostare limiti su queste carte; avere una panoramica dei tool che stiamo pagando. Ora, dato che usiamo anche Revolut Business per emettere carte personali ai dipendenti, mi chiedevo se possiamo usare Revolut (più qualche integrazione custom) per sostituire XXX, che costa circa 200 euro/mese.

Da notare che, quando ho posto questa domanda, non avevo idea se Revolut potesse essere una buona scelta o meno.

Dopo una ventina di minuti di chiacchierata con Claude siamo arrivati a questi punti chiave:

• Revolut è effettivamente una buona scelta: offre Company Card virtuali, cioè carte intestate all'azienda anziché a una persona specifica. È l'ideale per il nostro caso d'uso. Possiamo anche impostare limiti hard su queste carte, sia su un arco di tempo sia per singola transazione
• Aspetto cruciale, Revolut Business offre un'API per creare carte, ma bisogna richiederne manualmente l'accesso
• Probabilmente non serve una UI dedicata: possiamo usare Notion come interfaccia principale. Abbiamo verificato che le rispettive API di Notion e Revolut offrono ciò che ci serve per far funzionare l'integrazione (webhook e così via)
• Possiamo scrivere un piccolo servizio di backend per orchestrare Notion e Revolut, e possiamo mantenerlo stateless (i dati veri e propri vivono in uno dei due tool). Questa è un'altra grande vittoria, perché non devo mantenere dati da nessuna parte né preoccuparmi di persistenza, backup, ecc.

Questa è una delle principali svolte che l'AI ha introdotto nel processo di design del software: sono riuscito a fare avanti e indietro e a validare le mie assunzioni nel giro di minuti, mentre farlo manualmente mi avrebbe richiesto diverse ore.

A questo punto ho sparato un'email al supporto di Revolut e ho incrociato le dita.

Step 2

Fare la cosa.Con mia sorpresa, Revolut ha risposto molto in fretta e ha abilitato la Cards API! Eravamo pronti a partire. Ho avviato una sessione di Claude Code e boom, meno di un paio d'ore dopo avevo un prototipo funzionante.Per maggiore sicurezza, ho deciso di non memorizzare le informazioni della carta su Notion, ma di collegarle al 1Password della nostra azienda. Una volta creata la carta, ne salvo le informazioni in un secure item e lo collego a Notion.Sono poi passato a creare un db delle transazioni, così da poter tracciare le transazioni di ciascuna carta, e a implementare il meccanismo del "soft budget" (se una carta supera il budget, non bloccare la transazione ma emettere un avviso).Tutto sommato, l'intera cosa ha richiesto circa 5-6 ore per essere implementata, da zero.Non ho scritto una singola riga di codice, ma ho implementato tutti i guardrail ragionevoli per garantire la qualità:

• Ho deciso io le tecnologie core da usare, così da sentirmi sicuro nel mantenerlo (Node.js, TypeScript, Fastify)
• il progetto ha formattazione, linting, typechecking, ecc. (imposti in CI)
• il progetto ha oltre 30 test di integrazione per le funzionalità core (anch'essi imposti in CI)
• c'è una documentazione architetturale estesa

Step 3

Profitto, e un po' di divertimento.

Sembrava tutto troppo facile, così ho deciso di dedicare un po' di tempo alla creazione di un logo e di un video di lancio (usando Remotion). Il logo è stato fatto per lo più con Gemini, mentre il video è il risultato di una sessione di 30 minuti con Claude Code.

Cosa abbiamo imparato

È stato interessante vedere come la programmazione agentica (vibe engineering, chiamatela come volete) possa velocizzare in modo significativo alcune attività di ingegneria.

È allettante archiviare tutto questo sotto "posso vibe-codare un SaaS in un giorno", ma così si tralasciano alcune informazioni:

• L'ingegneria del software non è solo scrivere codice: è risolvere problemi con il software. Identificare il problema, progettare una soluzione, tirar fuori idee da validare, decidere l'approccio migliore (Notion vs UI, stateful vs stateless, ingegnerizzare il tutto con test e altri guardrail, ecc.) sono tutte cose che ho fatto io, e sono stato efficace nel farle perché creare software su misura per risolvere problemi è letteralmente il mio lavoro.
• Dai lo stesso problema a una persona non tecnica, o anche a una persona tecnica che non è abituata ad analizzare i requisiti di prodotto e a valutare i trade-off, e ti assicuro che il risultato o farà schifo o richiederà molto più tempo.
• La vera competenza in gioco qui era la raccolta dei requisiti: sono riuscito a tirar fuori questa soluzione perché avevo identificato un insieme chiaro di funzionalità che ci servivano e — aspetto cruciale — un insieme di funzionalità che non ci servivano. Quindi, in definitiva, non ho "vibe-codato un SaaS in un giorno"; ho estratto esattamente le funzionalità di cui avevamo bisogno dal prodotto che stavamo pagando e le ho integrate a fondo con i nostri strumenti esistenti.

Conclusioni

Si può fare! La nostra esperienza dimostra che l'AI sta decisamente spostando l'ago della bilancia del make-or-buy verso il make, ma con dei distinguo. La superficie del problema deve essere gestibile e ben compresa: l'AI non capirà per magia le esigenze del tuo business.

Allo stesso tempo, più vai sul custom, più devono essere coinvolti professionisti del software: è facile vibe-codare una demo, è ancora difficile farla funzionare davvero e distribuirla in tutta l'organizzazione, se non hai le competenze necessarie.

Se vuoi intraprendere il percorso per riprendere il controllo dei tuoi tool, siamo felici di aiutarti!