Wanneer één product er twee wordt: hoe je je met AI gebouwde app splitst zonder opnieuw te beginnen

Je begon met één idee. Je beschreef het aan je AI-appbouwer, keek hoe hij de schermen genereerde, bewerkte de ruwe randjes, en lanceerde iets echts. Mensen begonnen het te gebruiken. En toen, eerst langzaam, dook er een patroon op in de feedback: de helft van je gebruikers wilde het ene, de andere helft wilde iets anders. Ze vochten niet over dezelfde functie. Ze vroegen om twee verschillende producten.

Dit is het moment waarop veel oprichters in paniek raken en een tweede project vanaf nul beginnen. Dat zouden ze niet moeten doen. Er is een nettere manier om een AI-app te splitsen wanneer je ene product twee blijkt te zijn — en hij behoudt meestal het meeste van wat je al hebt gebouwd. Deze post gaat over hoe je de splitsing herkent, wanneer je hem doet, en de drie vormen die de splitsing meestal aanneemt.

Hoe je erachter komt dat je twee producten hebt

Het signaal ziet er bijna nooit uit als een functieverzoek. Het ziet eruit als frictie.

Een productiviteitsapp die ik dit zag doormaken had een helder verhaal. Hij werd verkocht als een “persoonlijke planner”. Gebruikers begonnen in twee smaken op te duiken. Eén groep gebruikte hem om hun eigen week te plannen en behandelde hem als een privénotitieboek. De andere groep runde kleine teams en wilde dingen aan andere mensen toewijzen. Ze waren beide blij genoeg om hetzelfde product te blijven gebruiken, maar elke release behaagde de ene groep en irriteerde de andere. Het team dacht dat ze een functieprioriteringsprobleem hadden. Ze hadden eigenlijk een merkprobleem. Ze hadden een persoonlijke app en een team-app die één codebase, één homepage en één prijspagina deelden.

Je weet dat je die lijn hebt overschreden wanneer een van deze waar begint te worden:

• Je landingspagina moet zijn echte pitch verbergen achter generieke taal omdat twee doelgroepen niet dezelfde woorden zullen geloven.
• Elke nieuwe functie heeft een “maar voor het andere soort gebruiker zou het anders moeten werken”-voorbehoud.
• Je supportantwoorden beginnen te vertakken: “als je het voor jezelf gebruikt…” versus “als je een team beheert…”
• Een niet-triviaal aantal gebruikers houdt twee aparte accounts aan om de twee modi gescheiden te houden.

Als je twee of meer hiervan ziet, heb je geen functieprobleem. Je hebt een productsplitsing die staat te wachten om te gebeuren.

De drie vormen van een splitsing

Je hoeft niet op dag één een vorm te kiezen. Je kunt meestal eerst de lichtste proberen en escaleren. Maar het is nuttig om het menu te kennen voordat je het aan je AI-bouwer begint te beschrijven, want de woorden die je gebruikt, vormen wat er gegenereerd wordt.

Vorm 1: één app, twee deuren

De lichtste versie. Je houdt één codebase. Je voegt een vraag toe bij de eerste keer opstarten — “Ben je hier voor jezelf of voor een team?” — en gebruikt het antwoord om een andere set pagina’s en een andere navigatie te tonen. Dezelfde dataopslag. Dezelfde login. Dezelfde facturering. Gewoon een ander oppervlak.

De meeste AI-appbouwers handelen dit goed af als je het beschrijft als een “twee-modus-app”. Het ding om op te letten is dat de twee modi geen schermen zouden moeten delen met overal conditionele toon-en-verberg-acties. Dat ziet er uiteindelijk uit als één rommelige app die doet alsof het er twee is. Vertel de bouwer dat de twee deuren gescheiden zijn — andere homepages, andere instellingenpagina’s, andere lege staten. De paar schermen die wel overlappen (accountinstellingen, facturering) kunnen gedeeld worden.

Wanneer dit werkt: wanneer de twee doelgroepen een andere framing willen maar dezelfde onderliggende objecten. Het planner-versus-team-voorbeeld past hier. Het ding dat je plant is nog steeds een taak; alleen de regels rond toewijzen, delen en informeren veranderen.

Wanneer dit niet werkt: wanneer de twee doelgroepen compleet andere objecten verwachten. Een “klantenportaal” en “interne beheertool” hebben bijna geen overlap, ook al lijken ze over hetzelfde bedrijf te gaan.

Vorm 2: twee apps, één back-end

De middenvorm. Je splitst de voorkant van het product in twee aparte apps — twee URL’s, twee landingspagina’s, twee onboardingflows, twee prijstabellen — maar ze lezen allebei uit dezelfde database eronder. Een klant kan op beide een account hebben. Een beheerder kan data van beide zien.

Dit is wat we onlangs deden bij het bedrijf dat deze blog runt. We hadden één app die twee doelgroepen probeerde te bedienen: engineers die ons agentplatform evalueren, en bouwers die onze AI-appbouwer gebruiken. Dezelfde backend, dezelfde auth, dezelfde database — maar de voorkant had twee koppen gekregen, en de boodschap was verward. We splitsten hem in twee front-end-apps, een voor elke doelgroep. De backend bleef precies hetzelfde.

Deze vorm is het juiste antwoord wanneer:

