Revisione del software creato con l'IA.
Hai costruito qualcosa con Lovable, Replit o uno strumento simile, oppure hai ereditato del codice da qualcun altro, e adesso vorresti aprirlo ai clienti veri. Guardo cosa c'è dietro la schermata e ti dico se regge.
Funziona, e non sai se regge.
Hai un software che gira. Magari lo hai costruito in fretta, magari con l'aiuto di un modello di IA, e fa esattamente quello che volevi. Il dubbio arriva dopo, quando si tratta di metterci davanti i clienti veri, e di solito prende la forma di una domanda semplice. Se lo apro a tutti, mi si rompe in mano?
È la domanda giusta, e non ha una risposta che si possa dare guardando il software da fuori. Si risponde aprendo il codice.
Quello che vedi è la schermata.
Se il tuo software l'hai costruito con Lovable, con Replit o con un altro strumento che scrive il codice per te, hai fatto una cosa sensata. Hai visto l'idea in piedi in giorni invece che in mesi, hai messo a fuoco i flussi provandoli davvero, e hai speso una frazione di quello che costa farsi costruire un prototipo su misura. Per arrivare fin qui, quegli strumenti funzionano.
Lavoro con l'IA anche io, tutti i giorni. La differenza non la fa lo strumento, la fa quello che succede dopo che il modello ha scritto. Chi fa questo mestiere capisce cosa sta facendo il modello, lo guida, lo corregge e si prende la responsabilità di quello che consegna. Chi non scrive codice quel passaggio non lo può fare da solo. Fin qui non serviva, per aprirlo ai clienti sì.
La parte scomoda è che da fuori non si vede se quel passaggio è stato fatto. L'unico pezzo del software che puoi giudicare da solo è l'interfaccia, ed è proprio il pezzo che questi strumenti fanno meglio. Tutto quello che vedi ti dice che il lavoro è finito. Ma quello che decide se il software regge sta sotto, dove da fuori non si vede. Chi può entrare e cosa può fare, dove finiscono le chiavi, cosa succede quando un servizio esterno non risponde, come sono trattati i dati delle persone, che con i clienti veri diventa anche una questione di privacy.
Non do per scontato che ci sia qualcosa che non va solo perché è stata usata l'IA. Lo cerco nel codice, e nel rapporto finisce quello che trovo, compreso quello che invece va bene.
Quello che manca per aprirlo ai clienti è una persona del mestiere che apra il codice, guardi sotto l'interfaccia e ti dica per iscritto su cosa puoi contare. È il lavoro descritto in questa pagina.
Vale anche se il tuo software non l'ha scritto un modello. Chi ha ereditato del codice da un fornitore o da una persona che non c'è più è nello stesso punto, un software che gira e nessun modo di sapere quanto regge. I controlli sono gli stessi.
Otto domande, sempre le stesse.
Sono l'indice del rapporto che ricevi. Il documento le attraversa tutte e otto, anche dove la risposta è che va bene, perché sapere cosa è stato guardato e non ha problemi vale quanto sapere cosa ne ha.
- 01
Si rimette in piedi da zero?
Build riproducibile da zero, dipendenze e versioni bloccate, istruzioni che funzionano. È la prima perché tutto il resto si verifica solo se il software si rimette in piedi da zero.
- 02
Chi entra, e cosa può fare?
Autenticazione e permessi, e quali pagine o chiamate rispondono anche senza credenziali. Non mi fermo a leggere il codice che dovrebbe proteggerle, provo a passare.
- 03
I dati stanno insieme?
Schema, integrità, migrazioni. Poi guardo se i backup che risultano attivi esistono davvero e se si riescono a rimettere.
- 04
Ci sono chiavi in chiaro?
Password e chiavi di accesso dentro il codice, dentro il pacchetto che arriva al browser, o nello storico di git, dove restano anche dopo che qualcuno le ha tolte dall'ultima versione.
- 05
Cosa succede quando qualcosa fallisce?
Cosa vede la persona che stava usando il software, e soprattutto cosa resta a metà. Un ordine registrato e non pagato, un pagamento senza ordine, una email partita due volte.
- 06
Regge il carico che ti aspetti?
Ricerche senza indice, letture ripetute dentro un ciclo, chiamate in fila che potevano andare in parallelo. Con dieci clienti di prova non si vedono, con diecimila fermano tutto.
- 07
Si può cambiare senza rompere altro?
Quali test esistono e cosa coprono davvero. Poi i punti dove tocchi una cosa e ne cadono altre tre, perché è lì che si ferma lo sviluppo futuro.
- 08
Di chi sono le dipendenze e gli account?
Licenze di quello che il software usa, e a nome di chi sono intestati i servizi esterni. Capita di scoprire che l'infrastruttura è sulla carta di credito di un fornitore che non lavora più con te.
Due gradini, e il primo non si paga due volte.
Si può cominciare in piccolo, con il check-up e le sue tre domande, oppure andare diretti alla revisione. Se cominci dal check-up e la revisione parte entro 30 giorni, il check-up lo scalo, perché è il primo pezzo dello stesso lavoro.
Check-up del software
300 euro
Prezzo fisso. Tre ore e mezza sul codice, tre domande e basta. Si rimette in piedi da zero seguendo le istruzioni che ci sono? Ci sono chiavi o segreti in chiaro, nel codice o nello storico? C'è qualcosa che espone i dati a chi non dovrebbe vederli?
Consegno una pagina, con il verdetto e le cose da fermare subito, se ci sono. Se esce qualcosa che tre domande non bastano a valutare, te lo scrivo e ti dico cosa servirebbe per andare a fondo. Mi basta un accesso in sola lettura al repository.
Revisione
da 1.500 euro
Dalle 12 alle 20 ore fra lettura, verifiche e scrittura. Alla fine un rapporto da 12 a 25 pagine in italiano, leggibile anche da chi non scrive codice. La prima pagina contiene il verdetto e si regge da sola. Se leggi solo quella, sai come stai.
Ogni rilievo ha tre parti, cioè cosa ho visto con il riferimento al file e alla riga, cosa può succedere, quanto costa sistemarlo in giornate. I rilievi sono in ordine di conseguenze, non di gravità teorica. In fondo c'è una delle tre conclusioni dichiarate prima di cominciare: si va avanti così, si rifà un pezzo, non conviene tenerlo. Poi un'ora insieme per leggere il rapporto.
Per la revisione mi servono la lettura del repository con il suo storico, un accesso in sola lettura a un ambiente che gira, le variabili d'ambiente con i valori oscurati, i log degli ultimi 30 giorni, con i dati delle persone oscurati, e una persona che risponda a domande scritte, in due giri. Per il check-up basta il repository.
Non mi servono le credenziali di produzione con permessi di scrittura, e non mi servono i dati veri delle persone. Se il database contiene dati personali si lavora sullo schema o su un estratto anonimizzato.
Il confine, detto prima.
Questa è una revisione di ingegneria. I problemi di sicurezza che nascono da come il software è costruito sono quelli che cerca, una chiave lasciata in chiaro, una pagina raggiungibile senza credenziali, un dato esposto a chi non dovrebbe vederlo. Un penetration test completo è un altro tipo di lavoro, con metodi e tempi suoi, e nel prezzo della revisione non ci sta. Se dal rapporto esce che ti serve, si quota a parte e me ne occupo io.
Di questioni di legge invece non me ne occupo. La revisione ti mette in mano i fatti tecnici, dove stanno i dati, chi li può vedere, come sono protetti. Dire se sei a norma o preparare una valutazione d'impatto è il mestiere di un avvocato o di un consulente privacy, e il rapporto è scritto perché ci possano lavorare sopra anche loro.
Fuori dal rapporto restano anche queste cose.
- La correzione dei difetti trovati. Ha sempre un preventivo separato, che arriva dopo la consegna del rapporto.
- La revisione del design e dell'esperienza d'uso.
- La qualità delle risposte dei modelli, se il prodotto usa l'IA mentre gira.
Quanto costa far rivedere un software.
a partire da
1.500 euro
È il prezzo della revisione completa, verifiche e ora di lettura comprese, dentro un perimetro chiuso:
- Un applicativo.
- Un repository. Un monorepo va bene, se si guarda una sola app.
- Fino a 15.000 righe di codice applicativo, escluse dipendenze, file generati e migrazioni.
- Due linguaggi principali.
- Un ambiente che gira, meglio se di collaudo.
- Tre servizi esterni critici, database compreso.
Sopra il perimetro si quota a parte. La misura si fa prima di partire, contando le righe e i servizi invece che a occhio, e toglie di mezzo la sorpresa a metà lavoro. Se preferisci cominciare con un impegno più piccolo, c'è il check-up, 300 euro a prezzo fisso.
La correzione di quello che trovo ha sempre un preventivo separato.
Quello che mi chiedono prima.
Sì, in due tempi. Prima la revisione, che dice cosa c'è da sistemare e quanto costa in giornate, poi la correzione, che ha un preventivo separato fatto sul rapporto. Strumenti come Lovable e Replit sono fatti per portarti in fretta da un'idea a un'applicazione che si usa, e quel lavoro lo fanno bene. La revisione guarda quello che sta sotto, e la responsabilità del giudizio me la prendo io. Vale lo stesso per chi usa strumenti più tecnici, Cursor, Antigravity, Codex o Claude Code, e vale anche se il codice te lo ha scritto una persona.
Per il check-up basta un accesso in sola lettura al repository, storico compreso, perché una chiave tolta dall'ultima versione resta lì dentro e senza guardarci non si trova. Per la revisione servono anche un ambiente che gira, le variabili d'ambiente con i valori oscurati, i log degli ultimi 30 giorni e una persona che risponda a domande scritte.
Non te li chiedo. Se il database contiene dati personali si lavora sullo schema o su un estratto anonimizzato, e anche i log arrivano con i dati delle persone oscurati. Non servono nemmeno le credenziali di produzione con permessi di scrittura, e i segreti veri non me li mandi, perché le variabili d'ambiente arrivano con i valori nascosti. Quello che esce dalla tua azienda resta lo stretto necessario per fare il lavoro.
Il check-up costa 300 euro a prezzo fisso. Sono tre ore e mezza sul codice e tre domande, quelle che dicono se c'è qualcosa di rotto adesso, e alla fine una pagina di verdetto. La revisione parte da 1.500 euro. Dura dalle 12 alle 20 ore, attraversa tutte e otto le domande e consegna un rapporto da 12 a 25 pagine, più un'ora insieme per leggerlo. Se la revisione parte entro 30 giorni, il check-up si scala.
Si quota a parte. Dentro 1.500 euro stanno un applicativo, un repository, fino a 15.000 righe di codice applicativo, due linguaggi principali, un ambiente e tre servizi esterni. La misura si fa prima di partire, contando le righe e i servizi.
No, è una revisione di ingegneria, e una parte dei controlli guarda proprio la sicurezza. I problemi che nascono da come il software è costruito sono quelli che cerca, una chiave in chiaro, una pagina raggiungibile senza credenziali, un dato esposto. Un penetration test completo non sta nel prezzo della revisione, e se dal rapporto esce che ti serve si quota a parte e me ne occupo io. Il verdetto che il rapporto non può darti è quello legale, perché dire se sei a norma spetta a un avvocato o a un consulente privacy, e il rapporto gli dà la base tecnica per farlo.
È scritto perché serva. Ogni rilievo dice cosa ho visto, con il riferimento al file e alla riga, cosa può succedere e quanto costa sistemarlo in giornate. Il documento è tuo e ci può lavorare chiunque, io o un altro.
No. L'intervento ha sempre un preventivo separato, e il prezzo della revisione non viene sottratto da quel preventivo. Qui il prodotto è il giudizio, e se costasse meno a chi poi mi affida i lavori non sarebbe più indipendente. Il check-up invece si scala, se la revisione parte entro 30 giorni, perché è il primo pezzo dello stesso lavoro fatto dalla stessa persona.
Te lo dico. Le conclusioni possibili sono tre e sono dichiarate prima di cominciare. La prima, si va avanti così, con gli interventi che elenco se ce ne sono. La seconda, si rifà un pezzo, e dico quale. La terza, non conviene tenerlo. È la più rara e la più scomoda da scrivere, e un rapporto deve poterci arrivare.
Se il rapporto dice che un pezzo va rifatto, quel pezzo si costruisce dentro un progetto su misura. Se invece quello che ti manca è qualcuno che segua le scelte tecniche nel tempo, esiste la direzione tecnica. Tutti i modi in cui posso aiutarti stanno nella pagina Servizi.
Scrivimi due righe su cosa hai costruito e con cosa lo hai costruito. Ti rispondo io, e se il perimetro non è chiaro lo misuriamo prima, così il preventivo è quello giusto.