Een redding is de opdracht die begint bij symptomen in plaats van bij een functielijst. De app bestaat al, hij is live, en er faalt iets aan: frames vallen weg, sessies breken af, crashes lopen op, releases duren elke cyclus langer — of het team dat hem bouwde antwoordt niet meer. Reddingswerk wordt afgebakend op die symptomen, geordend op ernst, en opgeleverd in een product dat de hele tijd in productie blijft.

Het is ander werk dan een app bouwen, en het bewijs dat telt is anders. Iedereen kan een herbouw beloven; een redding wordt beoordeeld op de vraag of het specifieke ding dat faalt meetbaar ophoudt te falen, zonder te breken wat nog werkt. Daarom begint elke redding die we uitvoeren met een audit en een geschreven plan — en daarom zeggen we het ook wanneer dat plan twee weken fixes voorschrijft in plaats van een herbouw.

De hulpvragen die we aannemen

  • Prestaties — haperen bij het scrollen, stotterende animaties, trage opstart, lijsten die stikken in echte datavolumes
  • Stabiliteit — oplopende crashcijfers, afgebroken sessies, geheugenlekken die pas na minuten echt gebruik opduiken
  • Verweesde overdrachten — het bureau is weg, de repo is onduidelijk, en niemand weet zeker waar de signing keys zijn
  • Door AI gebouwde codebases — een gegenereerd prototype dat echte gebruikers vond en ze nu moet overleven; de audit van AI-code is hiervoor de voordeur
  • Vastgelopen roadmaps — een architectuur waarin elke functie langzamer uitkomt dan de vorige, wat een even echt symptoom is als een crash

De reddingen achter deze pagina

Een live telezorgproduct, gestabiliseerd in productie

YouMi is een online dienst voor psychologische begeleiding waarvan de Flutter-app live stond in beide winkels en faalde precies op datgene waarvoor hij bestond: sessies vielen weg, chatberichten kwamen niet aan, en de navigatiestack lekte zo veel geheugen dat de app tussen schermen crashte. In twee weken herbouwden we de -laag met een echte verbindingslevenscyclus — automatische herverbinding, berichten in de wachtrij bij netwerkwisselingen — voegden we volledige bezorgstatussen toe, en herschreven we de navigatiearchitectuur op de moderne routing-API's van Flutter. De app verliet de winkels geen moment terwijl het gebeurde. In de telezorg is de verbinding het product, en daarom staat die opdracht bovenaan deze pagina: een redding wordt afgemeten aan waarvoor het product bestaat.

Prestaties, bewezen aan de extreme kant

Traag renderen repareren vereist dat je snel renderen hebt gebouwd. Arcana houdt een chat van duizenden streamende markdownberichten vast op 60 fps; ExtraETF houdt zijn framerate vast onder live streamende marktdata. Die plafonds doen ertoe voor reddingswerk omdat ze de diagnose kalibreren: wanneer we jouw app profileren, kennen we het verschil tussen "Flutter kan dit niet" — zelden waar — en "deze storm aan rebuilds is met de juiste afbakening te verhelpen", wat meestal de werkelijke bevinding is.

Hoe een redding verloopt

1. Audit

We nemen de codebase door — architectuur, statebeheer, testdekking, gezondheid van afhankelijkheden — aan de hand van de specifieke symptomen die tot het gesprek leidden, en profileren de app op echte toestellen in plaats van de simulator te vertrouwen. Je krijgt een geschreven bevindingenrapport en een geordend plan. Soms is dat plan twee weken fixes; soms een gefaseerde refactor; af en toe een eerlijk advies om te herbouwen, met de redenering erbij.

2. Stabiliseren

De zwaarste symptomen worden eerst gerepareerd en via gefaseerde uitrol uitgebracht, zodat de verlichting gebruikers al in de eerste releases bereikt in plaats van aan het einde van de opdracht. De app houdt zijn releasecadans — hem bevriezen zou bovenop de storing die je al hebt een tweede leggen: die van je roadmap.

3. Verharden

