Quando un prodotto diventa due: come dividere l'app creata con l'IA senza ricominciare da capo

Hai iniziato con un’idea sola. L’hai descritta al tuo creatore di app con IA, l’hai visto generare le schermate, hai sistemato le sbavature e hai pubblicato qualcosa di reale. Le persone hanno iniziato a usarlo. E poi, lentamente all’inizio, è emerso uno schema nei feedback: metà dei tuoi utenti voleva una cosa, l’altra metà ne voleva un’altra. Non si contendevano la stessa funzionalità. Stavano chiedendo due prodotti diversi.

Questo è il momento in cui molti founder vanno nel panico e iniziano un secondo progetto da zero. Non dovrebbero. C’è un modo più pulito di dividere un’app con IA quando il tuo unico prodotto si rivela essere due, e di solito conserva gran parte di ciò che hai già costruito. Questo articolo parla di come riconoscere la divisione, quando farla e le tre forme che la divisione tende ad assumere.

Come scopri di avere due prodotti

Il segnale non assomiglia quasi mai a una richiesta di funzionalità. Assomiglia ad attrito.

Un’app per la produttività che ho visto attraversare tutto questo aveva una storia chiara. Era venduta come “agenda personale”. Gli utenti hanno iniziato a presentarsi in due varianti. Un gruppo la usava per organizzare la propria settimana e la trattava come un taccuino privato. L’altro gruppo gestiva piccoli team e voleva assegnare cose ad altre persone. Erano entrambi abbastanza contenti da continuare a usare lo stesso prodotto, ma ogni rilascio faceva contento un gruppo e seccava l’altro. Il team pensava di avere un problema di prioritizzazione delle funzionalità. In realtà aveva un problema di brand. Avevano un’app personale e un’app per team che condividevano un’unica base di codice, un’unica home page e un’unica pagina dei prezzi.

Capirai di aver varcato quella soglia quando uno di questi inizia a essere vero:

La tua landing page deve seppellire il proprio pitch reale dietro un linguaggio generico, perché due pubblici non crederanno alle stesse parole.
Ogni nuova funzionalità ha un “ma per l’altro tipo di utente dovrebbe funzionare in modo diverso”.
Le tue risposte di supporto iniziano a ramificarsi: “se la usi per te stesso…” contro “se stai gestendo un team…”.
Un numero non trascurabile di utenti tiene due account separati per tenere distinte le due modalità.

Se ne stai vedendo due o più, non hai un problema di funzionalità. Hai una divisione di prodotto in attesa di avvenire.

Le tre forme di una divisione

Non devi scegliere una forma fin dal primo giorno. Di solito puoi provare prima la più leggera e poi salire di livello. Ma è utile conoscere il menù prima di iniziare a descriverla al tuo creatore di app con IA, perché le parole che usi daranno forma a ciò che viene generato.

Forma 1: un’app, due porte

La versione più leggera. Mantieni un’unica base di codice. Aggiungi una domanda al primo avvio — “Sei qui per te stesso o per un team?” — e usi la risposta per mostrare un diverso insieme di pagine e una diversa navigazione. Stesso archivio dati. Stesso login. Stessa fatturazione. Solo una superficie diversa.

La maggior parte dei creatori di app con IA gestisce bene tutto questo se lo descrivi come un‘“app a due modalità”. La cosa a cui fare attenzione è che le due modalità non dovrebbero condividere schermate con mostra-e-nascondi condizionali sparsi ovunque. Si finisce per avere un’unica app disordinata che finge di essere due. Di’ al builder che le due porte sono separate: home page diverse, pagine delle impostazioni diverse, stati vuoti diversi. Le poche schermate che effettivamente si sovrappongono (impostazioni dell’account, fatturazione) possono essere condivise.

Quando funziona: quando i due pubblici vogliono un inquadramento diverso ma gli stessi oggetti sottostanti. L’esempio agenda-contro-team rientra qui. La cosa che stai programmando è comunque un’attività; cambiano solo le regole su assegnazione, condivisione e notifica.

Quando non funziona: quando i due pubblici si aspettano oggetti completamente diversi. Un “portale clienti” e uno “strumento di amministrazione interno” non hanno quasi nessuna sovrapposizione, anche se sembrano riguardare lo stesso business.

Forma 2: due app, un solo back end

La forma intermedia. Dividi la parte frontale del prodotto in due app separate — due URL, due landing page, due flussi di onboarding, due tabelle di prezzi — ma entrambe leggono dallo stesso database sottostante. Un cliente può avere un account su entrambe. Un amministratore può vedere i dati di entrambe.

È quello che abbiamo fatto di recente nell’azienda che gestisce questo blog. Avevamo un’unica app che cercava di servire due pubblici: ingegneri che valutavano la nostra piattaforma di agenti e builder che usavano il nostro creatore di app con IA. Stesso backend, stessa autenticazione, stesso database — ma il frontend aveva messo su due teste, e il messaggio era confuso. L’abbiamo diviso in due app frontend, una per ciascun pubblico. Il backend è rimasto esattamente lo stesso.

Questa forma è la risposta giusta quando:

