Quando la tua app creata con l'IA supera la sua prima versione: refactoring o riscrittura?

Hai pubblicato qualcosa. Gli utenti l’hanno adorato. Ora hai dieci utenti, e vogliono funzionalità che non si adattano alla forma originale. Sei a un bivio: rattoppare l’app per adattarla al nuovo caso d’uso, o ammettere che la prima versione era un prototipo e costruirla bene. È la domanda che uccide più piccoli progetti di qualsiasi altra, perché non c’è una risposta tecnica — solo una risposta di business.

Il momento in cui ti rendi conto che l’app ha successo

La maggior parte delle app create con l’IA nasce come una cosa e ne diventa un’altra. Avevi costruito un modulo di accoglienza clienti per la tua attività di coaching; ora i clienti vogliono vedere gli appuntamenti passati e riprogrammarli da soli. Avevi costruito uno strumento di lead scoring; ora il tuo team commerciale vuole i riepiloghi esportati nel CRM. Avevi costruito un sistema di archiviazione; ora le persone vogliono collaborarci dentro.

Ogni richiesta è ragionevole. Ognuna allontana l’app un po’ di più da quello per cui era stata costruita. E a un certo punto — dopo sei mesi, o due, a volte due settimane — senti l’attrito. Tutto quello che aggiungi combatte contro le fondamenta. Le nuove funzionalità richiedono “ah, prima dobbiamo riorganizzare quella parte”. L’app rallenta. Ci vuole più tempo per cambiare le cose.

Quella sensazione è il tuo segnale per riflettere se questa è ancora la stessa app, oppure se l’hai superata.

Cosa ti dà e cosa ti costa il refactoring

Fare refactoring significa mantenere la stessa app, ma ripulirla così da poterci costruire sopra di più. Chiedi al tuo creatore con IA di riorganizzare il codice, di scomporre un flusso di lavoro troppo complicato, o di ridisegnare una schermata diventata un ripostiglio di funzionalità. Ci vogliono poche ore. Non aggiunge nuove funzionalità. Rende solo più solide le fondamenta.

Quando il refactoring funziona, è magia. Avevi la sensazione di combattere contro l’app; all’improvviso non più. Aggiungi tre nuove funzionalità in una settimana che prima ne avrebbero richieste tre.

Ma il refactoring funziona solo se il problema è la forma di ciò che hai. Se avevi costruito un modulo di accoglienza e gli utenti vogliono un modulo di accoglienza più veloce, fare il refactoring della parte lenta è un pomeriggio. Se vogliono un modulo di accoglienza che sia più veloce e memorizzi lo storico, è ancora una sola app, e il refactoring potrebbe aiutare. Ma se vogliono lo storico degli appuntamenti, le integrazioni con il calendario, i promemoria via SMS e la fatturazione, non stai più costruendo un modulo di accoglienza migliore — stai costruendo il back office di un’attività di coaching. Quello è un prodotto diverso.

Cosa ti dà e cosa ti costa la riscrittura

Riscrivere significa: hai capito cosa dovrebbe davvero essere l’app, e la costruirai da zero con quella consapevolezza. Non butti via la prima versione — i tuoi utenti ci dipendono ancora. Ma costruisci un’app nuova partendo dalle fondamenta, guidato da ciò che la vecchia ti ha insegnato, e poi ci migri sopra gli utenti quando è pronta.

Riscrivere sembra uno spreco. Avevi costruito qualcosa, e adesso lo stai costruendo di nuovo. Questo è il costo psicologico. Il costo pratico è il tempo: passerai dai due ai quattro mesi sulla nuova versione prima che sia pronta per migrare gli utenti. Non avrai più la prima versione come stampella — vai avanti senza rete.

Ma la riscrittura ti dà una cosa che nient’altro può darti: libertà. La nuova app non è vincolata dalla forma della vecchia. Se l’originale era un semplice modulo e la nuova dovrebbe essere un back office completo, la progetti così fin dall’inizio. Se le prestazioni contano, le progetti per quello. Se contano la sicurezza, le integrazioni o i flussi di lavoro, non sono aggiunte posticce — sono fondamentali.

Le app che hanno successo dopo una ricostruzione tendono a riuscirci perché la comprensione del problema da parte del team si era allontanata così tanto dal codice originale che provare a rattoppare era come indossare vestiti che non calzano del tutto. Riscrivere significava costruire per loro stessi.

Tre domande per scegliere tra le due

Domanda 1: la forma di base è ancora quella giusta?

La tua forma di base è quel paio di flussi di lavoro principali che definiscono l’app. Per un modulo di accoglienza di coaching, è “il cliente compila l’accoglienza, il coach la rivede, il coach fissa l’appuntamento”. Se stai aggiungendo flussi di lavoro diversi — fatturazione, gestione del calendario, messaggistica con i clienti — non stai estendendo il nucleo, stai imbullonando funzionalità laterali. È un segnale che stai costruendo un prodotto diverso, il che significa riscrivere.

Se stai aggiungendo varianti dello stesso nucleo — “accoglienza per singoli, accoglienza per team, accoglienza con campi personalizzati” — è ancora la stessa app. Fanne il refactoring ed estendila.

Domanda 2: se fai il refactoring oggi, quanti mesi mancano prima che l’attrito torni a colpire?

Sii onesto. Se l’attrito sparisce per sei mesi, il refactoring è la mossa giusta. Se tornerà a far male tra due mesi perché il problema non è la forma del codice ma le fondamenta stesse, allora riscrivere ti risparmia il falso risparmio di rattoppare due volte. Chiedi al tuo creatore con IA: “Se ripuliamo questo, quanto manca prima di doverlo rifare?” Se la risposta è “probabilmente non molto”, è ora di ricostruire.

Domanda 3: da cosa dipendono davvero i tuoi utenti?

Se hai tre utenti attivi sulla v1 e stai pensando di ricostruire, puoi spostarli in un giorno o due. Se hai cinquanta utenti che dipendono in produzione dall’app attuale, riscrivere significa che devi tenere entrambe le versioni funzionanti per mesi, il che è una sua forma di dolore.

Il percorso che di solito funziona

La maggior parte dei founder che ricostruiscono con successo lo fa in parallelo: tengono in funzione l’app originale e usano la banda residua per costruire la nuova. Quando la nuova ha la stessa parità di funzionalità della vecchia, dedicano una settimana a migrare dati e utenti, e hanno finito.

Il percorso che di solito non funziona: refactoring, refactoring, refactoring, finché dopo tre refactoring ti rendi conto che l’architettura è ancora sbagliata, e ormai sei troppo coinvolto nella versione “vecchia” per ammetterlo e ricominciare da capo.

Il momento giusto per decidere

La prossima volta che senti l’attrito, chiediti: “Sto facendo in modo che questa app faccia meglio ciò per cui era nata? Oppure le sto chiedendo di essere qualcosa per cui non è mai stata progettata?” Se è la prima, fai il refactoring. Se è la seconda, non c’è vergogna nel costruire la cosa che avrebbe dovuto essere fin dall’inizio. La maggior parte delle app di successo è alla versione 2 del nucleo, non alla versione 1.