VibeSoft Studio is op 12 augustus 2026 officieel ingeschreven bij de Kamer van Koophandel (KvK), maar de oudste repo in de projectenmap gaat terug tot 11 mei. Sindsdien heeft de map ongeveer 2.250 commits verzameld, verdeeld over 16 repositories, allemaal onder C:\Claude\Projects en bijna allemaal geschreven met Claude als typist. Zes van de repo's zijn Android-apps, meerdere zijn webapps, en één is deze website. Dit artikel legt uit hoe die map is ingedeeld, hoe het zover is gekomen en welke onderdelen nog niet bewezen zijn.
De korte versie: elk project heeft dezelfde bestanden onder dezelfde kopjes, alles wat bij geen enkel product hoort staat in een map die met een underscore begint, het werk wordt gepland in sprints van een week vanuit één gedeelde kalender, en een regelbestand dat Claude aan het begin van elke sessie leest, houdt het geheel bij elkaar. Niets hiervan is vooraf ontworpen. Het is stap voor stap toegevoegd, telkens na een ontdekking.
Hoe het begon, zonder plan
De eerste commit is gedateerd op 11 mei 2026, drie maanden voordat het bedrijf werd ingeschreven. Die kwam terecht in wat CryptoPro Trader werd, een geautomatiseerde paper-trading-agent. Vier andere CryptoPro-repo's volgden: een cursus op 30 mei, een grafiekapp op 13 juni, de Suite op 18 juli en een mobiele webapp op 9 augustus. Eind juli stonden de eerste vier samen in één CryptoPro-map.
Op 12 augustus werd het bedrijf ingeschreven bij de KvK, en de eerste commit van het volgende project, Bubble News, is van diezelfde dag. Vanaf dat moment veranderde het tempo. Tussen 12 augustus en 30 september werden tien repo's gestart, tien in zeven weken: Bubble News, Bubble Media, Pendulum Path, Trainbell, Bubble Crime, Bimblesound Nights, BlindsMate, Lyntiq AI, Boekhoud Agent en X Marketing. Niemand had op zestien gerekend.
De rommel is makkelijk op te sommen, want het validatierapport van 28 september heeft hem geteld. De roadmap heette in de ene repo roadmap.md, in een andere trainbell-roadmap.md, in een derde bimblesound-nights-roadmap.md en in een vierde ROADMAP-MOON.md. Vier projecten hadden geen versiebestand. Git remotes waren vernoemd naar het project in plaats van origin. Eén repo ging 27 dagen zonder commit en droeg 13 niet-gecommitte bestanden mee. Hetzelfde databasebestand van 1,5 MB dook op in acht mappen en was in één repo gecommit, en het overleefde zes wekelijkse rapporten. Verouderde git-lockbestanden stapelden zich op en moesten uit de weg worden verplaatst.
Elk van deze dingen is klein. Samen betekenden ze dat een nieuwe Claude-sessie, of een ontwikkelaar die na twee weken terugkeert, niet kon voorspellen waar iets stond.
De map laten groeien
Groepsmappen kwamen als eerste. CryptoPro bevat zijn vijf repo's, Bubbles bevat de drie bubble-board-apps en VibeSoft Studio bevat de bedrijfswebsite. Rabbit Hole Conviction is een conceptmap met notities en zonder repo. Elk ander product heeft een eigen map.
De tweede soort rommel was moeilijker te zien: dingen die bij geen enkel product horen. Android-ondertekeningssleutels, Play Store-afbeeldingen, de studiologo's, back-ups, een commit hook, een projectstarter. Sommige waren begonnen als bestanden in de repo die ze als eerste nodig had. Bubble Crime bijvoorbeeld had op 28 september nog tien definitieve storeafbeeldingen in zijn designmap staan, hoewel de regels zeggen dat ze in _store-assets horen. Zeven van deze gedeelde mappen zijn aangemaakt tussen 26 augustus en 9 september, en een achtste volgde op 4 oktober. Hun namen beginnen met een underscore, dus in één oogopslag zie je op de maplijst het verschil tussen een product en een gedeeld hulpmiddel.
De herstructurering, op volgorde
27 en 28 augustus: de projectstarter en de gedeelde commit hook. De starter is een werkend voorbeeld van een nieuw project, en de hook is één script dat in elke repo is gekopieerd. Het weigert een commit waarin een keystore, een logbestand, een databasebestand of een secret is gestaged, die een lange streep (em dash) toevoegt (onze schrijfregels verbieden die), of die de lint niet doorstaat.
Vanaf 28 augustus: een validatierapport dat elke repo toetst aan het regelbestand. Het draait elke maandag en geeft elk project een oordeel PASS, PARTIAL of FAIL met het belangrijkste probleem. Alles wat het vindt, komt op een chore-branch.
29 september: de branchregel. Toen stond elk product op twee na in productie, dus main is productie: een push naar main deployt de website of de app-backend op Vercel, en Android-bundles worden ervan gebouwd. Roadmapwerk verhuisde daarom naar branches, één per roadmapfase. Voordat Claude in een repo code aanraakt, zegt het regelbestand dat het eerst git branch --show-current moet draaien.
2 oktober: één documentstandaard voor alle 16 repo's. Elke repo heeft een CLAUDE.md (regels en beslissingen voor Claude), een README.md (voor iemand die de repo kloont), een ROADMAP.md (alleen openstaand werk), een BUILD-STATUS.md (de huidige stand, geen dagboek), een version.json en een docs-map. De kopjes zijn in elk project hetzelfde, dus een sessie kan elke repo zonder voorkennis openen en weet waar alles staat. Twee kleine scripts controleren de structuur en tonen elke alinea die na een herschrijving uit de laatste commit is verdwenen.
3 en 4 oktober: het gedeelde regelbestand, de sprintkalender en de lijst met open punten verhuisden naar z-planning, een kleine git-repo op zichzelf, zodat een wijziging in een regel een geschiedenis heeft zoals elke andere wijziging. De git remotes die naar het project waren vernoemd, kregen de naam origin. De studiologo's verhuisden uit de map VibeSoft Studio naar het bovenste niveau als _assets.
Wat elke map met een underscore doet
_assets bevat de huisstijlbestanden van de studio: logo's met en zonder tekst, een banner en de favicons.
_backup bevat een script dat elk bestand dat niet naar git is gecommit kopieert naar een back-upmap die met de cloud synchroniseert, behalve buildafval zoals node_modules, met behoud van de mapstructuur. Gecommit werk is al veilig in git, dus alleen de rest die niet is gecommit heeft een tweede kopie nodig. Het bevat ook JSON-exports van twee databases, gemaakt voor een schemaverhuizing op 1 oktober.
_hooks bevat de gedeelde commit hook, het script dat de documenten van een project toetst aan de standaard en het script dat alinea's opsomt die bij een herschrijving verloren zijn gegaan.
_keystore bevat de Android-uploadsleutel van elke app en andere secrets die nooit in een repo mogen komen. De naam is smaller dan de inhoud: er staan ook environment-bestanden in die op 27 september uit vier repo's zijn gehaald.
_skills bevat herbruikbare instructies voor Claude die voor meer dan één project gelden. De enige tot nu toe is een recept voor een productdemo in acht stappen: script, zelfstandige interface, compositie, opname, bijschriften en voice-over, geluid, muziek en montage.
_store-assets bevat het afgeronde Google Play-materiaal van elke app: icoon, feature graphic, screenshots, teksten voor de storepagina in meerdere talen en video's. De submappen zijn genummerd in de volgorde waarin de projecten zijn toegevoegd, en de repo's bewaren alleen de scripts en bronnen waarmee de afbeeldingen opnieuw worden gegenereerd.
_template bevat het startpunt voor een nieuw project: de set documenten met lege kopjes, een web- en Android-opzet met lint- en testconfiguratie, een Vercel-configuratie en een indeling voor store-assets.
_to_delete bevat alles wat dood lijkt. Niets wordt meteen verwijderd, het verhuist eerst hierheen. Op 28 september stonden er 28 items in en nu zijn het er ongeveer 40: verouderde git-lockbestanden, half geschreven git-objecten, een oude kopie van de broncode van een nieuwsapp en de map van een project dat we hebben laten vallen.
Eén map doorbreekt het patroon met opzet. z-planning heeft geen underscore omdat het geen opslag is maar de controlekamer: het regelbestand, de sprintkalender, de lijst met open punten, de wekelijkse validatierapporten en de marktanalyse achter de prioriteiten.
Hoe een project wordt opgezet
Een nieuw project begint als een kopie van _template. Git wordt geïnitialiseerd met de .gitignore van de starter en de eerste commit wordt op dag 1 gemaakt, voor ander werk. De commit hook wordt geïnstalleerd, het project krijgt de eerstvolgende vrije lokale poort uit een gedeelde tabel (tot nu toe 5172 tot 5185, waardoor meerdere projecten tegelijk kunnen draaien en testscripts niet ongemerkt de verkeerde app raken), en het krijgt een fasecode van twee letters, zoals TB voor Trainbell.
De startroadmap noemt vijf fasen die elke Android-app doorloopt. Fase 1 is de functioneel complete MVP, fase 2 zijn aankopen en advertenties achter interfaces met test-ID's, fase 3 zijn storeafbeeldingen en teksten voor de storepagina, fase 4 is de interne testtrack, en fase 5 is gesloten testen, daarna productie, met live advertenties.
Elke roadmaprij heeft dezelfde vier kolommen: fase, branch, inhoud en grootte. Een echte rij luidt: TB1, branch feature/tb1-review-prompt, inhoud in-app review-prompt en een beoordelingslink, grootte M. Eén fase is één branch en één pull request. De branch wordt afgesplitst van een actuele main, en nooit gestapeld op een andere branch die nog niet is gemerged. Een fase die te groot is voor een sprint wordt in tweeën gesplitst, zoals cp8a en cp8b. De pull request is een merge commit, zodat de commitberichten van de branch in de changelog blijven staan, en dezelfde pull request verwijdert de afgeronde fase uit de roadmap. De git-geschiedenis is het archief, dus de roadmap bevat alleen openstaand werk.
Hoe sprints werken
Een sprint is een week, van maandag tot en met zondag, en bevat ongeveer 12 uur praktisch werk, binnen een bereik van 10 tot 15. Grootte wordt in diezelfde tijd gemeten: S is ongeveer 3 uur, M ongeveer 6 en L ongeveer 12, een hele sprint. Claude doet de implementatie, dus de uren zijn de tijd van de ontwikkelaar voor aansturen, testen en beslissen, niet voor typen.
Op maandag worden de branches van de sprint afgesplitst van main. Op zondag wordt alles wat aan de definition of done voldoet gemerged, gaan releases de deur uit waar de kalender dat aangeeft, en schuiven onafgeronde fasen door naar de volgende sprint. Opruimwerk dat de validatie van maandag vindt, komt op chore-branches, maar alleen in de uren die de sprint nog over heeft. Een nieuwe feature moet binnen acht weken na de eerste bouwsprint zijn uitgebracht, zodat half afgebouwd werk zich niet opstapelt op branches.
De volgorde van het werk ligt schriftelijk vast. Productiebugs, meldingen van de Play Console en geschonden regels gaan voor. Daarna komt alles wat een app vindbaar maakt, want een goede app bouwen zorgde er niet voor dat iemand hem ontdekte. Die volgorde kwam voort uit een groeireview: de kalender die op 29 september was geschreven, is op 30 september herschreven.
Als een sprint boven het plafond uitkomt, staat dat in het plan. Sprint 2 telt 16 uur tegen een plafond van 15 uur, en de notitie ernaast geeft de reden en de fase die eraf gesplitst wordt als het uitloopt.
Eén roadmap voor zestien projecten
Er zijn drie lagen. Elk project heeft zijn eigen ROADMAP.md met dezelfde kopjes: doel, huidige stand, fasen en branches, bugs, beslissingen en risico's, wat we niet bouwen, en later. Eén bestand, ROADMAP-SPRINTS.md in z-planning, plant elke fase van elk project op één kalender. Het noemt 17 vaste sprints van maandag 5 oktober 2026 tot 31 januari 2027 en 10 voorlopige tot 11 april 2027, en het geeft elk project een fasecode van twee letters, 13 in totaal. De derde laag is TODO.md, voor open punten die bij geen enkele roadmap horen: beslissingen die op een eigenaar wachten, verouderde tekst die is gevonden maar niet is verbeterd, dingen die gecontroleerd moeten worden voordat je erop kunt vertrouwen.
Een feature beweegt in één richting door die lagen. Hij begint als een rij in de roadmap van zijn project, met een code, een branchnaam en een grootte. Hij krijgt een plek in de kalender. Op een maandag wordt zijn branch afgesplitst, op een zondag wordt hij gemerged en wordt zijn rij verwijderd. Alles wat niet is ingepland staat in een geordende backlog, in een lijst met gedegradeerde items met de voorwaarde die ze weer tot leven zou wekken, of in een lijst met geparkeerde items.
Open vragen krijgen dezelfde behandeling. Een tabel met beslissingen noemt de sprint die elke beslissing blokkeert, zodat een vraag die aan het begin van die sprint nog door niemand is beantwoord, zichtbaar de reden is dat de sprint niet kan beginnen.
CryptoPro beslaat vijf repo's, dus de roadmap is één hoofdbestand in de Suite-repo. De andere vier houden een ROADMAP.md met dezelfde kopjes bij die naar het hoofdbestand verwijst, en een fase die meerdere repo's raakt gebruikt in elk daarvan dezelfde branchnaam.
Wat nog niet bewezen is
Sprint 1 begint op 5 oktober 2026, dus de kalender heeft nog geen echte week meegemaakt. De groottes zijn schattingen, en de eerste sprints zullen laten zien hoe ver ze ernaast zitten.
De controles zijn handmatig. Het script dat de documentstandaard controleert, heeft opties nodig die met de hand worden gekozen, en het draait nog niet vanuit de commit hook. Het automatisch maken ervan staat op de lijst met open punten.
Documenten herschrijven laat verweesde resten achter in code. Ongeveer 40 opmerkingen in de trading-repo verwijzen nog naar roadmapnummers die niet meer bestaan, en ze staan op dezelfde lijst.
Het wekelijkse rapport vindt afwijkingen, maar een mens lost ze nog steeds op. _to_delete is het zichtbare bewijs: de map groeit sneller dan hij wordt leeggemaakt.
Wat we eerder zouden doen
Geef elke repo vanaf het tweede project dezelfde bestandsnamen en kopjes, niet pas vanaf het zestiende. De herstructurering van 2 oktober raakte alle 16 repo's op één dag, en de herschrijvingen die ze afdwong zouden goedkoper zijn geweest bij project twee.
Behandel main als productie vanaf de dag dat er iets live gaat, en plan het werk vanaf die dag als branches.
Geef gedeelde dingen een thuis met een naam die zegt dat het geen product is. De underscore kost niets en beantwoordt een vraag telkens als de maplijst wordt geopend.
Houd één kalender aan, bepaal de omvang van werk in uren die je echt hebt, en verwijder afgeronde roadmapitems. De geschiedenis onthoudt ze al.
Als je een vergelijkbare opzet hebt en iets anders doet, horen we dat graag via info@vibesoftstudio.com.