Wanneer je je met AI gebouwde app opnieuw bouwt (en wanneer je blijft itereren)

De app die zijwaarts groeide

Maria begon met het bouwen van een eenvoudig intakeformulier voor klanten. Zes maanden later had ze afsprakenplanning, een betaalpagina, geautomatiseerde herinneringsmails, een notitiesgedeelte voor elke klant, en een dashboard dat bijhield hoeveel mensen die week hadden geboekt. Het werkte, grotendeels. Maar elk nieuw ding dat ze toevoegde, leek iets anders te breken. Het notitiesgedeelte toevoegen zorgde dat de boekingsflow niet goed meer opsloeg. De boekingsflow repareren brak de herinneringen.

Ze vroeg me: “Op welk punt zou ik gewoon opnieuw moeten beginnen?”

Het eerlijke antwoord is: niet zo vaak als je denkt, maar er zijn specifieke tekenen die de zaak voor een herbouw moeilijk te weerleggen maken.

Waarom herbouwen verleidelijk voelt (zelfs als het verkeerd is)

Wanneer een app traag wordt, of zich onvoorspelbaar begint te gedragen, of er gewoon niet meer uitziet zoals je wilt — is de drang om hem te schrappen en vers te beginnen. Schone lei. Geen van de oude ballast.

Die drang is meestal verkeerd.

Herbouwen kost langer dan mensen verwachten. Je verliest alle randgevallen die je huidige app stilletjes heeft opgelost. Je verliest de vertrouwdheid die je hebt opgebouwd met hoe het ding werkt. En je herbouwt vaak dezelfde structurele problemen, omdat het echte probleem niet de app was — het was het gebrek aan helderheid over wat de app verondersteld werd te doen.

De meeste met AI gebouwde apps kunnen worden gered door iteratie. Een goede AI-appbouwer kan een verwarrend datamodel herstructureren, een verwarde pagina vereenvoudigen, of een functie opruimen die uit de hand groeide. Wat ertoe doet, is weten wanneer je in “repareer het”-gebied zit versus “begin opnieuw”-gebied.

Drie tekenen dat je echt opnieuw moet bouwen

1. Het kernidee veranderde, niet alleen de functies

Als je begon met het bouwen van een intaketool voor klanten en je nu een B2B-SaaS wilt met abonnementen, gebruikersteams en een openbare marktplaats — dan is dat een andere app. Dezelfde technologie, compleet ander product. Proberen de een in de ander te transformeren door functies te stapelen, is als een fiets in een auto veranderen door onderdelen toe te voegen. Je eindigt met iets dat geen van beide is.

De vraag om te stellen: Zou ik deze app op dezelfde manier beschrijven als toen ik hem voor het eerst bouwde?

Als het antwoord nee is — als de naam, het publiek en de kernwaarde allemaal anders zijn dan wat je oorspronkelijk bouwde — is een herbouw waarschijnlijk de juiste zet. Je mag dan ontwerpen voor wat je echt wilt in plaats van rondom te lappen wat je voor iets anders bouwde.

2. De AI kan zijn weg niet meer vinden in de app

Dit is een praktisch signaal, geen filosofisch. AI-appbouwers werken door de bestaande structuur van je app te lezen en wijzigingen te maken. Wanneer een app vele malen is gelapt, wordt de structuur inconsistent — data leeft op onverwachte plekken, pagina’s verwijzen op omslachtige manieren naar dingen, knoppen zijn verbonden met logica die van andere knoppen werd gekopieerd en nooit werd opgeruimd.

Wanneer je merkt dat elke wijziging iets ongerelateerds breekt, of de AI steeds dezelfde fout maakt (zoals verkeerd identificeren bij welk deel van de app een functie hoort), ben je misschien in “structurele schuld”-gebied beland.

Een herbouw lost dit niet als bij toverslag op — maar het laat je vanaf het begin schoon bouwen met het volledige plaatje in gedachten.

