424 GitHub Repos: Idea Hoarding or Strategy?

TL;DR

As of May 17, 2026: 424 repos. 367 not archived. 154 new in 2026. 15 deployed on Cloudflare Pages. The number is not the goal. It is the sediment of a working pattern: one idea, one repo, reality-check before discussion. This post shows the telemetry, the three heuristics I use to decide which repo lives, and the conditions under which this makes sense for someone else. Spoiler: for most people, it does not.

Featured image placeholder: stylized grid of repo cards in northern German palette. Asset pending — prompt at end of post.

Table of Contents

• Raw telemetry
• How 424 repos distribute across 30 years
• Three heuristics: when a repo lives
• What most people get wrong
• When does this make sense for you?
• What it actually costs
• FAQ

Raw telemetry

The number 424 scares people. Per anecdote in the Hacker News thread on 500+ repositories and the broader feel from GitHub’s repository limits docs, the average active developer sits around 10-30 repos. So 424 is a factor of 14-40× over a typical count. That deserves explanation.

How 424 repos distribute across 30 years

The most important correction first: 154 of these 424 repos are new in 2026. Not across 30 years — across four and a half months. The pattern is not a career-long accumulation. It is the consequence of the move from architect (15 years of IBM/PwC) to indie builder (since 2024), plus agentic coding tools that make creating a new repo cheaper than opening a branch.

Inline image placeholder: bar chart of repos created per year 2010-2026. Steep curve from 2024. Asset pending.

Creating a repo costs me about 30 seconds today:

gh repo create moinsen-dev/idea-name --private --clone
cd idea-name && cursor . && claude code

A branch costs more mental overhead: it lives inside an existing project’s context, with its conventions, its CLAUDE.md, its open issues. A new repo is clean. If the idea is dead after 90 minutes, I archive the repo and none of the context-pollution stays.

That is the thesis of the post. Everything else is consequence.

Three heuristics: when a repo lives

Not every repo stays active. The 57 archived out of 424 are not random — they follow three rules I learned the hard way.

Heuristic 1: 7-day reality-check

A new repo gets 7 days of daily attention. After day 7, if there is no clear “yes, there is a real question here that I want to answer,” it gets archived. Not deleted — archived. (Important distinction. More in the FAQ.)

This filters out vibe-coding one-day flies. Andrej Karpathy’s vibe coding concept is great for idea generation, dangerous when the idea is allowed to breathe for longer than 7 days without substance.

Heuristic 2: 30-day silence sweep

Every non-archived repo that has had no commits in 30 days lands on a weekly list. Three options per entry:

1. “Frozen on purpose — coming back” → tag frozen, removed from the list
2. “Dead, I just didn’t want to admit it” → archive
3. “Lives only in my head” → update the README with one paragraph, tag dormant

This heuristic separates honest pauses from creeping bottleneck.

Heuristic 3: Annual December sweep

Once a year — usually between Christmas and New Year’s — I walk through every repo with no commits in over 12 months. Default: archive. Exceptions must be actively justified.

Inline image placeholder: decision tree (new → 7-day check → 30-day sweep → annual sweep). Asset pending.

The result after three years of these heuristics: 13.4% archive rate (57 of 424). That sounds low — it is, because 2026 is the first year I have enforced the heuristics consistently. Expectation for 2027: ~25-30% archive rate, once the 154 fresh 2026 repos pass through the filters.

What most people get wrong

The most common reaction to “424 repos” is one of two wrong assumptions:

Wrong 1: “That is hoarding.” Hoarding has an emotional component — attachment, FOMO, fear of gaps. This is the opposite. A repo is a disposable container. The attachment is to the idea, not the code. If the idea was wrong, the code goes away. The code was cheap; the answer is valuable: “This idea died on day 30 because the market problem was not real.” That learning velocity is the point.

Wrong 2: “That is strategy.” Strategy has a forward-looking component — “in three years I will have turned 12 of these repos into products.” This is not that either. I do not know today which of the 154 repos from 2026 will still be alive in two years. That is part of the method. If I knew, I would not need to start 154 repos — three would suffice.

