Wanneer je met AI gebouwde app zijn eerste iteratie ontgroeit: refactoren versus herschrijven

Je lanceerde iets. Gebruikers waren er dol op. Nu zijn er tien gebruikers, en ze willen functies die niet bij de oorspronkelijke vorm passen. Je staat op een tweesprong: de app lappen om bij de nieuwe use case te passen, of toegeven dat de eerste versie een prototype was en hem goed bouwen. Het is de vraag die meer kleine projecten doodt dan welke andere ook, want er is geen technisch antwoord — alleen een zakelijk.

Het moment waarop je beseft dat de app succesvol is

De meeste met AI gebouwde apps beginnen als één ding en worden iets anders. Je bouwde een intakeformulier voor klanten voor je coachingpraktijk; nu willen klanten eerdere afspraken zien en zichzelf verzetten. Je bouwde een lead-scoringtool; nu wil je verkoopteam samenvattingen geëxporteerd naar hun CRM. Je bouwde een archiefsysteem; nu willen mensen erin samenwerken.

Elk verzoek is redelijk. Elk ervan trekt de app een beetje weg van wat hij was gebouwd om te zijn. En op een bepaald punt — zes maanden later, of twee maanden, soms twee weken — voel je de frictie. Alles wat je toevoegt, vecht tegen het fundament. Nieuwe functies vereisen “oh, we moeten dat deel eerst herorganiseren”. De app wordt trager. Het duurt langer om dingen te veranderen.

Dat gevoel is je signaal om na te denken over de vraag of dit nog steeds dezelfde app is, of dat je hem ontgroeid bent.

Wat refactoren oplevert en kost

Refactoren betekent dezelfde app houden, maar hem opschonen zodat je er meer bovenop kunt bouwen. Je vraagt je AI-bouwer om de code te herorganiseren, een te ingewikkelde workflow op te splitsen, of een scherm te herontwerpen dat een dumpplaats voor functies is geworden. Het kost een paar uur. Het voegt geen nieuwe functies toe. Het maakt gewoon het fundament sterker.

Wanneer refactoren werkt, is het magie. Je had het gevoel dat je tegen de app vocht; opeens is dat niet meer zo. Je voegt drie nieuwe functies toe in een week die er voorheen drie weken over zouden hebben gedaan.

Maar refactoren werkt alleen als het probleem de vorm is van wat je hebt. Als je een intakeformulier bouwde en gebruikers willen een sneller intakeformulier, is het trage deel refactoren een middag. Als ze een intakeformulier willen dat sneller is en geschiedenis opslaat, is het nog steeds één app, en refactoren kan helpen. Maar als ze afsprakengeschiedenis, agenda-integraties, sms-herinneringen en facturering willen, bouw je geen beter intakeformulier meer — je bouwt de backoffice voor een coachingpraktijk. Dat is een ander product.

Wat herschrijven oplevert en kost

Herschrijven betekent: je leerde wat de app eigenlijk zou moeten zijn, en je gaat hem vanaf nul bouwen met die kennis. Je gooit de eerste versie niet weg — je gebruikers vertrouwen er nog op. Maar je bouwt een nieuwe app vanaf de grond, geïnformeerd door wat de oude je leerde, en migreert dan gebruikers over wanneer hij klaar is.

Herschrijven voelt verspillend. Je bouwde iets, en nu bouw je het opnieuw. Dat zijn de psychologische kosten. De praktische kosten zijn tijd: je besteedt twee tot vier maanden aan de nieuwe versie voordat hij klaar is om gebruikers te migreren. Je hebt de eerste versie niet meer als kruk — je duwt vooruit zonder vangnet.

Maar herschrijven levert je één ding op dat niets anders kan: vrijheid. De nieuwe app wordt niet beperkt door de vorm van de oude. Als het origineel een eenvoudig formulier was en de nieuwe een volledige backoffice zou moeten zijn, ontwerp je daar vanaf het begin voor. Als prestatie ertoe doet, ontwerp je daarvoor. Als beveiliging of integraties of workflow ertoe doen, zijn het geen retrofits — het zijn fundamentele zaken.

De apps die slagen na een herbouw doen het meestal omdat het begrip van het team van het probleem zo ver was verschoven van de oorspronkelijke code dat proberen te lappen was als kleren dragen die niet helemaal passen. Herschrijven betekende voor zichzelf bouwen in plaats van.

Drie vragen om tussen ze te kiezen

Vraag 1: Is de kernvorm nog steeds juist?

Je kernvorm is de een of twee hoofdworkflows die de app definiëren. Voor een coaching-intakeformulier is het “klant vult intake in, coach beoordeelt, coach plant in”. Als je andere workflows toevoegt — facturering, agendabeheer, klantberichten — breid je de kern niet uit, je boutt er zijfuncties aan vast. Dat is een teken dat je een ander product bouwt, wat herschrijven betekent.

Als je variaties van dezelfde kern toevoegt — “intake voor individuen, intake voor teams, intake met aangepaste velden” — is het nog steeds dezelfde app. Refactor en breid hem uit.

Vraag 2: Als je vandaag refactort, hoeveel maanden tot de frictie weer toeslaat?

Wees eerlijk. Als de frictie zes maanden weggaat, is refactoren de juiste zet. Als het over twee maanden weer pijn gaat doen omdat het probleem niet de codevorm is maar het fundament zelf, dan bespaart herschrijven je de valse besparing van twee keer lappen. Vraag je AI-bouwer: “Als we dit opschonen, hoe lang totdat we dit weer moeten doen?” Als het antwoord “waarschijnlijk niet lang” is, is het tijd om te herbouwen.

Vraag 3: Waar vertrouwen je gebruikers eigenlijk op?

Als je drie actieve gebruikers op v1 hebt en je denkt na over herbouwen, kun je ze in een dag of twee verhuizen. Als je vijftig gebruikers hebt die productie-afhankelijk zijn van de huidige app, betekent herschrijven dat je maandenlang beide versies werkend moet houden, wat zijn eigen soort pijn is.

Het pad dat meestal werkt

De meeste oprichters die succesvol herbouwen, doen het parallel: ze houden de oorspronkelijke app draaiende en gebruiken reservecapaciteit om de nieuwe te bouwen. Wanneer de nieuwe functiepariteit heeft met de oude, besteden ze een week aan het migreren van data en gebruikers, en zijn ze klaar.

Het pad dat meestal niet werkt: refactoren, refactoren, refactoren, tot je drie refactors verder beseft dat de architectuur nog steeds verkeerd is, en je nu te geïnvesteerd bent in de “oude” versie om het toe te geven en opnieuw te beginnen.

Het juiste moment om te beslissen

De volgende keer dat je de frictie voelt, vraag jezelf af: “Maak ik deze app beter doen wat hij verondersteld werd te doen? Of vraag ik hem iets te zijn waar hij nooit voor was ontworpen?” Als het het eerste is, refactor. Als het het tweede is, is er geen schaamte in het bouwen van het ding dat hij vanaf het begin had moeten zijn. De meeste succesvolle apps zijn op versie 2 van de kern, niet versie 1.