Interne tools versus klant-apps: wanneer je welke bouwt (en waarom het ertoe doet)

Dezelfde AI-appbouwer kan een strakke boekingsapp genereren voor je fotografieklanten of een rommelige-maar-geliefde spreadsheetvervanger voor je operationele team. Van buitenaf zijn beide “apps”. Van binnenuit zijn het compleet verschillende klussen, en ze hetzelfde behandelen is de meest gemaakte fout die ik nieuwe bouwers zie maken.

De keuze interne tools versus klant-apps gaat niet over hoe de app eruitziet. Het gaat over wie wat tolereert, en wat er gebeurt als er iets breekt. Krijg dit verkeerd en je besteedt drie weken aan het polijsten van een knop waar niemand in je team om gaf, terwijl je echte gebruikers een bug raken die ze je laat wantrouwen.

Zo vogel je uit welke je echt aan het bouwen bent, en wat er verandert wanneer je het weet.

Het publiek bepaalt bijna alles

Een klant is iemand die voor jou koos. Ze hadden een concurrent kunnen gebruiken. Ze betaalden je, of ze meldden zich aan. Ze beoordelen je tegen het strakste ding dat ze ooit hebben gebruikt, ook al kost je app $9 per maand en die van hen $90. Ze hebben geen geduld voor een verwarrend label, een rare loginflow, of een lege staat die ze niet vertelt wat ze moeten doen.

Een teamgenoot is iemand die dit ding moet gebruiken omdat hun baas het zei. Het is ook iemand die je, in een Slack-bericht om 23 uur, vertelt dat de dropdown in de verkeerde volgorde staat. Ze tolereren lelijk. Ze tolereren niet traag, omdat ze het veertig keer per dag gebruiken.

Dezelfde bouwer. Dezelfde set functies, mogelijk. Wild verschillende lat.

Wanneer je met een AI-appbouwer gaat zitten om te beschrijven wat je wilt, is de allereerste vraag om voor jezelf te beantwoorden: wie is de gebruiker, en koos die ervoor om hier te zijn?

Interne tools: snelheid verslaat afwerking

Interne tools staan of vallen met één ding: hoeveel tijd besparen ze de mensen die ze gebruiken?

Een vastgoedbeheerder die ik ken, besteedde twee avonden aan het bouwen van een onderhoudsverzoektracker voor haar driekoppige team. Het is, naar elke objectieve maatstaf, lelijk. De knoppen zijn inconsistent. De zijbalk heeft er een typefout in die niemand de moeite heeft genomen te repareren. Er is geen logo.

Haar team gebruikt het meer dan welke andere software ze bezitten. Het bespaarde ze ruwweg vijf uur per week aan “heeft iemand de loodgieter al gebeld over unit 4?”-Slack-berichten. De afwerking zou nul uur aan waarde hebben toegevoegd.

Drie eigenschappen die ik zie in goed gebouwde interne tools:

• Het kortste pad van “ik wil X doen” naar “X is gedaan” wint. Sla het welkomstscherm over. Sla de wizard over. Open meteen in het ding.
• Randgevallen mogen lelijk zijn. Als een teamgenoot een fout raakt, appen ze je. Een klant zou gewoon weggaan.
• Updates landen dagelijks, niet in releases. Je lanceert geen product. Je sleutelt aan je eigen werkplaats.

Als je voor je team bouwt, leun dan stevig in “lelijk en nuttig”. Verzet je tegen de drang om een marketingpagina, een instellingenscherm of een mooie lege staat toe te voegen. Niets ervan verdient zijn plek.

Klant-apps: de saaie randjes zijn het product

Klant-apps zijn voornamelijk randjes. De loginflow. De onboarding. Wat er gebeurt als een creditcard wordt geweigerd. De e-mail die uitgaat wanneer een wachtwoord wordt gereset. Het scherm dat iemand ziet de eerste keer dat ze de app openen en er nog niets in hebben.

Geen van deze is de functie waar je enthousiast over werd. Het is allemaal waar je klant je op beoordeelt.