Fixes krijgen tests om zich heen zodat de fout niet stilletjes kan terugkeren, CI draait ze bij elke wijziging, en crash- en prestatiemonitoring wordt aangesloten om regressies te vangen voordat reviews dat doen. Dit is het verschil tussen een redding en een terugkerende afspraak.

4. Overdragen

De opdracht eindigt met de codebase in een staat die een team kan bezitten — het jouwe, of het onze via teamuitbreiding als je de capaciteit wilt houden. Het bevindingenrapport, het plan en de monitoring blijven hoe dan ook van jou.

De disciplines waar een redding op steunt

Framerate-werk

Prestatieproblemen worden geprofileerd voordat ze worden gerepareerd — op middenklassehardware, onder echte data, met de tijdlijn open. De gebruikelijke bevindingen zijn onbegrensde rebuilds die door de widgetboom golven, lijsten die rijen opnieuw opbouwen die ze zouden moeten hergebruiken, en werk tijdens de build dat ergens anders thuishoort. Prestaties zijn een eigenschap van de engineering, niet van het framework: dezelfde discipline die een chat op 60 fps laat streamen, haalt het stotteren uit een productscherm.

Statebeheer-refactors

Veel falende apps falen structureel: state verspreid over schermen, impliciete afhankelijkheden, één wijziging die uitwaaiert in vijf regressies. We refactoren stapsgewijs — scherm voor scherm, achter tests, terwijl de app blijft uitkomen — in plaats van een herbouw af te kondigen. Het doel is een architectuur waarin de volgende functie goedkoper is dan de vorige — precies het roadmapsymptoom dat zich omkeert.

Realtime betrouwbaarheid

Weggevallen sessies en niet-bezorgde berichten zijn levenscyclusbugs: verbindingen zonder herverbindingsbeleid, berichten zonder bezorgstatussen, sockets die geruisloos sterven wanneer het netwerk wisselt. De fix is een echte verbindingslevenscyclus, één keer gebouwd en met een eigenaar — de discipline die de YouMi-opdracht laat zien, en de reden dat die twee weken kostte in plaats van een kwartaal.

Geheugen en navigatie

Lekken die een app na tien minuten gebruik laten crashen schuilen in vastgehouden schermen, listeners die hun widgets overleven, en navigatiestacks die nooit loslaten wat ze pushen. We herschrijven navigatie op de moderne routing-API's van Flutter waar de architectuur dat vereist — bij YouMi was dat zo — en we verifiëren de fix met geheugenprofielen, niet met optimisme.

Overdrachten na een verdwenen bureau

Een overname begint met archeologie: toegang tot de repository, signing keys, winkelaccounts, backendcontracten die niemand opschreef. We hebben dit herstel eerder uitgevoerd en kennen de valkuilen — keys die alleen op de laptop van een voormalige contractor bestaan, winkelvermeldingen die aan het verkeerde account toebehoren — en het eerste product van de audit is in deze gevallen simpelweg een inventaris van wat je werkelijk in handen hebt. Het is weinig glamoureus werk dat gedaan moet zijn voordat welke engineering dan ook ertoe doet.

Wanneer het werkelijk een herbouw is

Sommige apps zijn bij binnenkomst economisch niet meer te repareren — een architectuur die tegen het framework vecht, afhankelijkheden die jaren achterlopen, geen tests om tijdens het refactoren op terug te vallen. Wanneer de audit dat zegt, zeggen wij het ook, met de redenering op schrift, en wordt het gesprek een afgebakende herbouw, gevoed door alles wat de audit vond. Wat we niet doen is een redding factureren op een codebase waarvan we al weten dat die gesloopt moet worden.

Wat een redding kost

De audit is een opdracht met vaste scope: € 4-12K, hetzelfde volledige auditniveau als gepubliceerd op de pagina Audit van AI-code — de machinerie is identiek, of de code nu door een bureau, een intern team of een model is geschreven. Stabilisatiewerk wordt daarna afgebakend vanuit het geordende plan van de audit, symptoom voor symptoom, zodat je werk in delen goedkeurt in plaats van je blind vast te leggen. Wil je dat de capaciteit daarna blijft, dan geldt het gepubliceerde tarief van teamuitbreiding: € 8-11,2K per senior engineer per maand.

