Interna verktyg kontra kundappar: när du ska bygga vilket (och varför det spelar roll)

Samma AI-appbyggare kan generera en stilren bokningsapp för dina fotograferingskunder eller en skraltig-men-älskad ersättning för ett kalkylark åt ditt driftsteam. Utifrån sett är båda “appar”. Inifrån sett är de helt olika jobb, och att behandla dem likadant är det vanligaste misstaget jag ser nya byggare göra.

Beslutet om interna verktyg kontra kundappar handlar inte om hur appen ser ut. Det handlar om vem som tolererar vad, och vad som händer när något går sönder. Får du det här om bakfoten lägger du tre veckor på att putsa en knapp som ingen i ditt team brydde sig om, samtidigt som dina faktiska användare stöter på en bugg som får dem att sluta lita på dig.

Här är hur du listar ut vilket du egentligen bygger, och vad som ändras när du vet det.

Målgruppen avgör nästan allt

En kund är någon som valde dig. De kunde ha använt en konkurrent. De betalade dig, eller de registrerade sig. De kommer döma dig mot det mest stilrena de någonsin använt, även om din app kostar 9 dollar i månaden och deras kostade 90 dollar. De har inget tålamod med en förvirrande etikett, ett konstigt inloggningsflöde eller ett tomt tillstånd som inte berättar vad de ska göra.

En kollega är någon som måste använda den här grejen för att chefen sa till dem. De är också någon som kommer berätta för dig, i ett Slack-meddelande klockan 23, att rullgardinsmenyn är i fel ordning. De tolererar fult. De tolererar inte långsamt, för de använder den fyrtio gånger om dagen.

Samma byggare. Samma uppsättning funktioner, möjligen. Vansinnigt olika ribba.

När du sätter dig ner med en AI-appbyggare för att beskriva vad du vill ha, är den allra första frågan du ska svara dig själv: vem är användaren, och valde de att vara här?

Interna verktyg: snabbhet slår polering

Interna verktyg lever och dör på en enda sak: hur mycket tid sparar de åt de som använder dem?

En fastighetsförvaltare jag känner lade två kvällar på att bygga en felanmälningshanterare för sitt trepersonersteam. Den är, enligt vilken objektiv måttstock som helst, ful. Knapparna är inkonsekventa. Sidofältet har ett stavfel som ingen har brytt sig om att fixa. Det finns ingen logotyp.

Hennes team använder den mer än någon annan programvara de äger. Den sparade dem ungefär fem timmar i veckan av “har någon redan ringt rörmokaren om lägenhet 4?”-Slack-meddelanden. Poleringen hade adderat noll timmars värde.

Tre drag jag ser i välbyggda interna verktyg:

• Den kortaste vägen från “jag vill göra X” till “X är gjort” vinner. Hoppa över välkomstskärmen. Hoppa över guiden. Öppna direkt in i själva grejen.
• Specialfall får vara fula. Om en kollega stöter på ett fel skickar de ett Slack-meddelande till dig. En kund skulle bara churna.
• Uppdateringar landar dagligen, inte i releaser. Du levererar inte en produkt. Du justerar din egen verkstad.

Om du bygger för ditt team, luta dig hårt in i “fult och användbart”. Stå emot lusten att lägga till en marknadsföringssida, en inställningsskärm eller ett vackert tomt tillstånd. Inget av det förtjänar sin plats.

Kundappar: de tråkiga kanterna är produkten

Kundappar är mestadels kanter. Inloggningsflödet. Onboardingen. Vad som händer när ett kreditkort nekas. Mejlet som går ut när ett lösenord återställs. Skärmen någon ser första gången de öppnar appen och inte har något i den än.

Inget av det här är funktionen du blev exalterad över. Allt av det är vad din kund dömer dig på.