Een vriend lanceerde vorig jaar een kleine factureringsapp. Hij besteedde zijn eerste maand aan het bouwen van de factuureditor — het ding waar hij enthousiast over was. Het was prachtig. Toen zette hij hem aan, keek hoe een klant zich probeerde aan te melden, en ontdekte dat:

• De verificatie-e-mail in spam belandde.
• Na verificatie de app de gebruiker een leeg dashboard inwierp zonder instructies.
• De knop “maak je eerste factuur” onder de vouw zat op een 13-inch laptop.

Drie klanten meldden zich die week aan. Nul maakten een factuur. Het product werkte. De verpakking eromheen niet.

Voor klantgerichte apps is de ruwe regel: besteed de helft van je inspanning aan het oppervlak dat niet de hoofdfunctie is. Onboarding, foutstaten, betaalflows, accountinstellingen, support-e-mail. Dat spul is het product, ook al voelt het niet zo.

Hoe je bepaalt welke je aan het bouwen bent

De keuze interne tools versus klant-apps is makkelijker dan hij lijkt zodra je een paar diagnostische vragen stelt:

Wie betaalt hiervoor? Als het antwoord is “het bedrijf waar ik werk, als onderdeel van de overhead”, is het een interne tool. Als het antwoord is “de gebruiker, individueel, met hun creditcard”, is het een klant-app. Het tussengeval — je baas betaalt, maar je baas is een klant — trekt meestal nog steeds naar de verwachtingen van een klant-app.

Wat gebeurt er als hij een uur plat ligt? Interne tool: iemand is geïrriteerd. Klant-app: iemand gaat weg. De ontploffingsstraal van een bug is wild verschillend.

Hoeveel gebruikers krijgt hij, ooit? Vijf tot vijftig is degelijk intern. Honderd tot duizend begint eruit te zien als een echt product. Vijfduizend en meer betekent dat je een softwarebedrijf bent, of je dat nu wilde zijn of niet.

Hebben gebruikers een keuze? Interne tools zijn verplicht. Klant-apps zijn vrijwillig. Vrijwillige gebruikers vertrekken op het moment dat iets ze irriteert.

Als je deze niet helder kunt beantwoorden, weet je niet wat je aan het bouwen bent, en kan de AI-bouwer je niet helpen convergeren.

De verborgen valkuil: tools die producten worden

Hier wordt het interessant. De meest succesvolle indie-producten die ik ken, begonnen hun leven als interne tools. Iemand bouwde een ding voor hun team, het team liet het aan een vriend zien, de vriend wilde er een, en nu is er een klant.

Dit is een geweldig verhaal. Het is ook een moment van maximaal gevaar, want op het moment dat je iemand laat betalen, verschuift de lat van de ene op de andere dag. De lelijke zijbalk die je team tolereerde, is nu een afhaakrisico. De app-de-ontwikkelaar-foutafhandeling is nu een supportnachtmerrie.

Als je deze brug oversteekt met een AI-appbouwer, behandel het dan als een echte overgang. Besteed een week — minstens een week — aan de saaie randjes. Onboarding. Lege staten. De eerste vijf minuten na aanmelding. Foutmeldingen die zichzelf uitleggen. Promoot de tool niet totdat dat werk gedaan is.

Het goede nieuws is dat AI-bouwers deze overgang goedkoper hebben gemaakt dan vroeger. Het afwerkingswerk dat vroeger een maand kostte met een freelancer, is een paar goede promptsessies en wat geduld.

De vraag om bij stil te staan

De hele kwestie interne tools versus klant-apps valt samen in één prompt voor jezelf voordat je een idee aan een AI-appbouwer beschrijft: Is dit een tool die ik gebruik, of een product dat ik aanbied?

Het antwoord verandert de prompt. Het verandert waar je tijd aan besteedt. Het verandert wat je negeert. En het is het enige nuttigste stukje helderheid dat je in de build kunt brengen.

Als je twijfelt aan welke kant je staat, is ons stuk over wat je eerste met AI gebouwde app zou moeten zijn een goede aanvullende lectuur. De meeste eerste apps zouden tools moeten zijn. De meeste tweede ook. Klanten komen later, en ze komen makkelijker zodra je de spier hebt verdiend door dingen te bouwen waar alleen je team doorheen moest worstelen.