We noemen geen stabilisatieprijzen vóór de audit — een getal zonder de codebase te hebben gezien zou een gok in een net pak zijn, en wie een redding nodig heeft, heeft zich aan precies dat soort offertes meestal al één keer gebrand.

Veelgestelde vragen

Veelgestelde vragen van teams waarvan de Flutter-app in productie faalt.

Ja — een deel van ons best gedocumenteerde werk begon precies zo, waaronder een live telezorgproduct dat we stabiliseerden terwijl het in productie bleef. Een overname begint met een audit van de codebase en een inventaris van wat je werkelijk in handen hebt: toegang tot de repository, signing keys, winkelaccounts, backenddocumentatie. Je krijgt een geschreven bevindingenrapport en een geordend plan voordat er ook maar een herbouwgesprek plaatsvindt, want soms is het antwoord twee weken fixes in plaats van een herbouw — en als dat zo is, zeggen we dat.
Door te profileren voordat we iets veranderen — op middenklassehardware, onder echte datavolumes, met de prestatietijdlijn open. De veelvoorkomende oorzaken zijn onbegrensde widget-rebuilds die door de boom golven, lijsten die rijen opnieuw opbouwen die ze zouden moeten hergebruiken, en zwaar werk dat tijdens de build draait. Flutter zelf is zelden het plafond: het framework houdt 60 frames per seconde vast door streamende, animatierijke schermen wanneer het renderen gedisciplineerd is, dus de fix is vrijwel altijd het werk correct afbakenen in plaats van tegen het framework vechten.
Meestal niet, en de audit is wat die vraag eerlijk beantwoordt. De meeste falende apps hebben specifieke, repareerbare oorzaken — een ontbrekende verbindingslevenscyclus, verspreide state, lekkende navigatie — die een geordende refactor aanpakt terwijl de app blijft uitkomen. Af en toe is een codebase werkelijk economisch niet meer te repareren, en dan zegt de audit dat op schrift, met redenering, en wordt het gesprek een afgebakende herbouw. Wat je van niemand zou moeten accepteren is een herbouwadvies dat is gegeven voordat de code is gelezen.
Toegang tot de repository, een build die draait, en wat er bestaat aan winkelaccounts, signing keys en backenddocumentatie — plus de symptomen zoals jij ze ervaart, in gewone taal. Ontbrekende stukken zijn normaal in reddingssituaties; een deel van de audit bij overdrachten is vaststellen wat je werkelijk in handen hebt en terughalen wat kan. Een actuele productiebuild en toegang tot crashrapportage, als je die hebt, verkorten de diagnose aanzienlijk.
Ja — dat is een ontwerpvoorwaarde van de opdracht, geen hoop. Fixes komen uit via gefaseerde uitrol in volgorde van ernst, zodat gebruikers de verlichting al in de eerste releases voelen, en de app houdt de hele tijd zijn normale releasecadans. We hebben op deze manier een live telezorgproduct gestabiliseerd zonder dat het de winkels verliet. Een redding die vereist dat het product offline gaat is een herbouw met de verkeerde naam, en dat zouden we je in de auditfase vertellen.
Ja, en het is een steeds vaker voorkomende hulpvraag: een gegenereerd prototype vindt echte gebruikers en komt dan in aanraking met de productie, waar beveiligingsgaten, uit de hand lopende API-kosten en architecturaal haastwerk snel aan de oppervlakte komen. Onze audit van AI-code bestaat precies voor dit codebaseprofiel en verloopt hetzelfde als elke reddingsaudit — bevindingenrapport, plan geordend op ernst, dan fixes. Gegenereerde code is niet onrepareerbaar; hij faalt alleen in patronen die we als eerste hebben leren zoeken.

Lees de casestudy van YouMi voor de redding waarop deze pagina is gebouwd, de pagina Audit van AI-code voor de auditmachinerie, of begin bij de pijler Flutter-appontwikkeling.