BiohackOS · een project op de standaard
Een grote codebase, één gebruiker
BiohackOS is een Flutter-app die ik voor mezelf bouwde en die inmiddels grotendeels zichzelf bouwt: een fleet agents werkt er ‘s nachts aan door, ik ben projectmanager. De repo staat op zichzelf — eigen issues, eigen grenzen, eigen releasecadans — en haakte als eerste aan op de gedeelde standaard van deSchouwVloot. Daarmee is het de plek waar die standaard zich op echte productcode moet bewijzen in plaats van op een voorbeeld.
De app zelf bestaat uit een paar losse logworkflows — één voor voeding, één voor gewicht, één voor sportprestaties — elk zo kort mogelijk gehouden zodat het geen moeite kost om vol te houden. Los loggen is nooit het doel: het doel is wat zichtbaar wordt zodra die workflows samen genoeg data opleveren. De app leert mee van wat erin komt — verbanden tussen eten en prestatie, gewoontes die pas na weken herhaling als patroon herkenbaar worden, signalen die ik zelf nooit had gezien zonder de workflows naast elkaar te leggen.
De schermen
Een losse pagina, met de aurora eromheen: schakel daar tussen de webapp en de app, en klik zelf door de schermen — net als in de app zelf. De getallen zijn verzonnen; de vorm is echt.
Open de demo →Wat er staat
Eén taal
Dart, boven naar beneden
UI, logica en tests
Actief
Geen prototype
groeit met elke gewoonte die ik meet
Beide lagen
Unit + integratie
apart getest, samen getoetst
Naast de code
Eén spec-module per onderdeel
geen los canvas dat achterloopt
De techniek
flutter
Flutter op zak, webapp op tafel
De app is Android-only en gericht op één telefoon — geen matrix van schermformaten om te bedienen, dus alle aandacht naar wat 'm dóét. State via Riverpod, data via een repository-laag erboven. Daarnaast staat er een webapp voor het werk waar een telefoon te klein voor is: beheren, vergelijken, terugkijken.
supabase
Postgres met een slot per rij
Supabase in eu-central-1, met row level security op auth.uid(). Niet als instelling in de app maar als regel in de database: een query die de verkeerde rij vraagt, krijgt 'm niet — ook niet als de app het per ongeluk vraagt.
allowlist
Eén lijst met bestemmingen
Waar de app naartoe mag praten staat machineleesbaar in de grondwet, en woordelijk gedupliceerd op twee andere plekken zodat elke agent het leest. Een guard in de CI vergelijkt die drie exemplaren bij elke wijziging — uit de pas lopen is een rode build.
keystore
Sleutels buiten de database
Tokens van derden staan in de Android Keystore, nooit in Postgres. De grens loopt op waar iets naartoe kán lekken, niet op hoe gevoelig het voelt.
toolchain
Versies staan vast, en dat wordt gecontroleerd
Flutter, Dart, Node, Java en de Supabase-CLI staan gepind in één manifest. Een doctor controleert dat manifest tegen de échte pin-bronnen, dus "het werkt bij mij" is hier een test die faalt in plaats van een discussie.
Van idee naar app
Elk idee gaat door dezelfde drie trappen. De eerste twee draaien zonder mij; bij de derde lig ik in het pad, en precies daar hoort het ook.
01
Triage
Een nieuw issue wordt vanzelf beoordeeld: hoort dit hier, is het duidelijk, bestaat het al?
automatisch
02
Plan
Een agent schrijft de impactanalyse als comment en ontsteekt daarna zelf de bouw. Een plan dat niemand leest is geen poort, dus die is verplaatst.
automatisch
03
Bouw
Branch, implementatie, PR. Een kleine fix merget op groen; een feature wacht op mijn approval. Daar ligt de poort, één keer, op de plek waar het resultaat te zien is.
ik beslis
Het atelier
Zeven sporen, elk een eigen nacht
De app verbetert terwijl ik slaap
Naast het gewone werk draait er ‘s nachts een klein atelier van autonome agents. Elk spoor heeft een scherp mandaat en levert een pull request — behalve de zaterdag, die kijkt terug en levert alleen issues. Ze bouwen niet door op elkaar en ze mergen zichzelf niet, op de dependency-tak na. Wat overblijft is een stapel werk dat ik 's ochtends beoordeel in plaats van zelf moet bedenken.
- ma · quality — opruimwerk als PR
- di · deps — updates, merget zelf op groen
- wo · optimize — prestatiewerk als PR
- do · design — UI-voorstellen op een eigen tak
- vr · testlab — tests op een eigen tak
- za · retro — issues, geen code
- elke nacht · content — concepten om goed te keuren
Waar de grenzen staan
Er zit gezondheidsdata in deze app, dus de interessante vraag is niet wat 'm kan maar wat 'm niet mag. Die grenzen staan niet in een document dat iedereen vergeet, maar als regels die falen: de database weigert de verkeerde rij, de CI weigert een nieuwe netwerkbestemming, en elke feature komt niet door de poort zonder impactanalyse. Bij een conflict wint de grondwet van het plan, en het plan van de code.
Diezelfde regel geldt voor deze pagina, en daarom hoort hier de kleine letter bij de schermen hierboven. Die komen uit een ontwerpbestand, niet uit de app: elk gewicht, elke macro en elke datum erin is verzonnen. Er staat geen screenshot van de echte app op deze pagina en geen waarde die uit de database is overgetikt — wat je ziet gaat over het bouwwerk, niet over wat erin staat.