När en produkt blir två: hur du delar din AI-byggda app utan att börja om
Din AI-byggda app började som en produkt. Sedan insåg du att den i hemlighet var två. Här är hur du delar en AI-app rent – utan att överge det du redan skeppat.
Du började med en idé. Du beskrev den för din AI-appbyggare, såg den generera skärmarna, putsade på de skrovliga kanterna och skeppade något riktigt. Folk började använda det. Och så, först långsamt, dök ett mönster upp i återkopplingen: hälften av dina användare ville ha en sak, den andra hälften ville ha något annat. De slogs inte om samma funktion. De bad om två olika produkter.
Det här är ögonblicket då många grundare får panik och startar ett andra projekt från grunden. Det borde de inte. Det finns ett renare sätt att dela en AI-app när din ena produkt visar sig vara två – och det behåller oftast det mesta av det du redan byggt. Det här inlägget handlar om hur du känner igen delningen, när du ska göra den och de tre former delningen tenderar att ta.
Hur du upptäcker att du har två produkter
Signalen ser nästan aldrig ut som en funktionsförfrågan. Den ser ut som friktion.
En produktivitetsapp jag såg gå igenom detta hade en tydlig historia. Den såldes som en “personlig planerare”. Användarna började dyka upp i två varianter. En grupp använde den för att planera sin egen vecka och behandlade den som ett privat anteckningsblock. Den andra gruppen drev små team och ville tilldela saker till andra människor. Båda var nöjda nog för att fortsätta använda samma produkt, men varje release gladde en grupp och irriterade den andra. Teamet trodde att de hade ett problem med funktionsprioritering. De hade egentligen ett varumärkesproblem. De hade en personlig app och en team-app som delade en kodbas, en startsida och en prissida.
Du vet att du har korsat den gränsen när något av detta börjar bli sant:
- Din landningssida måste gömma sitt faktiska budskap bakom generiskt språk eftersom två målgrupper inte tror på samma ord.
- Varje ny funktion har ett “men för den andra sortens användare borde det fungera annorlunda”-förbehåll.
- Dina supportsvar börjar förgrena sig: “om du använder det för dig själv …” mot “om du hanterar ett team …”.
- Ett inte obetydligt antal användare har två separata konton för att hålla de två lägena åtskilda.
Om du ser två eller fler av dessa har du inte ett funktionsproblem. Du har en produktdelning som väntar på att hända.
De tre formerna av en delning
Du behöver inte välja en form dag ett. Du kan oftast prova den lättaste först och trappa upp. Men det är nyttigt att känna till menyn innan du börjar beskriva det för din AI-byggare, eftersom orden du använder formar vad som genereras.
Form 1: en app, två dörrar
Den lättaste versionen. Du behåller en kodbas. Du lägger till en fråga vid första körningen – “Är du här för dig själv eller för ett team?” – och använder svaret för att visa olika uppsättningar sidor och olika navigering. Samma datalager. Samma inloggning. Samma fakturering. Bara en annan yta.
De flesta AI-appbyggare hanterar detta bra om du beskriver det som en “app med två lägen”. Det du ska se upp med är att de två lägena inte ska dela skärmar med villkorliga visa-och-dölj överallt. Det slutar med att se ut som en rörig app som låtsas vara två. Säg till byggaren att de två dörrarna är separata – olika startsidor, olika inställningssidor, olika tomma tillstånd. De få skärmar som faktiskt överlappar (kontoinställningar, fakturering) kan delas.
När detta fungerar: när de två målgrupperna vill ha olika inramning men samma underliggande objekt. Planerare-mot-team-exemplet passar här. Det du schemalägger är fortfarande en uppgift; bara reglerna kring tilldelning, delning och avisering ändras.
När detta inte fungerar: när de två målgrupperna förväntar sig helt olika objekt. En “kundportal” och ett “internt admin-verktyg” har nästan ingen överlappning, även om de ser ut att handla om samma verksamhet.
Form 2: två appar, en backend
Mellanformen. Du delar produktens framsida i två separata appar – två URL:er, två landningssidor, två onboarding-flöden, två pristabeller – men de läser båda från samma databas under huven. En kund kan ha ett konto på båda. En admin kan se data från båda.
Det här är vad vi nyligen gjorde på företaget som driver den här bloggen. Vi hade en app som försökte betjäna två målgrupper: ingenjörer som utvärderade vår agentplattform, och byggare som använde vår AI-appbyggare. Samma backend, samma autentisering, samma databas – men frontend hade fått två huvuden, och budskapet var förvirrat. Vi delade upp den i två frontend-appar, en för varje målgrupp. Backend förblev exakt densamma.
Den här formen är rätt svar när:
- De två målgrupperna köper av olika skäl.
- De skulle bli förvirrade eller avskräckta av den andra målgruppens marknadsföringstext.
- Datan de bryr sig om har mestadels samma form, men ramas in olika.
- Du inte vill underhålla två databaser eller två faktureringsupplägg.
Säg till din AI-byggare att du vill ha en “andra frontend-app som delar det befintliga API:et”. De flesta moderna AI-byggare kan ställa upp ett syskonprojekt och peka det mot din befintliga backend. Fällan att undvika: kopiera-klistra in den första appens komponenter ordagrant och sedan redigera båda kopiorna för evigt. Be byggaren att extrahera de delade delarna (autentiseringsskärmar, vanliga formulärwidgetar) till ett litet bibliotek som båda apparna använder. Du sparar dig själv månader av dubblerade fixar senare.
Form 3: två appar, två backends
Den tyngsta delningen. Du har faktiskt två produkter. De delar inte data, de delar inte användare, och de borde inte dela en färdplan. Rätt drag är att separera dem helt: separata kodbaser, separata databaser, separata domäner.
Det här är rätt drag mer sällan än folk tror. Det är frestande för att det känns rent. Verkligheten är att två helt separata appar betyder två av allt att hålla igång – två deploy-pipelines, två jourrotationer, två faktureringsintegrationer, två hjälpdokument. Sträck dig inte efter den här formen om inte produkterna genuint inte överlappar. Ett bra test: om en användare av produkt A aldrig skulle vara en användare av produkt B, behöver du förmodligen Form 3. Om de flesta av dina användare rimligen skulle kunna vilja ha båda, vill du nästan säkert ha Form 2.
När du gör det här med en AI-byggare är det enklaste draget att kopiera ditt befintliga projekt som startpunkt för det andra, och sedan be byggaren att ta bort de funktioner som inte hör hemma och lägga till dem som gör det. Starta inte det andra projektet från ett tomt blad. Du lärde dig redan mycket av att bygga det första, och AI-byggaren plockar upp det sammanhanget om du låter den.
Vad du ska göra innan du delar något
Innan du beskriver delningen för din AI-byggare, gör tre små saker. De är värda mer än de låter.
För det första, skriv den nya startsidan för varje sida. Två stycken var. Budskapet, målgruppen, den enda sak du vill att de ska göra. Om du inte kan skriva två olika startsidor har du faktiskt inte två produkter än – du har bara två segment av en produkt, och det ska du lösa med budskap, inte arkitektur.
För det andra, lista vilka skärmar som är delade och vilka som inte är det. Var ärlig. “Inloggning är delad. Onboarding är annorlunda. Instrumentpanelen är annorlunda. Inställningar är mestadels delade. Fakturering är delad.” Den här listan blir uppdraget du lämnar till AI-byggaren. Den sparar mycket fram-och-tillbaka.
För det tredje, bestäm vad som är detsamma under huven. Samma användare? Samma data? Samma betalningar? Varje “ja” drar dig mot Form 1 eller 2. Varje “nej” drar dig mot Form 3. Det finns inget rätt svar – bara svaret som matchar hur din produkt faktiskt fungerar.
Vad som ändras efter delningen
Två saker blir enklare och en sak blir svårare.
Marknadsföring blir enklare. Varje app får sitt eget tydliga budskap. Varje landningssida kan tala till en målgrupp utan att gardera sig. Din konverteringsgrad går oftast upp på minst en sida, ibland båda.
Onboarding blir enklare. En förstagångsanvändare landar på en sida som handlar om dem, inte en sida som försöker handla om alla.
Det som blir svårare är att hålla de delade delarna i synk. Om du fixar en bugg i inloggningsflödet vill du ha den fixad i båda apparna. Om du ändrar hur faktureringsskärmen ser ut vill du att båda apparna ska återspegla det. Disciplinen du behöver – och det är sant vare sig du vibe-codar med en AI-byggare eller bygger med ett team av mänskliga utvecklare – är att hålla de delade delarna genuint delade. Dubblera inte. Forka inte. Antingen extraherar du den delade skärmen till ett litet bibliotek som båda apparna använder, eller så accepterar du att du har två verkligt separata appar och äger det.
En liten fråga att avsluta med
Om du körde din nuvarande apps budskap förbi fem främlingar och de var och en beskrev det olika – men i två tydliga fack – lever du förmodligen redan med delningen. Den enda frågan är om du fortsätter betala skatten för en förvirrad produkt, eller gör jobbet att vara ärlig om att vara två.
Du behöver inte bestämma idag. Men nästa gång din AI-appbyggare frågar “vad ska jag bygga härnäst?”, överväg att det mest användbara svaret kanske inte är en ny funktion. Det kanske är en ny ytterdörr.
Om det här gav genklang kanske du också gillar vårt tidigare inlägg om att bygga för ditt team kontra att bygga för kunder – samma sorts beslut, ett steg tidigare i din produkts liv.