I due pubblici comprano per ragioni diverse.
Sarebbero confusi o disorientati dai testi di marketing dell’altro pubblico.
I dati che gli interessano hanno per lo più la stessa forma, ma vengono inquadrati in modo diverso.
Non vuoi mantenere due database o due configurazioni di fatturazione.

Di’ al tuo creatore di app con IA che vuoi una “seconda app frontend che condivide l’API esistente”. La maggior parte dei creatori di app con IA moderni può impostare un progetto gemello e puntarlo al tuo backend esistente. La trappola da evitare: copiare e incollare i componenti della prima app pari pari e poi modificare per sempre entrambe le copie. Chiedi al builder di estrarre le parti condivise (schermate di autenticazione, widget di form comuni) in una piccola libreria che entrambe le app usano. Ti risparmierai mesi di correzioni doppie in futuro.

Forma 3: due app, due back end

La divisione più pesante. Hai davvero due prodotti. Non condividono dati, non condividono utenti e non dovrebbero condividere una roadmap. La mossa giusta è separarli completamente: basi di codice separate, database separati, domini separati.

Questa è la mossa giusta meno spesso di quanto la gente pensi. È allettante perché sembra pulita. La realtà è che due app completamente separate significano due di tutto da mandare avanti — due pipeline di deploy, due turni di reperibilità, due integrazioni di fatturazione, due documentazioni di aiuto. Non ricorrere a questa forma a meno che i prodotti non siano genuinamente privi di sovrapposizioni. Un buon test: se un utente del prodotto A non sarebbe mai un utente del prodotto B, probabilmente ti serve davvero la Forma 3. Se la maggior parte dei tuoi utenti potrebbe plausibilmente volerli entrambi, quasi sicuramente vuoi la Forma 2.

Quando lo fai con un creatore di app con IA, la mossa più facile è copiare il tuo progetto esistente come punto di partenza per il secondo, e poi chiedere al builder di rimuovere le funzionalità che non c’entrano e aggiungere quelle che servono. Non iniziare il secondo progetto da una tela bianca. Hai già imparato molto costruendo il primo, e il creatore di app con IA coglierà quel contesto se glielo permetti.

Cosa fare prima di dividere qualsiasi cosa

Prima di descrivere la divisione al tuo creatore di app con IA, fai tre piccole cose. Valgono più di quanto sembri.

Primo, scrivi la nuova home page per ciascun lato. Due paragrafi ognuna. Il pitch, il pubblico, l’unica cosa che vuoi che facciano. Se non riesci a scrivere due home page diverse, in realtà non hai ancora due prodotti — hai solo due segmenti di un unico prodotto, e dovresti risolverlo con il messaggio, non con l’architettura.

Secondo, elenca quali schermate sono condivise e quali no. Sii onesto. “Il login è condiviso. L’onboarding è diverso. La dashboard è diversa. Le impostazioni sono per lo più condivise. La fatturazione è condivisa.” Questo elenco diventa il brief che consegni al creatore di app con IA. Risparmia un sacco di avanti e indietro.

Terzo, decidi cosa è uguale sotto il cofano. Stessi utenti? Stessi dati? Stessi pagamenti? Ogni “sì” ti spinge verso la Forma 1 o 2. Ogni “no” ti spinge verso la Forma 3. Non c’è una risposta giusta, solo la risposta che corrisponde a come funziona davvero il tuo prodotto.

Cosa cambia dopo la divisione

Due cose diventano più facili e una cosa diventa più difficile.

Il marketing diventa più facile. Ogni app ottiene il proprio pitch chiaro. Ogni landing page può parlare a un solo pubblico senza tergiversare. Il tuo tasso di conversione di solito sale almeno su un lato, a volte su entrambi.

L’onboarding diventa più facile. Un utente alle prime armi atterra su una pagina che parla di lui, non su una pagina che cerca di parlare a tutti.

Ciò che diventa più difficile è tenere sincronizzate le parti condivise. Se correggi un bug nel flusso di login, vuoi che sia corretto in entrambe le app. Se cambi l’aspetto della schermata di fatturazione, vuoi che entrambe le app lo riflettano. La disciplina che ti serve — e questo è vero sia che tu stia facendo vibe coding con un creatore di app con IA, sia che tu stia costruendo con un team di sviluppatori umani — è mantenere le parti condivise genuinamente condivise. Non duplicare. Non biforcare. O estrai la schermata condivisa in una piccola libreria che entrambe le app usano, oppure accetti di avere due app davvero separate e te ne assumi la responsabilità.

Una piccola domanda per chiudere

Se facessi leggere il pitch della tua app attuale a cinque sconosciuti e ognuno la descrivesse in modo diverso — ma in due gruppi distinti — probabilmente stai già convivendo con la divisione. L’unica domanda è se continuare a pagare la tassa di un prodotto confuso, oppure fare il lavoro di essere onesto sul fatto di essere due.

Non devi decidere oggi. Ma la prossima volta che il tuo creatore di app con IA ti chiede “cosa dovrei costruire dopo?”, considera che la risposta più utile potrebbe non essere una nuova funzionalità. Potrebbe essere una nuova porta d’ingresso.

Se questo ti ha colpito, potrebbe piacerti anche il nostro pezzo precedente su costruire per il tuo team contro costruire per i clienti: stesso tipo di decisione, un passo prima nella vita del tuo prodotto.