The right description sits in between: a cheap option machine. Each repo is a 30-second option on a possible future idea. Most expire worthless. The few that do not are the products. Bonblick, Food Designer, AI Trader, Conductor — all emerged from this option machine, not from forward-looking planning.

Inline image placeholder: loop diagram (idea at top → repo → 7-day reality-check → branching into product path or archive path). Asset pending.

When does this make sense for you?

Three conditions must hold simultaneously:

1. You have agentic coding tools in your stack. Without Claude Code, Cursor, GitHub Copilot, or similar, the repo initialization overhead is too high. Without them a new repo does not cost 30 seconds but 30 minutes — and the whole logic falls apart.
2. You are 100% self-directed about your repo setup. If you work at a company that centrally approves repos: forget it. The heuristic requires frictionless creation AND archiving.
3. You are comfortable with thrown-away code. If you mourn every repo that gets archived, you build a hoarding layer on top of the heuristic and sabotage it. The northern German background helps — “Dat is dood, dann wegg” (if it is dead, then gone) is a cultural disposition.

If even one of these three conditions is missing: fewer repos are better. Pieter Levels, probably the most well-known solo founder with many small products, runs ~10-12 active projects. That is the other scale — works for him because each project is revenue-active. The bulk of my 154 fresh 2026 repos are pre-revenue. Different optimization function.

What it actually costs

Honest cost section, because most people underestimate the invisible costs.

The dollar cost is irrelevant (~€170/year for the entire infrastructure). The real cost is context switching. Conductor v8.1.0 with its knowhow plugin (see prior post) is the primary counter — without it I could not hold 8 parallel projects.

What it does not cost: recruiter perception. In 30 years of senior-track career I have learned that no serious tech recruiter scans 424 repos. They scan 1-3 pinned repos. As long as those have real substance (READMEs, CI, tests), the total count does not matter. Source: lived experience, not study.

Where this goes next

Three open issues where the method currently strains:

1. Cross-repo refactoring. When one API change has to land in 12 repos in parallel, heuristic 2 breaks down — none of them has 30 days of silence, but all need attention at the same time. Conductor v9 will address this.
2. Auto telemetry. The table above was generated manually from the GitHub API. I do not yet have a dashboard that shows me each repo’s lifecycle position daily.
3. Public vs private mix. Currently most of my 367 living repos are private. That is defensive, especially for experiments. But if I want to build open source authority (Wikipedia notability, citation surface in AI engines), a larger share needs to be public. Plan: 2026/2027, make ~30-50 selected repos public.

If you run a similar repo strategy or want to attack the system: reach me on LinkedIn or GitHub. I trade notes happily.

FAQ

How many GitHub repositories should I have?

There is no ideal number. The right question is: how fast is your idea-reality-check loop? If you use agentic coding tools and can frictionlessly create and archive repos, 50-400 is normal. If not, 5-20 is normal.

What does GitHub Pro cost?

$4/month (~$48/year). For most indie builders the free tier is enough — Pro is only needed for GitHub Codespaces and unlimited private repos in organization accounts. Current pricing on github.com/pricing.

Should I delete or archive old repos?

Archive, not delete. Archiving keeps the history (useful if the idea becomes relevant again in two years) and removes the repo from the active list. Deletion is destructive and removes branch refs, stars, issues. I have not deleted a single repo since 2024.

Does it make sense to put small experiments in their own repo instead of branches?

If the experiment is independent of the main project: yes, own repo. If it is a variation of the main project: branch. Heuristic: could this experiment become a product in six months? → repo. Is it a feature variation? → branch.

How does a high repo count affect job applications?

Practically not at all. Recruiters look at 1-3 pinned repos, not the total count. More important: the pinned repos need a clear README, CI, and tests. David’s indie dev toolkit is a good reference for what a pinned repo should look like.

Written on May 17, 2026 in Hamburg. The telemetry is a snapshot for that date — the count keeps growing. If you find this post useful, link to it — that helps others find it too.