Il problema del vibe coding non è che non funzioni.
Il problema è che funziona.
Funziona abbastanza bene da farti credere, troppo presto, di avere costruito un software vero.
Io ci ho provato con un CRM. In due giorni e con circa 200 euro di crediti avevo una pipeline, delle tabelle, una dashboard e un login. Potevo inserire un'azienda, aprire un'opportunità e trascinarla da una fase all'altra.
A prima vista sembrava fatto.
Poi ho capito che avevo costruito soltanto la parte facile.
Tra una demo che funziona e un sistema a cui affidare i dati commerciali della tua azienda per i prossimi vent'anni c'è un abisso. È dentro quell'abisso che cominciano i problemi che nei video sul “CRM costruito in 12 minuti” quasi nessuno mostra.
Implemento CRM dai primi anni Duemila. Non ho fatto questo esperimento per dimostrare che costruire un CRM con l'AI sia impossibile. Volevo capire fin dove si può arrivare e, soprattutto, che cosa succede dopo l'entusiasmo del primo momento.
Ho trovato sette problemi. Non il pulsante fuori posto o il filtro che non va. Problemi più profondi, che iniziano quando il CRM va online e dentro ci finiscono persone, processi e dati veri.
Con “CRM No Code” si intende, in genere, un sistema costruito usando piattaforme visuali, componenti già pronti e automazioni, senza sviluppare tutto nel modo tradizionale. Oggi queste piattaforme si sono aggiunte anche i servizi generati dall'intelligenza artificiale: descrivi quello che vuoi e loro generano tabelle, schermate, regole e pezzi di codice.
Da qui nasce il vibe coding (Lovable, Base44, Claude, eccc...). Non parti dalle specifiche tecniche, né dalla programmazione; parti da una conversazione. Chiedi una funzione, guardi il risultato, aggiusti il prompt e continui.
Per arrivare a un prototipo è straordinario. In poche ore puoi vedere un'idea che prima avrebbe richiesto giorni o settimane. Il guaio comincia quando la velocità della demo viene scambiata per semplicità del progetto.
Sono due cose molto diverse.
All'inizio ti servono una tabella clienti, una pipeline, qualche attività e una dashboard. Tutto comprensibile. Trascini le opportunità da una colonna all'altra e hai la piacevole sensazione di essere già a buon punto.
Poi entrano i dati reali.
Due commerciali inseriscono la stessa azienda. Quale record rimane? Un contatto cambia lavoro: lo sposti nella nuova azienda o perdi lo storico della relazione precedente? Un'opportunità resta aperta per diciotto mesi perché nessuno la aggiorna. Il CRM deve chiuderla? Deve avvisare qualcuno? Chi?
E non abbiamo ancora parlato dei permessi. Un commerciale può modificare le opportunità di un collega? Può vedere i margini? Può esportare tutti i clienti?
Domande del genere sembrano tecniche, ma spesso nascondono decisioni di business mai prese.
Che cos'è un lead nella tua azienda? Quando diventa un'opportunità? Chi ne diventa responsabile? Quando la consideri persa?
Se il processo commerciale è confuso, l'AI non lo mette magicamente in ordine. Al massimo digitalizza la confusione, con una bella interfaccia sopra.
Questo è il primo equivoco: l'AI sa costruire molto velocemente ciò che le chiedi. Il difficile è sapere che cosa chiederle. Un freelance con trenta contatti potrebbe convivere benissimo con qualche regola implicita. Una rete B2B con dieci commerciali, territori, obiettivi, forecast e assegnazioni automatiche no.
È lì che si vede la differenza tra avere generato un'applicazione e avere progettato un sistema. Se vuoi partire dalle basi, qui trovi anche la mia spiegazione su che cos'è un CRM e a che cosa serve.
Quando costruisci un CRM a colpi di prompt è facilissimo metterci dentro il tuo modo di ragionare. Usi i nomi che per te sono ovvi, aggiungi i campi che servono a te e sistemi i pulsanti dove ti aspetti di trovarli.
Poi il CRM lo dai a un collega.
“Qui cosa devo mettere?”
“Che differenza c'è tra lead e opportunità?”
“Perché questo campo è obbligatorio?”
“Dov'è finita la funzione che ieri era qui?”
Nel giro di qualche giorno arriva la frase che ogni progetto CRM teme: “Io intanto me lo segno su Excel.”
Non è colpa del No Code. Accade anche nei progetti tradizionali. La differenza è che, quando costruisci da solo, rischi di saltare tutto ciò che sta intorno al software: interviste agli utenti, test, formazione, documentazione, feedback e correzioni.
Una schermata intuitiva per chi l'ha disegnata non è automaticamente intuitiva per gli altri. E un CRM usato benissimo da una sola persona non è ancora un sistema aziendale.
La user adoption è spesso il punto in cui i progetti si fermano, qualunque tecnologia ci sia sotto. Ne ho parlato più in dettaglio nell'articolo dedicato a perché i commerciali odiano il CRM.
Se fossi un imprenditore che sta valutando un CRM No Code, questo sarebbe il punto su cui farei più domande.
Nel CRM finiscono clienti, contatti, offerte, prezzi, contratti, note commerciali e previsioni di vendita. In pratica, una parte importante del patrimonio informativo dell'azienda.
Durante la mia prova il login funzionava. La pipeline si caricava. I dati erano al loro posto. Tutto bene, apparentemente.
Ma chi poteva leggere le tabelle? I permessi erano controllati davvero dal server o soltanto nascosti nell'interfaccia? Dove venivano conservate le chiavi? Che cosa sarebbe successo alle credenziali di un dipendente uscito dall'azienda?
Poi ci sono i backup. Dire “li facciamo” tranquillizza tutti. La domanda interessante, però, è un'altra: qualcuno ha mai provato a ripristinarne uno?
La sicurezza è difficile da vedere in azione. E proprio per questo in una demo fa raramente una brutta figura. Puoi avere un'applicazione che continua a comportarsi benissimo mentre sotto c'è un controllo dei permessi sbagliato o una sessione gestita male.
Usare Base44, Lovable o un'altra piattaforma non rende automaticamente insicuro il CRM. Ma non lo rende neppure automaticamente sicuro. La piattaforma può darti buoni strumenti; qualcuno deve comunque configurarli, controllarli e capire se le scelte proposte dall'AI hanno senso.
Chiedere “scrivimi del codice sicuro” non basta. Bisogna essere in grado di verificare la risposta.
La demo costruita in venti minuti è impressionante. Il giorno più interessante, però, arriva molto più tardi.
Mettiamo che fra due anni l'azienda apra un nuovo mercato e debba aggiungere una valuta. Oppure cambi il processo commerciale, acquisti un altro gestionale o introduca una nuova regola di assegnazione dei lead.
Nel frattempo sul CRM avrai aggiunto una funzione oggi, corretto quella di ieri e modificato con un prompt qualcosa che dipendeva da qualcos'altro. Non c'è nulla di strano: è quello che succede al software quando viene usato. La particolarità del vibe coding è che accelera sia la creazione sia l'accumulo della complessità.
Se nessuno governa architettura, test e documentazione, prima o poi ogni modifica diventa più delicata della precedente.
E poi c'è Marco.
Marco è la persona che ha costruito il CRM con l'AI. Sa perché quel campo non si può eliminare e ricorda il motivo di quella regola apparentemente assurda. Tutti chiedono a lui.
Finché Marco lavora in azienda.
Finché ricorda tutto.
Finché ha tempo.
Quando Marco se ne va, l'azienda può scoprire che la vera documentazione del sistema era nella sua testa. All'inizio sembrava un risparmio. In realtà una parte del conto era stata soltanto spostata nel futuro.
Un CRM vero non vive da solo. Parla con email, calendario, fatturazione, gestionale, marketing automation e spesso con altri sistemi ancora.
Durante una demo è abbastanza semplice prendere un dato dal CRM e portarlo nel Gestionale. Il problema arriva quando il CRM non risponde.
Riprovi? Quante volte? Se nel frattempo il dato è già arrivato, come eviti di creare un doppione? Se la stessa azienda viene modificata contemporaneamente nel CRM e nell'ERP, chi ha ragione?
La questione non è far funzionare un'integrazione quando tutto va bene. È avere deciso prima che cosa deve succedere quando qualcosa va male. Perché, se un sistema viene usato abbastanza a lungo, qualcosa prima o poi va male.
Più strumenti sono già presenti in azienda, più questa parte pesa. È uno dei motivi per cui, quando si deve scegliere il CRM più adatto, consiglio di guardare non soltanto alle funzioni disponibili oggi, ma anche alle integrazioni che serviranno domani.
La promessa economica è irresistibile: “Me lo costruisco da solo e non pago più il canone.”
Capisco benissimo il ragionamento. Ma il prezzo della licenza e il costo di possedere un sistema sono due cose diverse.
Io, per arrivare alla mia demo, avevo già speso circa 200 euro di crediti e due giorni di lavoro. Poi sarebbero arrivati l'hosting, i servizi esterni, i backup, i test, la documentazione, la formazione degli utenti e la manutenzione. Senza contare il tempo necessario per controllare i permessi o rimettere in piedi un'integrazione.
Quindi sì, un CRM gratis può esistere come formula commerciale o come licenza. Non significa che sia privo di costi.
C'è poi una voce che in pochi mettono nel preventivo: il costo della comprensione.
Prima o poi l'AI ti chiederà se vuoi aggiungere la row-level security o gestire il refresh dei token. Se non sai che cosa vogliono dire queste espressioni, che fai? Dici sì e vai avanti?
Il primo “sì” probabilmente non crea problemi. Nemmeno il secondo. A un certo punto, però, non stai più delegando soltanto il lavoro. Stai delegando decisioni che nessuno in azienda è in grado di valutare.
La domanda utile non è “l'AI è abbastanza brava da fare un CRM che funzioni?”. È: “noi siamo abbastanza competenti da capire quando sta sbagliando?”.
Prima di costruire tutto da zero, vale la pena provare ciò che esiste già. Ci sono prodotti accessibili e anche progetti open source: per esempio, ho provato Twenty, un CRM open source gratuito. Anche in quel caso, naturalmente, gratuito non significa senza manutenzione o responsabilità.
Chi può chiedere una modifica al CRM? Chi decide se vale la pena farla? Chi controlla che non rompa qualcos'altro? E chi rivede i permessi quando entra un nuovo dipendente o qualcuno cambia ruolo?
Sono domande poco spettacolari. Eppure è da queste che dipende la vita del sistema.
In molti progetti costruiti internamente la risposta è sempre la stessa: “Chiediamo a Marco, l'ha fatto lui”.
Non è governance. È dipendenza da una persona.
Non serve trasformare una piccola azienda in una multinazionale piena di comitati. Serve però sapere chi approva le modifiche, chi gestisce gli accessi, dove si fanno i test, come si documentano le decisioni e chi interviene se il CRM si ferma.
Le responsabilità possono essere leggere. Non possono essere invisibili.
No. Non è questa la conclusione.
Il vibe coding è un'opportunità enorme per prototipare un processo, capire che cosa serve prima di acquistare un prodotto o automatizzare un'attività circoscritta. Può essere utile anche per creare una piccola interfaccia sopra un CRM esistente, senza sostituirne il cuore.
E se sei un freelance o una piccola agenzia con poche decine di contatti e requisiti semplici, costruire uno strumento su misura può avere perfettamente senso. In quel caso il rischio è limitato e la semplicità è un vantaggio reale. Ho raccolto qualche considerazione specifica anche nella guida al CRM per freelance.
Il problema nasce quando chiamiamo “CRM” due cose che non sono equivalenti: da una parte un prototipo personale; dall'altra un'infrastruttura aziendale che deve gestire dati sensibili, decine di utenti, integrazioni e anni di cambiamenti.
Con l'AI abbiamo accorciato moltissimo la strada tra l'idea e la demo. Quella tra la demo e la produzione è ancora fatta di processi, test, sicurezza, formazione, integrazioni, manutenzione e responsabilità.
Sono tutte cose meno emozionanti di una dashboard generata con un prompt. Per questo si vedono meno spesso su YouTube.
La prossima volta che qualcuno ti dice “mi sono costruito il CRM in una sera”, non fermarti alla pipeline. Chiedi di vedere anche:
Se queste risposte mancano, non significa che la demo non valga nulla. Significa che è ancora una demo.
Con il vibe coding puoi costruire molto velocemente il CRM che oggi riesci a immaginare. Un'azienda strutturata, però, nei prossimi anni avrà bisogno anche di molte cose che oggi non sa ancora di dover immaginare.
Per questo non mi fermerei ai prodotti più costosi e blasonati, ma non partirei nemmeno automaticamente da zero. Oggi ci sono CRM moderni, flessibili e accessibili che vale la pena provare prima di scegliere. Il punto non è comprare il software più famoso o costruire quello più originale: è capire quanta complessità deve davvero gestire la tua azienda.
Nei prossimi anni sarà sempre più facile creare software aziendale con l'AI. La vera selezione arriverà dopo. Non sarà tra chi riesce a costruirlo e chi no. Sarà tra chi riesce a mantenerlo, governarlo e farlo sopravvivere a chi lo ha costruito.
Se hai un caso specifico e vuoi confrontarti, scrivimi. Per altri contenuti su CRM, AI e processi commerciali puoi anche iscriverti alla newsletter di Merita.
Ecco i CRM da provare:
- PIPEDRIVE
- NOCRM
- SALESFORCE
- HUBSPOT
- MONDAY
- YDEA
Puoi costruire un prototipo o uno strumento semplice anche senza essere uno sviluppatore. Per mettere in produzione un CRM aziendale servono però competenze su processi, dati, sicurezza, integrazioni e manutenzione. Il fatto che il codice venga generato non elimina la necessità di saperlo valutare.
Può esserlo, ma dipende da come viene progettato e configurato. Vanno verificati almeno autenticazione, permessi lato server, gestione delle chiavi, backup, ripristino, audit log e revoca degli accessi.
Esistono piani gratuiti e CRM open source senza costo di licenza. Restano il tempo di configurazione, l'eventuale hosting, la manutenzione, la formazione, le integrazioni e la sicurezza. “Gratis” descrive quindi il prezzo di una parte del sistema, non necessariamente il suo costo totale.
Soprattutto quando devi validare un processo, creare un prototipo, automatizzare un'attività a basso rischio o servire un piccolo gruppo con esigenze semplici. All'aumentare di utenti, dati sensibili e integrazioni, cresce la necessità di una piattaforma strutturata e di una governance chiara.