En vän lanserade en liten faktureringsapp förra året. Han lade sin första månad på att bygga fakturaredigeraren — grejen han var exalterad över. Den var vacker. Sedan slog han på den, såg en kund försöka registrera sig, och upptäckte att:

• Verifieringsmejlet hamnade i skräpposten.
• Efter verifieringen kastades användaren in i en tom instrumentpanel utan instruktioner.
• Knappen “skapa din första faktura” låg under sidans nedre kant på en 13-tums laptop.

Tre kunder registrerade sig den veckan. Noll skapade en faktura. Produkten fungerade. Omslaget runt den gjorde det inte.

För kundvända appar är den grova regeln: lägg hälften av din ansträngning på ytan som inte är huvudfunktionen. Onboarding, feltillstånd, betalflöden, kontoinställningar, supportmejl. Den grejen är produkten, även om det inte känns så.

Hur du avgör vilket du bygger

Beslutet om interna verktyg kontra kundappar är enklare än det ser ut när du väl ställer några diagnostiska frågor:

Vem betalar för det här? Om svaret är “företaget jag jobbar för, som en del av de allmänna kostnaderna”, är det ett internt verktyg. Om svaret är “användaren, individuellt, med sitt kreditkort”, är det en kundapp. Mellanfallet — din chef betalar, men din chef är en kund — drar oftast ändå mot förväntningar på kundappar.

Vad händer om det ligger nere i en timme? Internt verktyg: någon blir irriterad. Kundapp: någon churnar. En buggs sprängradie är vansinnigt olika.

Hur många användare kommer det någonsin ha? Fem till femtio är solitt internt. Hundra till tusen börjar se ut som en riktig produkt. Femtusen och uppåt betyder att du är ett mjukvaruföretag oavsett om du ville vara det eller inte.

Kommer användarna ha ett val? Interna verktyg är obligatoriska. Kundappar är frivilliga. Frivilliga användare lämnar i samma stund något irriterar dem.

Om du inte kan svara tydligt på de här frågorna vet du inte vad du bygger, och AI-byggaren kan inte hjälpa dig att konvergera.

Den dolda fällan: verktyg som blir produkter

Här blir det intressant. De mest framgångsrika indie-produkterna jag känner till började livet som interna verktyg. Någon byggde en grej för sitt team, teamet visade den för en vän, vännen ville ha en, och nu finns det en kund.

Det är en fin historia. Det är också ett ögonblick av maximal fara, för i samma stund du tar betalt av någon flyttas ribban över en natt. Det fula sidofältet som ditt team tolererade är nu en churn-risk. Felhanteringen av typen Slack-meddela-utvecklaren är nu en supportmardröm.

Om du korsar den här bron med en AI-appbyggare, behandla det som en riktig övergång. Lägg en vecka — minst en vecka — på de tråkiga kanterna. Onboarding. Tomma tillstånd. De första fem minuterna efter registrering. Felmeddelanden som förklarar sig själva. Marknadsför inte verktyget förrän det arbetet är gjort.

Den goda nyheten är att AI-byggare har gjort den här övergången billigare än den brukade vara. Poleringsarbetet som förr tog en månad med en frilansare är några bra prompt-sessioner och lite tålamod.

Frågan att sitta med

Hela frågan om interna verktyg kontra kundappar kokar ner till en enda prompt till dig själv innan du beskriver en idé för en AI-appbyggare: Är det här ett verktyg jag använder, eller en produkt jag erbjuder?

Svaret förändrar prompten. Det förändrar vad du lägger tid på. Det förändrar vad du ignorerar. Och det är den enskilt mest användbara biten av klarhet du kan ta med dig in i bygget.

Om du har stått och vägt mellan vilken sida du är på, är vårt inlägg om vad din första AI-byggda app borde vara en bra följeslagare att läsa. De flesta första appar borde vara verktyg. De flesta andra också. Kunder kommer senare, och de kommer lättare när du har förtjänat muskeln av att bygga saker som bara ditt team behövde lida sig igenom.