Gdy jeden produkt staje się dwoma: jak podzielić aplikację zbudowaną z AI bez zaczynania od zera
Twoja aplikacja zbudowana z AI zaczynała jako jeden produkt. Potem zorientowałeś się, że potajemnie była dwoma. Oto jak czysto podzielić aplikację z AI — bez porzucania tego, co już wypuściłeś.
Zacząłeś od jednego pomysłu. Opisałeś go swojemu kreatorowi aplikacji z AI, patrzyłeś, jak generuje ekrany, dopracowałeś chropowate krawędzie i wypuściłeś coś prawdziwego. Ludzie zaczęli z tego korzystać. A potem, najpierw powoli, w opiniach pojawił się pewien wzorzec: połowa Twoich użytkowników chciała jednego, druga połowa czegoś innego. Nie kłócili się o tę samą funkcję. Prosili o dwa różne produkty.
To moment, w którym wielu founderów wpada w panikę i zaczyna drugi projekt od zera. Nie powinni. Istnieje czystszy sposób, by podzielić aplikację z AI, gdy Twój jeden produkt okazuje się dwoma — i zwykle zachowuje większość tego, co już zbudowałeś. Ten wpis jest o tym, jak rozpoznać podział, kiedy go przeprowadzić i jakie trzy kształty zwykle przyjmuje.
Jak rozpoznać, że masz dwa produkty
Sygnał prawie nigdy nie wygląda jak prośba o funkcję. Wygląda jak tarcie.
Aplikacja do produktywności, której przez to przejście obserwowałem, miała wyraźną historię. Była sprzedawana jako „osobisty planer”. Użytkownicy zaczęli pojawiać się w dwóch odmianach. Jedna grupa używała jej do planowania własnego tygodnia i traktowała ją jak prywatny notatnik. Druga grupa prowadziła małe zespoły i chciała przydzielać zadania innym osobom. Obie były na tyle zadowolone, by dalej korzystać z tego samego produktu, ale każda aktualizacja cieszyła jedną grupę, a irytowała drugą. Zespół myślał, że ma problem z priorytetyzacją funkcji. Tak naprawdę miał problem z marką. Mieli aplikację osobistą i aplikację zespołową dzielące jedną bazę kodu, jedną stronę główną i jedną stronę z cennikiem.
Poznasz, że przekroczyłeś tę granicę, gdy jedno z poniższych zacznie być prawdą:
- Twoja landing page musi chować swój prawdziwy przekaz za ogólnikami, bo dwie grupy odbiorców nie uwierzą tym samym słowom.
- Każda nowa funkcja ma zastrzeżenie w stylu „ale dla drugiego typu użytkownika powinno to działać inaczej”.
- Twoje odpowiedzi dla wsparcia zaczynają się rozgałęziać: „jeśli używasz tego dla siebie…” kontra „jeśli zarządzasz zespołem…”.
- Niemała liczba użytkowników trzyma dwa osobne konta, żeby oddzielić od siebie te dwa tryby.
Jeśli widzisz dwa lub więcej z tych objawów, nie masz problemu z funkcjami. Masz podział produktu czekający, żeby się wydarzyć.
Trzy kształty podziału
Nie musisz wybierać kształtu pierwszego dnia. Zwykle możesz najpierw spróbować najlżejszego i eskalować. Ale warto znać menu, zanim zaczniesz to opisywać swojemu kreatorowi z AI, bo słowa, których użyjesz, ukształtują to, co zostanie wygenerowane.
Kształt 1: Jedna aplikacja, dwoje drzwi
Najlżejsza wersja. Zachowujesz jedną bazę kodu. Dodajesz pytanie przy pierwszym uruchomieniu — „Jesteś tu dla siebie czy dla zespołu?” — i na podstawie odpowiedzi pokazujesz inny zestaw stron i inną nawigację. Ta sama baza danych. To samo logowanie. To samo rozliczanie. Po prostu inna powierzchnia.
Większość kreatorów aplikacji z AI dobrze to ogarnia, jeśli opiszesz to jako „aplikację dwutrybową”. Trzeba uważać, żeby oba tryby nie współdzieliły ekranów z warunkowym pokazywaniem i ukrywaniem wszędzie. To kończy się jako jedna zagracona aplikacja udająca dwie. Powiedz kreatorowi, że dwoje drzwi jest osobnych — inne strony główne, inne strony ustawień, inne stany puste. Te nieliczne ekrany, które faktycznie się pokrywają (ustawienia konta, rozliczanie), mogą być wspólne.
Kiedy to działa: gdy obie grupy odbiorców chcą innego ujęcia, ale tych samych obiektów pod spodem. Przykład planer kontra zespół tu pasuje. To, co planujesz, wciąż jest zadaniem; zmieniają się tylko reguły wokół przydzielania, udostępniania i powiadamiania.
Kiedy to nie działa: gdy obie grupy odbiorców oczekują zupełnie innych obiektów. „Portal klienta” i „wewnętrzne narzędzie administracyjne” prawie się nie pokrywają, nawet jeśli wyglądają, jakby dotyczyły tego samego biznesu.
Kształt 2: Dwie aplikacje, jeden backend
Środkowy kształt. Dzielisz front produktu na dwie osobne aplikacje — dwa adresy URL, dwie landing page, dwa procesy wdrożenia, dwie tabele cenowe — ale obie czytają z tej samej bazy danych pod spodem. Klient może mieć konto w obu. Administrator może widzieć dane z obu.
To właśnie zrobiliśmy niedawno w firmie, która prowadzi tego bloga. Mieliśmy jedną aplikację próbującą obsługiwać dwie grupy odbiorców: inżynierów oceniających naszą platformę agentów oraz osoby budujące za pomocą naszego kreatora aplikacji z AI. Ten sam backend, to samo uwierzytelnianie, ta sama baza danych — ale frontend wyhodował dwie głowy, a przekaz był pomieszany. Podzieliliśmy go na dwie aplikacje frontendowe, po jednej dla każdej grupy. Backend pozostał dokładnie taki sam.
Ten kształt jest właściwą odpowiedzią, gdy:
- Obie grupy odbiorców kupują z różnych powodów.
- Zmyliłaby je lub zniechęciła marketingowa treść skierowana do drugiej grupy.
- Dane, na których im zależy, mają w większości ten sam kształt, ale są ujęte inaczej.
- Nie chcesz utrzymywać dwóch baz danych ani dwóch konfiguracji rozliczeń.
Powiedz swojemu kreatorowi z AI, że chcesz „drugą aplikację frontendową, która współdzieli istniejące API”. Większość nowoczesnych kreatorów z AI potrafi utworzyć bliźniaczy projekt i skierować go na Twój istniejący backend. Pułapka, której trzeba unikać: kopiowanie komponentów pierwszej aplikacji jeden do jednego, a potem edytowanie obu kopii już na zawsze. Poproś kreatora, żeby wyodrębnił wspólne części (ekrany logowania, typowe widżety formularzy) do małej biblioteki, której używają obie aplikacje. Oszczędzisz sobie miesiące zduplikowanych poprawek później.
Kształt 3: Dwie aplikacje, dwa backendy
Najcięższy podział. Naprawdę masz dwa produkty. Nie współdzielą danych, nie współdzielą użytkowników i nie powinny współdzielić mapy drogowej. Słuszny ruch to całkowite ich rozdzielenie: osobne bazy kodu, osobne bazy danych, osobne domeny.
To słuszny ruch rzadziej, niż ludziom się wydaje. Kusi, bo wydaje się czysty. Rzeczywistość jest taka, że dwie całkowicie osobne aplikacje oznaczają po dwie sztuki wszystkiego do utrzymania — dwa potoki wdrożeniowe, dwa dyżury, dwie integracje rozliczeniowe, dwie dokumentacje pomocy. Nie sięgaj po ten kształt, chyba że produkty naprawdę się nie pokrywają. Dobry test: jeśli użytkownik produktu A nigdy nie byłby użytkownikiem produktu B, to prawdopodobnie potrzebujesz Kształtu 3. Jeśli większość Twoich użytkowników mogłaby realnie chcieć obu, to prawie na pewno chcesz Kształtu 2.
Kiedy robisz to z kreatorem z AI, najłatwiejszy ruch to skopiowanie istniejącego projektu jako punktu wyjścia dla drugiego, a potem poproszenie kreatora o usunięcie funkcji, które tam nie pasują, i dodanie tych, które pasują. Nie zaczynaj drugiego projektu od pustej kartki. Sporo się nauczyłeś, budując pierwszy, a kreator z AI podchwyci ten kontekst, jeśli mu na to pozwolisz.
Co zrobić, zanim cokolwiek podzielisz
Zanim opiszesz podział swojemu kreatorowi z AI, zrób trzy małe rzeczy. Są warte więcej, niż brzmią.
Po pierwsze, napisz nową stronę główną dla każdej ze stron. Po dwa akapity. Przekaz, odbiorca, jedna rzecz, którą chcesz, żeby zrobili. Jeśli nie potrafisz napisać dwóch różnych stron głównych, to tak naprawdę nie masz jeszcze dwóch produktów — masz tylko dwa segmenty jednego produktu i powinieneś to rozwiązać przekazem, a nie architekturą.
Po drugie, wypisz, które ekrany są wspólne, a które nie. Bądź szczery. „Logowanie jest wspólne. Wdrożenie jest inne. Panel jest inny. Ustawienia są w większości wspólne. Rozliczanie jest wspólne.” Ta lista staje się briefem, który wręczasz kreatorowi z AI. Oszczędza mnóstwo tam i z powrotem.
Po trzecie, zdecyduj, co jest takie samo pod spodem. Ci sami użytkownicy? Te same dane? Te same płatności? Każde „tak” ciągnie Cię w stronę Kształtu 1 lub 2. Każde „nie” ciągnie Cię w stronę Kształtu 3. Nie ma dobrej odpowiedzi — jest tylko ta, która pasuje do tego, jak Twój produkt naprawdę działa.
Co zmienia się po podziale
Dwie rzeczy stają się łatwiejsze, a jedna trudniejsza.
Marketing staje się łatwiejszy. Każda aplikacja dostaje własny jasny przekaz. Każda landing page może mówić do jednej grupy odbiorców bez asekuracji. Twój współczynnik konwersji zwykle rośnie na co najmniej jednej stronie, czasem na obu.
Wdrożenie staje się łatwiejsze. Użytkownik trafia po raz pierwszy na stronę, która jest o nim, a nie na stronę, która próbuje być o wszystkich.
Trudniejsze staje się utrzymywanie wspólnych części w synchronizacji. Jeśli naprawiasz błąd w procesie logowania, chcesz, żeby był naprawiony w obu aplikacjach. Jeśli zmieniasz wygląd ekranu rozliczeń, chcesz, żeby obie aplikacje to odzwierciedlały. Dyscyplina, której potrzebujesz — a to prawda niezależnie od tego, czy uprawiasz vibe coding z kreatorem z AI, czy budujesz z zespołem ludzkich programistów — to utrzymywać wspólne części naprawdę wspólnymi. Nie duplikuj. Nie rozgałęziaj. Albo wyodrębnij wspólny ekran do małej biblioteki, której używają obie aplikacje, albo zaakceptuj, że masz dwie naprawdę osobne aplikacje, i weź to na siebie.
Małe pytanie na koniec
Jeśli przepuściłbyś przekaz swojej obecnej aplikacji przez pięciu nieznajomych, a każdy opisałby ją inaczej — ale w dwóch wyraźnych koszykach — to prawdopodobnie już żyjesz z podziałem. Jedyne pytanie brzmi, czy dalej płacisz podatek od jednego pomieszanego produktu, czy wykonujesz pracę bycia szczerym co do tego, że jesteś dwoma.
Nie musisz decydować dziś. Ale następnym razem, gdy Twój kreator aplikacji z AI zapyta „co mam zbudować dalej?”, rozważ, że najbardziej przydatną odpowiedzią może nie być nowa funkcja. Mogą to być nowe drzwi wejściowe.
Jeśli to do Ciebie trafiło, może spodoba Ci się też nasz wcześniejszy tekst o budowaniu dla swojego zespołu kontra budowaniu dla klientów — ten sam rodzaj decyzji, o krok wcześniej w życiu Twojego produktu.