Când un produs devine două: cum îți împarți aplicația construită cu IA fără să o iei de la zero
Aplicația ta construită cu IA a pornit ca un singur produs. Apoi ți-ai dat seama că, de fapt, erau două. Iată cum împarți curat o aplicație cu IA — fără să renunți la ceea ce ai lansat deja.
Ai pornit de la o singură idee. Ai descris-o creatorului tău de aplicații cu IA, l-ai urmărit generând ecranele, ai șlefuit colțurile aspre și ai lansat ceva real. Oamenii au început să-l folosească. Și apoi, încet la început, în feedback a apărut un tipar: jumătate dintre utilizatorii tăi voiau un lucru, cealaltă jumătate voia altceva. Nu se certau pe aceeași funcție. Cereau două produse diferite.
Acesta e momentul în care mulți fondatori intră în panică și pornesc un al doilea proiect de la zero. N-ar trebui. Există o cale mai curată să împarți o aplicație cu IA atunci când produsul tău unic se dovedește a fi de fapt două — și de obicei păstrezi cea mai mare parte din ce ai construit deja. Articolul acesta e despre cum recunoști împărțirea, când să o faci și cele trei forme pe care le ia de obicei.
Cum afli că ai două produse
Semnalul aproape niciodată nu arată ca o cerere de funcție. Arată ca o frecare.
O aplicație de productivitate pe care am urmărit-o trecând prin asta avea o poveste clară. Era vândută ca un „planificator personal”. Utilizatorii au început să apară în două variante. Un grup o folosea ca să-și organizeze propria săptămână și o trata ca pe un carnețel privat. Celălalt grup conducea echipe mici și voia să atribuie sarcini altor oameni. Ambele grupuri erau destul de mulțumite cât să rămână cu același produs, dar fiecare lansare bucura un grup și enerva celălalt. Echipa credea că are o problemă de prioritizare a funcțiilor. De fapt avea o problemă de brand. Avea o aplicație personală și o aplicație de echipă care împărțeau o singură bază de cod, o singură pagină principală și o singură pagină de prețuri.
Vei ști că ai trecut linia atunci când unul dintre lucrurile astea devine adevărat:
- Pagina ta de prezentare e nevoită să-și ascundă pitch-ul real în spatele unui limbaj generic, pentru că două categorii de public nu vor crede aceleași cuvinte.
- Fiecare funcție nouă vine cu un „dar pentru celălalt tip de utilizator ar trebui să funcționeze altfel”.
- Răspunsurile tale de suport încep să se ramifice: „dacă o folosești pentru tine…” vs. „dacă administrezi o echipă…”.
- Un număr deloc neglijabil de utilizatori țin două conturi separate ca să mențină cele două moduri separate.
Dacă vezi două sau mai multe dintre acestea, nu ai o problemă de funcții. Ai o împărțire de produs care așteaptă să se întâmple.
Cele trei forme ale unei împărțiri
Nu trebuie să alegi o formă din prima zi. De obicei poți încerca mai întâi varianta cea mai ușoară și să escaladezi. Dar e util să cunoști meniul înainte să începi să i-o descrii creatorului tău cu IA, fiindcă vorbele pe care le folosești vor modela ce se generează.
Forma 1: O aplicație, două uși
Cea mai ușoară variantă. Păstrezi o singură bază de cod. Adaugi o întrebare la prima rulare — „Ești aici pentru tine sau pentru o echipă?” — și folosești răspunsul ca să afișezi un set diferit de pagini și o navigare diferită. Aceeași bază de date. Aceeași autentificare. Aceeași facturare. Doar o suprafață diferită.
Majoritatea creatoarelor de aplicații cu IA se descurcă bine cu asta dacă o descrii ca pe o „aplicație cu două moduri”. Lucrul de care să ții cont e ca cele două moduri să nu împartă ecrane cu afișări și ascunderi condiționate peste tot. Asta ajunge să arate ca o singură aplicație aglomerată care se preface că e două. Spune-i creatorului că cele două uși sunt separate — pagini principale diferite, pagini de setări diferite, stări goale diferite. Puținele ecrane care chiar se suprapun (setări de cont, facturare) pot fi comune.
Când funcționează: când cele două categorii de public vor o încadrare diferită, dar aceleași obiecte de bază. Exemplul planificator-versus-echipă se potrivește aici. Lucrul pe care îl programezi e tot o sarcină; doar regulile din jurul atribuirii, partajării și notificării se schimbă.
Când nu funcționează: când cele două categorii de public se așteaptă la obiecte complet diferite. Un „portal pentru clienți” și un „instrument intern de administrare” aproape nu se suprapun deloc, chiar dacă par să fie despre aceeași afacere.
Forma 2: Două aplicații, un singur backend
Forma de mijloc. Împarți fața produsului în două aplicații separate — două URL-uri, două pagini de prezentare, două fluxuri de onboarding, două tabele de prețuri — dar amândouă citesc din aceeași bază de date dedesubt. Un client poate avea cont pe amândouă. Un administrator poate vedea datele de pe amândouă.
Asta am făcut recent la compania care administrează acest blog. Aveam o singură aplicație care încerca să servească două categorii de public: ingineri care evaluau platforma noastră de agenți și creatori care foloseau creatorul nostru de aplicații cu IA. Același backend, aceeași autentificare, aceeași bază de date — dar frontend-ul crescuse două capete, iar mesajul era confuz. Am împărțit-o în două aplicații de frontend, câte una pentru fiecare public. Backend-ul a rămas exact la fel.
Forma asta e răspunsul corect atunci când:
- Cele două categorii de public cumpără din motive diferite.
- Ar fi confuzate sau respinse de mesajul de marketing al celuilalt public.
- Datele care le interesează au în mare aceeași formă, dar sunt prezentate diferit.
- Nu vrei să întreții două baze de date sau două configurații de facturare.
Spune-i creatorului tău cu IA că vrei „o a doua aplicație de frontend care folosește API-ul existent”. Majoritatea creatoarelor moderne cu IA pot construi un proiect-frate și îl pot îndrepta spre backend-ul tău existent. Capcana de evitat: să copiezi-lipești componentele primei aplicații cuvânt cu cuvânt și apoi să editezi ambele copii la nesfârșit. Cere-i creatorului să extragă părțile comune (ecrane de autentificare, widget-uri comune de formular) într-o mică bibliotecă pe care o folosesc ambele aplicații. Îți vei economisi luni de corecturi duplicate mai târziu.
Forma 3: Două aplicații, două backenduri
Împărțirea cea mai grea. Chiar ai două produse. Nu împart date, nu împart utilizatori și n-ar trebui să împartă un plan de dezvoltare. Mișcarea corectă e să le separi complet: baze de cod separate, baze de date separate, domenii separate.
Asta e mișcarea corectă mai rar decât cred oamenii. E tentantă fiindcă pare curată. Realitatea e că două aplicații complet separate înseamnă câte două din toate de ținut în funcțiune — două pipeline-uri de deploy, două ture de gardă, două integrări de facturare, două seturi de documentație de ajutor. Nu apela la forma asta dacă produsele nu se suprapun cu adevărat. Un test bun: dacă un utilizator al produsului A n-ar deveni niciodată utilizator al produsului B, probabil chiar ai nevoie de Forma 3. Dacă majoritatea utilizatorilor tăi ar putea în mod plauzibil să le vrea pe amândouă, aproape sigur vrei Forma 2.
Când faci asta cu un creator cu IA, cea mai simplă mișcare e să copiezi proiectul tău existent ca punct de plecare pentru al doilea, apoi să-i ceri creatorului să elimine funcțiile care nu-și au locul și să le adauge pe cele care da. Nu porni al doilea proiect de la o pânză goală. Ai învățat deja multe construind-o pe prima, iar creatorul cu IA va prelua contextul acela dacă îl lași.
Ce să faci înainte să împarți ceva
Înainte să-i descrii împărțirea creatorului tău cu IA, fă trei lucruri mici. Valorează mai mult decât sună.
În primul rând, scrie noua pagină principală pentru fiecare parte. Două paragrafe fiecare. Pitch-ul, publicul, singurul lucru pe care vrei să-l facă. Dacă nu poți scrie două pagini principale diferite, încă nu ai cu adevărat două produse — ai doar două segmente ale unui singur produs, iar asta o rezolvi cu mesajul, nu cu arhitectura.
În al doilea rând, enumeră ce ecrane sunt comune și ce ecrane nu. Fii sincer. „Autentificarea e comună. Onboarding-ul e diferit. Panoul de control e diferit. Setările sunt în mare parte comune. Facturarea e comună.” Lista asta devine brief-ul pe care i-l dai creatorului cu IA. Economisește o grămadă de dus-întors.
În al treilea rând, decide ce e la fel dedesubt. Aceiași utilizatori? Aceleași date? Aceleași plăți? Fiecare „da” te trage spre Forma 1 sau 2. Fiecare „nu” te trage spre Forma 3. Nu există un răspuns corect — doar răspunsul care se potrivește cu felul în care funcționează de fapt produsul tău.
Ce se schimbă după împărțire
Două lucruri devin mai ușoare și unul devine mai greu.
Marketingul devine mai ușor. Fiecare aplicație își primește propriul pitch clar. Fiecare pagină de prezentare poate vorbi cu un singur public, fără să dea din colț în colț. Rata ta de conversie de obicei crește pe cel puțin o parte, uneori pe amândouă.
Onboarding-ul devine mai ușor. Un utilizator nou aterizează pe o pagină care e despre el, nu pe o pagină care încearcă să fie despre toată lumea.
Ce devine mai greu e să ții părțile comune sincronizate. Dacă repari un bug în fluxul de autentificare, îl vrei reparat în ambele aplicații. Dacă schimbi cum arată ecranul de facturare, vrei ca ambele aplicații să reflecte asta. Disciplina de care ai nevoie — și asta e adevărat fie că faci vibe coding cu un creator cu IA, fie că construiești cu o echipă de dezvoltatori umani — e să ții părțile comune cu adevărat comune. Nu duplica. Nu bifurca. Ori extragi ecranul comun într-o mică bibliotecă pe care o folosesc ambele aplicații, ori accepți că ai două aplicații cu adevărat separate și-ți asumi asta.
O mică întrebare de încheiere
Dacă ai trece pitch-ul aplicației tale actuale prin fața a cinci străini și fiecare l-ar descrie altfel — dar în două categorii distincte — probabil că trăiești deja cu împărțirea. Singura întrebare e dacă tot plătești taxa unui produs confuz sau faci efortul de a fi sincer cu privire la faptul că ești două.
Nu trebuie să decizi azi. Dar data viitoare când creatorul tău de aplicații cu IA întreabă „ce să construiesc în continuare?”, gândește-te că răspunsul cel mai util s-ar putea să nu fie o funcție nouă. S-ar putea să fie o nouă ușă de intrare.
Dacă ți-a rezonat, s-ar putea să-ți placă și articolul nostru anterior despre a construi pentru echipa ta vs. a construi pentru clienți — același tip de decizie, cu un pas mai devreme în viața produsului tău.