3. De app heeft gebruikers maar houdt ze tegen

Als echte mensen je app gebruiken en je steeds tegen dezelfde muur loopt — “we hebben X nodig maar er is geen manier om het toe te voegen zonder alles opnieuw te doen” — dan is dat een legitiem herbouwsignaal. Niet omdat de app slecht is, maar omdat hij was gebouwd voor een kleinere versie van het probleem dan je echt moet oplossen.

Dit is een goed probleem om te hebben. Het betekent dat de app goed genoeg werkte dat mensen hem serieus gebruiken. Een herbouw in dit stadium is geen mislukking — het is een afstuderen.

Wat te doen voordat je herbouwt

Zelfs als je besloten hebt te herbouwen, doe dit eerst:

Schrijf op wat werkte. Loop je huidige app door en maak een lijst van alles wat gebruikers echt gebruiken. Deze functies hebben bewezen vraag. Ze zouden vanaf dag één in de nieuwe app moeten zitten.

Schrijf op wat problemen veroorzaakte. Niet alleen “dit was traag” of “dit brak veel” — wees specifiek. “De notitiesfunctie botste met de boekingsflow omdat ze allebei data in hetzelfde gebruikersrecord opsloegen.” Je wilt de lessen meenemen, niet de code.

Stel een scope-limiet voor de herbouw. Het grootste risico bij herbouwen is scope creep. Je besluit alles opnieuw te doen, en twee maanden later ben je nog steeds niet klaar omdat je steeds “nu we toch bezig zijn”-functies toevoegt. De herbouw zou de werkende functies van de oude app moeten lanceren plus de een of twee dingen die echt geblokkeerd waren. Al het andere wordt daarna toegevoegd.

Wanneer je blijft itereren (meestal)

Je app laadt traag? Itereer — dat is meestal een dataquery-probleem of te veel dingen die tegelijk laden.

Je ontwerp ziet er gedateerd uit? Itereer — een ontwerpopfrissing is 100% haalbaar in een AI-bouwer zonder de onderliggende logica aan te raken.

Een kernfunctie voelt onhandig? Itereer — herbouw alleen die functie, niet de hele app.

Je voegde te veel functies toe en dingen voelen verspreid? Itereer — functies verwijderen en de navigatie vereenvoudigen is veel sneller dan een volledige herbouw, en vaak effectiever.

De vuistregel: als het datamodel nog steeds logisch is voor wat je probeert te doen, itereer. Als het datamodel de verkeerde vorm heeft voor het product, herbouw.

Maria’s app

We doorliepen haar app samen. De kernstructuur — klanten, afspraken, betalingen — was eigenlijk prima. De rommel kwam van een notitiesfunctie die was aangebout op een manier die botste met hoe klantrecords werden opgeslagen.

In plaats van te herbouwen, vertelde ze de AI-bouwer precies wat er gebeurde: “Het notitiesgedeelte en de boekingsflow slaan informatie op in overlappende plekken, en het veroorzaakt conflicten. Ik wil notities herstructureren zodat ze volledig gescheiden zijn van het boekingsrecord.” Twee sessies later was het gerepareerd. De rest van de app bleef intact.

Zes maanden aan opgebouwde functies, niet verloren.

De echte vraag

Voordat je besluit te herbouwen, vraag: Zit het probleem bij de app, of bij mijn helderheid over wat de app zou moeten doen?

Meestal is het antwoord helderheid. En helderheid vereist geen herbouw. Het vereist alleen specifiek zijn tegen je AI-bouwer over wat je echt wilt.

Begin daar. Herbouwen is altijd beschikbaar. Het is er over een week nog steeds.

Als je probeert uit te vogelen wat je app echt nodig heeft — of dat nu een aanpassing of een verse start is — is Proyecta een goede plek om het te overdenken. Bouw iets kleins, zie wat standhoudt, en groei vanaf daar.