VibeSoft Studio was officially registered with the Dutch Chamber of Commerce (KvK) on 12 August 2026, but the oldest repo in its projects folder goes back to 11 May. Since then the folder has collected about 2,250 commits across 16 repositories, all of them under C:\Claude\Projects and nearly all of them written with Claude doing the typing. Six of the repos are Android apps, several are web apps, and one is this website. This article explains how that folder is organised, how it got that way, and which parts are still unproven.
The short version: every project has the same files under the same headings, everything that belongs to no single product lives in a folder that starts with an underscore, work is planned in one-week sprints from one shared calendar, and a rules file that Claude reads at the start of every session ties it together. None of this was designed up front. It was added one discovery at a time.
How it started, with no plan
The first commit is dated 11 May 2026, three months before the company was registered. It landed in what became CryptoPro Trader, an automated paper-trading agent. Four more CryptoPro repos followed: a training course on 30 May, a charting app on 13 June, the Suite on 18 July and a mobile web app on 9 August. By late July the first four sat together in one CryptoPro folder.
On 12 August the company was registered at the KvK, and the first commit of the next project, Bubble News, is dated that same day. From then the pace changed. Between 12 August and 30 September ten repos were started, ten in seven weeks: Bubble News, Bubble Media, Pendulum Path, Trainbell, Bubble Crime, Bimblesound Nights, BlindsMate, Lyntiq AI, Boekhoud Agent and X Marketing. Nobody had planned for sixteen.
The mess is easy to list, because the validation report of 28 September counted it. The roadmap was called roadmap.md in one repo, trainbell-roadmap.md in another, bimblesound-nights-roadmap.md in a third and ROADMAP-MOON.md in a fourth. Four projects had no version file. Git remotes were named after the project instead of origin. One repo went 27 days without a commit and carried 13 uncommitted files. The same 1.5 MB database file turned up in eight folders and had been committed in one repo, and it survived six weekly reports. Stale git lock files piled up and had to be moved out of the way.
Each of these is small. Together they meant that a new Claude session, or a developer back after two weeks, could not predict where anything was.
Growing the folder
Group folders came first. CryptoPro holds its five repos, Bubbles holds the three bubble-board apps, and VibeSoft Studio holds the company website. Rabbit Hole Conviction is a concept folder with notes and no repo. Every other product has a folder of its own.
The second kind of clutter was harder to see: things that belong to no product. Android signing keys, Play Store graphics, the studio logos, backups, a commit hook, a project starter. Some had started as files inside whichever repo needed them first. Bubble Crime, for one, still kept ten final store images in its design folder on 28 September, although the rules say they belong in _store-assets. Seven of these shared folders were created between 26 August and 9 September, and an eighth followed on 4 October. Their names start with an underscore, so a glance at the folder list tells a product from a shared tool.
The restructure, in order
27 and 28 August: the project starter and the shared commit hook. The starter is a working example of a new project, and the hook is one script copied into every repo. It refuses a commit that stages a keystore, a log file, a database file or a secret, that adds an em dash (our writing rules ban them), or that fails lint.
28 August onward: a validation report that checks every repo against the rules file. It runs every Monday and gives each project a verdict of PASS, PARTIAL or FAIL with its top issue. Whatever it finds goes onto a chore branch.
29 September: the branch rule. Every product except two was in production by then, so main is production: a push to main deploys the website or app backend on Vercel, and Android bundles are built from it. Roadmap work therefore moved onto branches, one per roadmap phase. Before Claude touches code in any repo, the rules file tells it to run git branch --show-current first.
2 October: one document standard for all 16 repos. Each carries a CLAUDE.md (rules and decisions for Claude), a README.md (for a person cloning the repo), a ROADMAP.md (open work only), a BUILD-STATUS.md (the current state, not a diary), a version.json and a docs folder. The headings are the same in every project, so a session can open any repo cold and know where things are. Two small scripts check the structure and list any paragraph that disappeared from the last commit after a rewrite.
3 and 4 October: the shared rules file, the sprint calendar and the open-items list moved into z-planning, a small git repo of its own, so a change to a rule has history like any other change. The project-named git remotes were renamed to origin. The studio logos moved out of the VibeSoft Studio folder to the top level as _assets.
What each underscore folder does
_assets holds the studio's brand files: logos with and without text, a banner and the favicons.
_backup holds a script that copies every file that is not committed to git, minus build junk such as node_modules, to a cloud-synced backup folder, keeping the folder structure. Committed work is already safe in git, so only the uncommitted rest needs a second copy. It also holds JSON exports of two databases, taken before a schema move on 1 October.
_hooks holds the shared commit hook, the script that checks a project's documents against the standard, and the script that lists paragraphs lost in a rewrite.
_keystore holds the Android upload key for each app and other secrets that must never enter a repo. The name is narrower than the contents: it also holds environment files that were taken out of four repos on 27 September.
_skills holds reusable instructions for Claude that apply to more than one project. The only one so far is a product-demo recipe in eight steps: script, standalone interface, composition, recording, captions and voice-over, sound, music and assembly.
_store-assets holds the finished Google Play material for each app: icon, feature graphic, screenshots, listing text in several languages and videos. The subfolders are numbered in the order the projects were added, and the repos keep only the scripts and sources that regenerate the graphics.
_template holds the starting point for a new project: the document set with empty headings, a web and Android scaffold with lint and test config, a Vercel config, and a layout for store assets.
_to_delete holds anything that looks dead. Nothing is deleted straight away, it moves here first. It had 28 entries on 28 September and has about 40 now: stale git lock files, half-written git objects, an old copy of a news app's source and the folder of a project we dropped.
One folder breaks the pattern on purpose. z-planning has no underscore because it is not storage, it is the control room: the rules file, the sprint calendar, the open-items list, the weekly validation reports and the market analysis behind the priorities.
How a project is set up
A new project starts as a copy of _template. Git is initialised with the starter's .gitignore and the first commit is made on day 1, before any other work. The commit hook is installed, the project takes the next free local port from a shared table (5172 to 5185 so far, which lets several projects run at once and keeps test scripts from silently hitting the wrong app), and it gets a two-letter phase code such as TB for Trainbell.
The starter roadmap lists five phases that every Android app goes through. Phase 1 is the feature-complete MVP, phase 2 is billing and ads behind interfaces with test IDs, phase 3 is store graphics and listing copy, phase 4 is the internal testing track, and phase 5 is closed testing, then production, with live ads.
Every roadmap row has the same four columns: phase, branch, scope and size. A real one reads TB1, branch feature/tb1-review-prompt, scope in-app review prompt and a rate link, size M. One phase is one branch and one pull request. The branch is cut from an up-to-date main, never stacked on another unmerged branch. A phase too big for a sprint is split into two, such as cp8a and cp8b. The pull request is a merge commit, so the branch's commit messages stay in the changelog, and the same pull request deletes the finished phase from the roadmap. Git history is the record, so the roadmap holds open work only.
How sprints work
A sprint is one week, Monday to Sunday, and holds about 12 hours of hands-on time, within a range of 10 to 15. Sizes are measured in that same time: S is about 3 hours, M about 6 and L about 12, a whole sprint. Claude does the implementation, so the hours are the developer's time directing, testing and deciding, not typing.
On Monday the sprint's branches are cut from main. On Sunday whatever passed the definition of done is merged, releases go out where the calendar says so, and unfinished phases move to the next sprint. Hygiene found by the Monday validation goes onto chore branches, but only in hours the sprint has left. A new feature must ship within eight weeks of its first build sprint, which stops half-built work from piling up on branches.
The order of work is fixed in writing. Production bugs, Play Console notices and broken rules come first. After those comes whatever gets an app found, because building a good app did not make anyone discover it. That ordering came out of a growth review: the calendar written on 29 September was rewritten on 30 September.
When a sprint overshoots, the plan says so. Sprint 2 carries 16 hours against a 15-hour ceiling, and the note beside it gives the reason and the phase to split off if it runs long.
One roadmap for sixteen projects
There are three layers. Each project has its own ROADMAP.md with the same headings: goal, current status, phases and branches, bugs, decisions and risks, what we are not building, and later. One file, ROADMAP-SPRINTS.md in z-planning, schedules every phase of every project on a single calendar. It lists 17 firm sprints from Monday 5 October 2026 to 31 January 2027 and 10 provisional ones to 11 April 2027, and it gives every project a two-letter phase code, 13 in all. The third layer is TODO.md, for open items that belong to no single roadmap: decisions waiting for an owner, stale text found and not fixed, things to verify before relying on them.
A feature moves through those layers in one direction. It starts as a row in its project's roadmap with a code, a branch name and a size. It gets a slot in the calendar. On a Monday its branch is cut, on a Sunday it is merged, and its row is deleted. Anything that is not scheduled sits in an ordered backlog, in a demoted list with the gate that would revive it, or in a parked list.
Open questions get the same treatment. A table of decisions names the sprint each one blocks, so a question nobody has answered by the start of that sprint is visibly the reason the sprint cannot start.
CryptoPro spans five repos, so its roadmap is one master file in the Suite repo. The other four keep a ROADMAP.md with the same headings that points to the master, and a phase that touches several repos uses the same branch name in each.
What is not proven yet
Sprint 1 starts on 5 October 2026, so the calendar has not yet met a real week. The sizes are estimates, and the first few sprints will show how far off they are.
The checks are manual. The script that checks the document standard needs its options chosen by hand, and it does not run from the commit hook yet. Making it automatic is on the open-items list.
Rewriting documents leaves orphans in code. About 40 comments in the trading repo still cite roadmap item numbers that no longer exist, and they sit on the same list.
The weekly report finds drift, but a person still fixes it. _to_delete is the visible proof: it grows faster than it is emptied.
What we would do sooner
Give every repo the same file names and headings from the second project, not the sixteenth. The restructure on 2 October touched all 16 repos in one day, and the rewrites it forced would have been cheaper at project two.
Treat main as production the day anything ships, and plan work as branches from that day.
Give shared things a home with a name that says they are not a product. The underscore costs nothing and answers a question every time the folder list is opened.
Keep one calendar, size work in hours you actually have, and delete finished roadmap items. The history already remembers them.
If you run a similar setup and do something differently, we would like to hear about it at info@vibesoftstudio.com.