Indexing the 70 Projects on My MacBook in One Second

The ~/Developer folder on my MacBook weighs 75GB: 11 category folders, 70 projects inside them. The problem? I couldn’t remember what half of them were. What was temp/rkserver again? Why does english-staff exist? Every time I started something new, there was no way to check “didn’t I already build something like this?”

So I built an indexing system. I call it devindex. The headline result: a full scan of all 70 projects takes one second, and the output is a single markdown file.

Decision 1: Don’t make the AI do it

The obvious 2026 answer is “just tell an AI agent to read every folder and summarize.” I considered it — and the math doesn’t work. If an AI crawls 70 projects on every refresh, you burn a pile of tokens each time. Worse, it re-reads the same information over and over.

So I split the roles: whatever a machine can know, a script extracts; only what a machine can’t know goes to AI. Last commit date, branch, uncommitted changes, tech stack (reading package.json and pyproject.toml is enough), deployment traces (vercel.json, Dockerfile…) — all of it already sits in the filesystem, readable with nothing but the Python standard library. The only thing that genuinely needed AI was a one-line description of what each project is — and that’s a one-time cost per project.

Decision 2: Metadata lives next to the project

The real design fork was where to keep the data that can’t be auto-extracted — descriptions, deployment targets. A single central file is convenient at first, but the moment you delete or rename a project it silently drifts out of sync. Ghost entries pile up and nobody notices.

Instead, every project root gets its own .project.toml. Delete the project and its metadata disappears with it. Change where something is deployed while you’re working on it, and you fix the file right there. Consistency is enforced by structure, not discipline.

Decision 3: The scanner never edits a metafile

The scanner’s write permissions are limited to exactly two things: creating a skeleton where no metafile exists, and overwriting its own output, INDEX.md. An existing .project.toml is never touched, under any circumstances.

That invariant makes scans idempotent — run it as many times as you like — and guarantees that whatever a human (or an AI) wrote into a metafile never evaporates. When I seeded the initial descriptions, I ran six Claude Code subagents in parallel across all 70 projects, and the scanner and the agents could touch the same files with zero risk of collision.

The result

~/Developer/INDEX.md now lists all 70 projects sorted by activity (🟢 active / 🟡 quiet / 🔴 dormant), and anything with a missing description or long-neglected uncommitted changes gets flagged automatically in a ⚠️ section. There were side benefits too: the indexing run surfaced five completely empty directories and one pair of projects that turned out to be clones of each other.

And the system immediately became a foundation for something else. The portfolio site you’re reading right now is built from those same 70 .project.toml files as its data source. That’s the next post.