• De twee doelgroepen om verschillende redenen kopen.
• Ze in de war of afgeschrikt zouden raken door de marketingtekst van de andere doelgroep.
• De data waar ze om geven grotendeels dezelfde vorm heeft, maar anders geframed.
• Je geen twee databases of twee factureringsopzetten wilt onderhouden.

Vertel je AI-bouwer dat je een “tweede front-end-app wilt die de bestaande API deelt”. De meeste moderne AI-bouwers kunnen een zusterproject opzetten en het naar je bestaande backend wijzen. De valkuil om te vermijden: de componenten van de eerste app letterlijk kopiëren-en-plakken en dan beide kopieën voor altijd bewerken. Vraag de bouwer om de gedeelde delen (authenticatieschermen, gangbare formulierwidgets) te extraheren in een kleine bibliotheek die beide apps gebruiken. Je bespaart jezelf later maanden aan dubbele fixes.

Vorm 3: twee apps, twee back-ends

De zwaarste splitsing. Je hebt echt twee producten. Ze delen geen data, ze delen geen gebruikers, en ze zouden geen roadmap moeten delen. De juiste zet is om ze volledig te scheiden: aparte codebases, aparte databases, aparte domeinen.

Dit is minder vaak de juiste zet dan mensen denken. Het is verleidelijk omdat het schoon voelt. De realiteit is dat twee compleet aparte apps twee van alles betekent om draaiende te houden — twee deploypijplijnen, twee oproeproosters, twee factureringsintegraties, twee helpdocumenten. Grijp niet naar deze vorm tenzij de producten oprecht niet overlappen. Een goede test: als een gebruiker van product A nooit een gebruiker van product B zou zijn, heb je waarschijnlijk vorm 3 nodig. Als de meeste van je gebruikers plausibel beide zouden kunnen willen, wil je vrijwel zeker vorm 2.

Wanneer je dit doet met een AI-bouwer, is de makkelijkste zet om je bestaande project te kopiëren als startpunt voor het tweede, en dan de bouwer te vragen de functies te verwijderen die er niet bij horen en de functies toe te voegen die er wel bij horen. Begin het tweede project niet vanaf een leeg canvas. Je hebt al veel geleerd bij het bouwen van het eerste, en de AI-bouwer pikt die context op als je het toelaat.

Wat te doen voordat je iets splitst

Voordat je de splitsing aan je AI-bouwer beschrijft, doe drie kleine dingen. Ze zijn meer waard dan ze klinken.

Ten eerste, schrijf de nieuwe homepage voor elke kant. Twee alinea’s elk. De pitch, de doelgroep, het ene ding dat je wilt dat ze doen. Als je geen twee verschillende homepages kunt schrijven, heb je nog niet echt twee producten — je hebt gewoon twee segmenten van één product, en dat zou je moeten oplossen met boodschap, niet met architectuur.

Ten tweede, maak een lijst van welke schermen gedeeld zijn en welke niet. Wees eerlijk. “Login is gedeeld. Onboarding is anders. Dashboard is anders. Instellingen zijn grotendeels gedeeld. Facturering is gedeeld.” Deze lijst wordt de briefing die je aan de AI-bouwer overhandigt. Het bespaart veel heen-en-weer.

Ten derde, beslis wat hetzelfde is eronder. Dezelfde gebruikers? Dezelfde data? Dezelfde betalingen? Elke “ja” trekt je naar vorm 1 of 2. Elke “nee” trekt je naar vorm 3. Er is geen juist antwoord — alleen het antwoord dat past bij hoe je product echt werkt.

Wat er verandert na de splitsing

Twee dingen worden makkelijker en één ding wordt moeilijker.

Marketing wordt makkelijker. Elke app krijgt zijn eigen heldere pitch. Elke landingspagina kan tot één doelgroep spreken zonder voorbehoud. Je conversiepercentage gaat meestal omhoog aan minstens één kant, soms beide.

Onboarding wordt makkelijker. Een eerste-keer-gebruiker landt op een pagina die over hen gaat, niet op een pagina die over iedereen probeert te gaan.

Wat moeilijker wordt, is de gedeelde delen synchroon houden. Als je een bug repareert in de loginflow, wil je hem in beide apps gerepareerd hebben. Als je verandert hoe het factureringsscherm eruitziet, wil je dat beide apps het weerspiegelen. De discipline die je nodig hebt — en dit geldt of je nu vibe-codet met een AI-bouwer of bouwt met een team van menselijke ontwikkelaars — is om de gedeelde delen oprecht gedeeld te houden. Dupliceer niet. Fork niet. Extraheer ofwel het gedeelde scherm in een kleine bibliotheek die beide apps gebruiken, of accepteer dat je twee echt aparte apps hebt en sta daarvoor.

Een kleine vraag om mee af te sluiten

Als je de pitch van je huidige app langs vijf vreemden zou laten gaan en ze hem elk anders zouden beschrijven — maar in twee aparte hokjes — leef je waarschijnlijk al met de splitsing. De enige vraag is of je de belasting van één verward product blijft betalen, of het werk doet om eerlijk te zijn over twee zijn.

Je hoeft het vandaag niet te beslissen. Maar de volgende keer dat je AI-appbouwer vraagt “wat moet ik vervolgens bouwen?”, overweeg dat het nuttigste antwoord misschien geen nieuwe functie is. Het is misschien een nieuwe voordeur.

Als dit aansloeg, vind je misschien ook ons eerdere stuk over bouwen voor je team versus bouwen voor klanten leuk — dezelfde smaak van beslissing, één stap eerder in het leven van je product.