01
Leesbaarheid is niet het echte risico
Slecht leesbare code kost tijd. Een export waar je niet meer in terug kunt, kost een keuze. Die tweede weegt zwaarder.
OneDayBuild, het bouwdagmerk van Appfront
FlutterFlow-code laten beoordelen op kwaliteit
Je hebt in FlutterFlow iets gebouwd dat werkt, je hebt de code geëxporteerd, en nu moet iemand er verder mee. Dan blijkt de export lastig te lezen: namen die nergens op slaan, schermen die uit één lang bestand bestaan, en logica die verspreid staat over plekken waar je hem niet zoekt.
- Eén werkdag
- Werkend prototype
- Code in je eigen repository
01/06
Waarom gegenereerde code er anders uitziet dan handwerk
De export is geschreven voor de machine die hem maakt, niet voor de mens die hem leest.
Een visuele bouwer moet uit een klikbaar model geldige code maken. Dat lukt het best met een vaste vorm: voorspelbare structuren, gegenereerde namen en logica op de plek waar de generator hem kwijt kan. Voor de machine is dat prima. Voor een ontwikkelaar die er drie maanden later een wijziging in moet doen, is het lastig, omdat de aanwijzingen ontbreken die je normaal uit namen en indeling haalt.
Belangrijker dan de leesbaarheid is een structureel punt: exporteren is eenrichtingsverkeer. Je kunt de code uit FlutterFlow halen, maar niet aangepaste code terugzetten in de visuele editor. Zodra je met de hand in de export gaat werken, ben je de editor kwijt en werk je verder als gewoon Flutter-project. Dat is een keuze die je bewust wilt maken, niet een die je overkomt.
De vraag is dus niet of de code mooi is. De vraag is welke van de drie routes bij jou past: doorwerken in FlutterFlow en met de hand alleen aanvullen, de export overnemen en de editor loslaten, of opnieuw beginnen met wat je hebt geleerd.
02
De grens ligt bij je maatwerkcode
Hoe meer eigen code je in de bouwer hebt gehangen, hoe eerder overnemen logischer is dan doorklikken.
03
Opnieuw beginnen is soms goedkoper
Wat je in de bouwer hebt uitgezocht, is de opbrengst. De code is dat niet altijd.
02/06
Wat valt binnen en buiten de bouwdag
Binnen scope
- Een doorloop van je geëxporteerde project met een oordeel per onderdeel: bruikbaar, aanpassen of overdoen.
- Een advies over de route: doorwerken in de bouwer, de export overnemen, of opnieuw beginnen.
- Eén onderdeel dat we die dag daadwerkelijk aanpassen, zodat je ziet wat de route in de praktijk betekent.
- Alles in je eigen repository, met een logboek van de bevindingen.
Buiten scope
- Het volledig herschrijven van je project. Dat is een traject, geen dag.
- Een beveiligingsaudit. We kijken naar bouwbaarheid, niet naar sluitende beveiliging.
- Het oplossen van problemen in je back-end of database.
- Onderhandelen met FlutterFlow over je abonnement of je export.
03/06
Hoe de bouwdag verloopt
- Stap 1
Kijken wat je hebt
Het project, de export en de plekken waar je zelf code hebt toegevoegd.
- Stap 2
De echte vraag scherpstellen
Wil je door in de bouwer, of eruit? Dat bepaalt waar we naar kijken.
- Stap 3
De structuur beoordelen
Waar zit de logica, hoe groot zijn de schermen, en wat gebeurt er als je één ding wilt wijzigen.
- Stap 4
Eén wijziging echt doen
Niet bespreken maar uitvoeren. Dan weet je wat een wijziging kost.
- Stap 5
De routes naast elkaar zetten
Wat kost doorklikken, wat kost overnemen, wat kost opnieuw.
- Stap 6
Vastleggen wat je zou doen
Een advies met de redenen erbij, bruikbaar voor wie het ook uitvoert.
Volgende stap
Twijfel je of je hierop kunt doorbouwen?
Vertel wat je in FlutterFlow hebt gebouwd en waarom je twijfelt. In een korte intake bepalen we of een beoordelingsdag zin heeft en wat we die dag zouden aanpakken.
04/06
Eerlijk over een beoordeling in één dag
- Soms is het antwoord: hou het in de bouwer. Als je nauwelijks eigen code hebt en de app doet wat hij moet doen, is exporteren een oplossing voor een probleem dat je niet hebt.
- Een oordeel is geen verbouwing. Je krijgt een onderbouwd advies en één uitgevoerde wijziging, niet een opgeschoond project.
- Terug kan niet. Zodra je met de hand in de export werkt, kun je niet terug naar de visuele editor. Dat is geen mening maar hoe het werkt.
- Wij zijn geen FlutterFlow-partner. We beoordelen wat er ligt en zeggen wat we zouden doen. Voor vragen over je abonnement of de bouwer zelf ben je bij hen beter af.
05/06
Twee manieren om verder te gaan
De bouwdag maakt je idee aantoonbaar. Wil je daarna doorbouwen naar een volwaardige applicatie, dan doet Appfront dat traject.
Eén bouwdag, OneDayBuild
- Je wilt weten of je op de export kunt doorbouwen voordat iemand er weken in steekt.
- Aan het eind van de dag is er een oordeel per onderdeel, één uitgevoerde wijziging en een advies over de route.
- Één dag, vaste prijs, alles in je eigen repository.
Volledig traject, Appfront
- De route is duidelijk en je wilt de app naar productie brengen.
- Herbouw of doorbouw, koppelingen, beveiliging, beheer en doorontwikkeling.
- Dat traject doet Appfront, met dezelfde mensen.
06/06
Veelgestelde vragen
Kan ik de aangepaste code terugzetten in FlutterFlow?
Nee. Exporteren is eenrichtingsverkeer: je haalt de code eruit, maar de visuele editor kan aangepaste code niet inlezen. Zodra je met de hand gaat werken, werk je verder als gewoon Flutter-project. Dat is de belangrijkste keuze in dit hele vraagstuk, en hij is niet terug te draaien.
Is gegenereerde code slechte code?
Niet per se. Hij is geschreven om betrouwbaar gegenereerd te worden, niet om prettig gelezen te worden. Dat merk je vooral bij wijzigen: je zoekt langer naar de plek waar iets gebeurt. Of dat een probleem is, hangt af van hoeveel je nog wilt veranderen.
Wanneer is opnieuw beginnen verstandiger?
Als het grootste deel van de waarde in wat je hebt geleerd zit en niet in de code zelf. Dat is vaker zo dan mensen denken: de schermen, de flow en de keuzes zijn de opbrengst, en die neem je mee zonder één regel over te nemen.
Kijken jullie ook naar beveiliging?
Niet als audit. We letten op de dingen die tijdens het lezen opvallen, zoals sleutels die in de app staan of een database die te ruim openstaat, en we melden ze. Een echte beveiligingsbeoordeling is een apart traject met een eigen methode.
Wat als we de bouwer gewoon willen blijven gebruiken?
Prima, en soms is dat het advies. Dan kijken we welk deel je met eigen code kunt aanvullen zonder de editor te verliezen, en waar de grens ligt van wat de bouwer aankan. Dat is een nuttiger antwoord dan een oordeel over de exportkwaliteit.
