Wanneer je een tweede persoon uitnodigt om je met AI gebouwde app te onderhouden

De meeste apps gebouwd met een AI-appbouwer beginnen als een eenpersoonsproject. Je had op zaterdagochtend een idee, je beschreef het aan de bouwer, tegen zaterdagavond had je iets dat werkte, en tegen het volgende weekend had je echte mensen die het gebruikten. Een tijdlang kun je het hele ding zelf runnen — berichten beantwoorden, de ene typefout op de homepage repareren, de nieuwe functie toevoegen waar een gebruiker steeds om vraagt, de analytics op je telefoon bekijken in de koffiezaak.

Dan merk je op een dag dat je eigenlijk al drie weken niets nieuws hebt gebouwd. Elk vrij uur gaat naar onderhoud. De “kleine aanpassingen” houden nooit op. Je beantwoordt voor de vijftiende keer dezelfde vraag van nieuwe gebruikers. Je begint op te zien tegen het openen van de app, wat het ergste gevoel is dat een bouwer kan hebben over iets dat ze maakten.

Dit is het moment om na te denken over het uitnodigen van een tweede persoon. Geen medeoprichter, geen aanwerving, geen aannemer voor een grote herbouw — gewoon één persoon extra die kan helpen het ding te dragen.

Deze post gaat over hoe je weet wanneer je dat moment hebt bereikt, wie de juiste eerste persoon is om uit te nodigen, en hoe je ze een stuk van je met AI gebouwde app overhandigt zonder de controle over het geheel op te geven.

De tekenen dat het tijd is

Je weet dat het tijd is wanneer je op de meeste hiervan ja kunt antwoorden:

Je zegt nee tegen wijzigingen die je zou willen maken. Niet omdat het slechte ideeën zijn — omdat je de uren niet hebt. Je bent een privélijst begonnen met “dingen die ik zou doen als ik tijd had” en hij wordt steeds langer.
Dezelfde gebruikersvraag blijft terugkomen. Je hebt “hoe exporteer ik mijn data?” acht keer beantwoord in twee weken. Dat is een helppagina, maar je hebt geen tijd om hem te schrijven, dus je blijft met de hand antwoorden.
Je vermijdt de app. Een specifieke hoek ervan voelt zwaar. Misschien het beheerdersgedeelte, misschien het factureringsscherm — iets waar elke wijziging als een operatie voelt. Je laat bugs daar langer verouderen dan je zou moeten.
Eén fout zou pijn doen. Je app heeft nu echte gebruikers met echte data. Een enkele slechte deploy op een vermoeide dinsdagavond zou iemands werk kunnen kwijtraken. Je hebt geen tweede paar ogen.
Jij bent de flessenhals voor groei. Drie potentiële klanten vroegen om een kleine wijziging voordat ze zich zouden aanmelden. Twee maanden geleden had je het die avond gebouwd. Nu kun je niet eens binnen drie dagen reageren.

Als twee daarvan waar zijn, is het misschien oké. Als er vier waar zijn, ben je al langer de flessenhals dan je je realiseert.

Wie je als eerste uitnodigt

De drang is om iemand te vinden die “technischer is dan jij”. Dit is meestal verkeerd. De eerste persoon om uit te nodigen is niet de persoon die code kan schrijven. Het is de persoon die al om je app geeft.

Kijk in deze volgordes, ruwweg:

Een gebruiker die steeds dingen voorstelt. Je hebt er waarschijnlijk een. Ze hebben je vier functie-ideeën gestuurd, twee bugmeldingen, en een beleefde klacht over de bewoording op je aanmeldscherm. Ze willen dat dit product goed is. Ze letten op. Als je ze vraagt of ze één hoek ervan zouden willen helpen vormgeven, is het antwoord vaak ja.

Een vriend die vanaf de zijlijn heeft toegekeken. Iemand die je maandenlang over de app heeft horen praten en nieuwsgierig is. Ze hoeven niet te weten hoe ze moeten coderen — je AI-appbouwer doet dat. Ze moeten duidelijk kunnen beschrijven wat ze willen, wat de meeste mensen die je een tijdje hebben zien worstelen beter kunnen dan ze beseffen.

Iemand in je community. Als je app docenten bedient, vind een docent. Als hij trouwfotografen bedient, vind een trouwfotograaf. De domeinkennis is meer waard dan technische vaardigheid, want de AI-appbouwer kan technische vaardigheid invullen maar hij kan niet invullen “wat trouwfotografen echt nodig hebben op een zaterdag in juli”.

Een echt voorbeeld, licht vermomd. Iemand die we kennen bouwde een kleine marktplaats voor handgemaakt keramiek met een AI-appbouwer. Na zes maanden verzoop ze — berichten van verkopers beantwoorden, dezelfde checkout-tekst drie keer repareren, functies bouwen voor kopers die ze niet had ontmoet. Ze nodigde een van haar verkopers uit, een vrouw die haar dat jaar al elf suggesties had gemaild. Binnen twee maanden had die verkoper de meeste verkoper-gerichte pagina’s herschreven, met een stem die geen buitenstaander had kunnen kopiëren. De oprichter bleef bouwen voor kopers. De app vertraagde niet; hij verdubbelde bijna in tempo.

De slechtste eerste uitnodiging is meestal een generieke technische aannemer. Ze leveren goed werk, maar het kan ze niet schelen, en de eerste persoon die je uitnodigt moet het kunnen schelen, want ze gaan veel kleine inschattingen maken zonder jou.

Welk stuk je ze overhandigt

De fout is om ze de hele app te overhandigen. De hele app zit in je hoofd. Je weet welke delen kwetsbaar zijn, welke delen je nooit helemaal hebt afgemaakt, welke delen een gebruiker ooit bijna brak. Zij niet.

Overhandig ze een stuk. Een echt stuk, met randen:

De homepage en marketingpagina’s. Laag risico, hoge zichtbaarheid. Ze kunnen itereren op tekst, secties, screenshots, testimonials. Als ze iets breken, merk je het binnen een uur en raakt geen gebruiker data kwijt.
Het helpcentrum. Als je steeds dezelfde vragen beantwoordt, is dit het stuk. Zij schrijven de antwoorden; jij beoordeelt de eerste paar tot je de stem vertrouwt; dan lanceren ze.
Eén specifieke gebruikersgerichte functie. Misschien is het de exportflow, of het reactiesysteem, of de meldingen. Iets met een schone grens, waar een bug erin niet de hele app neerhaalt.
De beheerderstools die je zelf gebruikt. Een verrassend goed startstuk. Ze kunnen de tools verbeteren die je gebruikt zonder iets aan te raken dat klanten zien. Jij voelt de verbeteringen dagelijks, wat vertrouwen opbouwt.

De vorm van het stuk doet er minder toe dan het feit dat het een stuk is. Zij bezitten het. Jij twijfelt niet aan elke wijziging. Jullie spreken een check-in-cadans af en laat ze werken.

Wat je niet moet doen op dag één

Een korte lijst, voornamelijk van anderen dit slecht zien doen:

Geef ze geen toegang tot je live database. De meeste AI-appbouwers laten je een staging-kopie van je app maken. Begin ze daar. De dag dat ze hun eerste ding naar productie lanceren, zou een kleine ceremonie moeten zijn, geen ongeluk.
Stort niet alles op hun schoot. “Hier is een Notion-doc met 87 dingen, kies maar.” Dit is overweldigend en ze haken af. Kies samen de eerste drie dingen. Maak die af. Kies dan de volgende drie.
Verwacht niet dat ze je gedachten lezen. Je leeft al maanden met deze app. Je hebt voor alles een afkorting. Schrijf vijf dingen op over hoe de app werkt en hoe je er beslissingen over maakt. Overhandig ze dat. Het kost je negentig minuten en bespaart je weken.
Verdwijn niet. Ze hebben je nodig voor de eerste paar weken. Stel een echte cadans in — een snel gesprek eens per week, async berichten ertussen. Na een maand kun je waarschijnlijk terug naar om de week. Niet eerder.

Hoe het echt voelt daarna

De meeste solo-bouwers zijn verrast, de eerste keer dat ze iemand uitnodigen, door hoeveel energie ze terugkrijgen. Niet omdat de andere persoon snel is — dat zijn ze waarschijnlijk niet, in het begin — maar omdat de helft van je zorg ging over de dingen waar je niet aan toekwam. Zodra iemand anders eraan toekomt, verschuift de zorg.

Je merkt ook dat je app minder kwetsbaar begint te voelen. Twee mensen die een systeem begrijpen, zijn meer dan twee keer zo veerkrachtig als één. De busfactor gaat van één naar twee, wat als een klein ding klinkt tot de week waarin je laptop sterft en iemand anders nog steeds kan lanceren.

Als je met een lange lijst van “dingen die ik zou doen als ik tijd had” zit, is het misschien de moeite waard om vandaag een uur te besteden aan nadenken over wie die eerste persoon zou kunnen zijn, en welk stuk van je met AI gebouwde app je ze zou overhandigen.

Het is meestal minder van een sprong dan het lijkt.