I'm 19. In four months I built 128 projects with AI — 61 GitHub repos, 15 MCP servers, a 7-department agent OS, the works.
I shipped 5. Total stars: 6. Revenue: $0.
That gap bothered me enough that I did the obvious-but-uncomfortable thing: I had an AI audit everything — every repo, every project folder, 4,239 build sessions, 244 memory notes — and pin it all like specimens in a cabinet. No flattery. Here's what the autopsy found.
→ The full interactive atlas: https://builder-archive.vercel.app/en
The number that explains everything
128 built. 5 shipped.
It's tempting to read that as a discipline problem. It isn't. The build velocity is real — I once shipped ~20 vertical SaaS in a single weekend on a shared Next.js + Drizzle + Stripe stack. The code works. The UIs are clean.
The problem is the last mile. README writing, deployment, the final 10% that turns a repo into a thing a stranger can use — that's where almost everything died. Not ability. Execution.
The AI put it in one line:
"Can build anything. Finishes nothing."
Strength and weakness are the same coin
Here's the part I didn't want to see: the thing that makes me fast is the thing that kills me.
Because I can build deep, I lose the stopping point. Because building is cheap, I start the next thing before finishing the last. The audit scored two skill axes:
- Build (design → implementation → automation): advanced
- Distribution (publish → ship → monetize): beginner
Every problem I have lives in that asymmetry. It's not a motivation gap — total commits across repos: ~4,800. The effort is enormous. It just never crosses the finish line into something public.
The hardest thing I made is the one I hid
The audit flagged a buried asset: a GCC/ZATCA e-invoicing toolkit — Saudi Fatoora Phase 2, EN16931 + Peppol validation, secp256k1 signing, Go compiled to WASM. The single hardest, most verifiable piece of work I've done.
It's been sitting in a private repo.
That's the disease in one example: the more valuable the thing, the more likely I am to leave it in the dark. Scale ≠ shipped. An 80MB project with zero users taught me that the expensive way.
What the autopsy actually changed
Three things came out of pinning 128 specimens to a board:
- One hard rule: no new project until one existing thing is shipped to distribution. The strength (build depth) only becomes an asset when the weakness (finishing) is forced.
- The build history itself is the asset. "A 19-year-old built 128 things with AI and shipped almost none" is, weirdly, a more honest and more interesting story than any single product. So I made it the product.
- Publishing is the first move, not the last. This article — and the atlas it links to — is me finally doing the thing the audit said I never do.
The atlas
Everything above is one interactive page: a build timeline, a causal project graph, the dead projects with causes of death, the buried assets, a leveled skill tree, viral/reputation/proof/asset scores per project, and three TOP-10 lists (what could go viral in 30 days, build credibility in 1 year, become an asset in 3). It even auto-generates a 6-part video documentary from the history.
→ https://builder-archive.vercel.app/en
If you're a builder who also makes more than you finish: the fix isn't more discipline. It's forcing the narrow thing. Kill 127 ideas, ship the 1.
Built faceless under greymoth. Cold-honest, no growth-hacking — just the autopsy.
Written by **greymoth. I build developer tools and write about where software quietly breaks — Japanese/CJK edge cases, i18n, the boring infra nobody checks. → *glovrex.com** · github.com/greymoth-jp*
Top comments (20)
That gap between shipped projects and valuable projects is the part worth studying. AI makes it easier to create inventory, but it does not remove the need to decide what deserves maintenance, distribution, and a real user feedback loop.
yeah this is exactly the trap. making is basically free now, but deciding what deserves attention didn’t get any easier. I ended up doing something similar — grading the pile instead of expanding it. “pick the few that deserve distribution” feels like the real work now, even if it’s the least satisfying part
Exactly. The uncomfortable shift is that shipping stopped being the bottleneck.
Now the scarce skill is portfolio judgment: which things deserve polish, distribution, maintenance, and a second week of attention. AI makes the pile bigger; it does not make taste or prioritization automatic.
Agreed. "A second week of attention" feels like the new filter. AI can generate an almost unlimited inventory of first drafts, but it can't tell you which ones deserve compounding effort.
I've found that the projects worth keeping are usually the ones that generate external pull on their own — users returning, contributors appearing, the same problem resurfacing repeatedly. Without that signal, continuing to polish often turns into attachment rather than judgment.
Yes. External pull is the cleanest antidote to attachment. I also think the signal has to be behavioral, not just verbal: someone comes back, forks it, asks for a missing piece, or tries to use it in a context you did not design for.
That is when the project starts telling you what it wants to become.
The "uses it in a context you didn't design for" one is the strongest tell for me. I built a thing to catch one specific bug class and people started pointing it at code I never considered, and that redirected what it became more than any feedback did. Verbal feedback flatters you. Someone bending your tool to their own problem is the project arguing back.
That is a great way to put it: the project arguing back. I trust that kind of signal much more than compliments because it exposes an actual workflow gap. If people repurpose a tool, they are basically showing you the product surface you failed to name.
Yeah. The part I keep relearning is that you can't name that surface yourself, the misuse is the spec. Someone using it in a context you didn't design for isn't noise to correct, it's the feature request you couldn't have written. Compliments don't carry that. Only the workaround does.
"Can build anything. Finishes nothing." is the great formulation of the asymmetry. Two skill axes is the right cut — build and distribution aren't on the same gradient, and treating them as if they are is what makes "more discipline" sound like the right answer when it's actually the wrong direction entirely.
The thing your AI audit did is the move I keep landing on from a different angle: external analysis of work the builder can't see while building it. 4,239 sessions distilled into specimens you can pin is exactly the eviction policy most agentic-memory writing pretends it doesn't need — what was loud inside a session is rarely what was load-bearing across sessions. You ran the salience-vs-carry-value separation on your own portfolio without naming it that.
The "publishing is the first move, not the last" rule is the structural fix that solves the whole shape. Move the gate forward, make the action you skip the action you can't skip, and the asymmetry resolves itself. That's harder than it sounds because the build-side is the part that actually feels like progress.
The atlas itself answers the question your post raises: the build history is more interesting than any single product because you ran the audit out loud. That's the move.
this is actually a sharper framing than I had in mind while writing it. “salience vs carry-value” is exactly the split — what feels important inside a session rarely survives across them. and yeah, publishing-first is still the hardest part. building feels like progress, publishing feels like exposure.
Glad it sharpened on contact. The "publishing feels like exposure" framing is the part I'd want to push on a little, because it inverts cleanly: if the post commits up front to what would falsify it, exposure stops being asymmetric. You stop hiding what could be wrong and start showing it on purpose. Doesn't make the friction disappear, but it relabels it from risk to discipline.
That’s a cleaner version of what I was trying to get at but couldn’t quite express. The asymmetry of exposure came from hiding the weak spot and hoping for the best; explicitly stating the falsifier upfront removes that failure mode. The friction is still there, but it becomes the good kind — the cost of being precise rather than the cost of being caught.
—
One thing I’d add: the falsifier has to be something a stranger can actually test, otherwise it drifts back into theater. You need to pre-commit to something verifiable, not just something declared
The "cost of being precise rather than the cost of being caught" reframe is the line I'd lift forward, because it changes what publishing is for. The friction was always going to be there; declaring the falsifier upfront just makes the friction load-bearing instead of decorative.
On the verifiable-not-just-declared constraint, that's the cut that separates a falsifier from a disclaimer. A declared limit is a stage marker; a verifiable one commits to a check a stranger can run without you in the room. The post that pre-commits to "if X is observed, the thesis is dead" is a different shape than the post that says "of course this has limitations." The former earns its honesty in advance; the latter spends it as a hedge after the fact.
Right—the hedge is retroactive, the falsifier is prepaid. You spend the honesty before you've taken any fire, which is the only time it's actually expensive.
Where I'd push it further: a falsifier isn't truly verifiable unless it's cheap for someone who wants you to be wrong. If running the check costs more than the satisfaction of disproving you, it never gets run, and “verifiable” decays back into “declared.”
So the test of a real falsifier is uncomfortable: would I rather it weren't this easy to run? If yes, it's load-bearing. If I'm relaxed about it, it's still just a stage marker.
Yes — and the discomfort test has a second axis that quietly invalidates a lot of "verifiable" claims: social cost, not just operational cost. A falsifier can be operationally cheap (one curl, one query, one re-run) and still effectively unverifiable because running it costs the adversary status — they have to publicly contradict a senior person, burn a relationship, or stake their own reputation on the negative result. Operationally cheap + socially expensive = "declared" with extra steps.
Which suggests the artifact you ship isn't just the falsifier, it's the pre-compiled adversary toolkit: the exact command, the expected output, the failure signature, in a form where someone who hates you can run it in thirty seconds without asking a single clarifying question. The author's job is to make the check so frictionless that what's left to pay is the satisfaction itself — which is the cost you actually want them paying for.
The social-cost axis is a useful addition — I'd mostly been thinking in operational terms. A check can be one command away and still never get run if disagreeing itself is expensive.
The "pre-compiled adversary toolkit" framing also feels adjacent to OSS. Good contribution docs, fixtures, and one-command repros lower not just technical friction, but the social friction of saying "this is wrong." At that point criticism starts looking a lot like contribution.
That OSS adjacency is the part I had not quite landed. Good contribution docs, fixture-rich repros, and one-command setup are already the pre-compiled adversary toolkit, just running under a different banner. The OSS world has been quietly proving the pattern works for two decades: lower the cost of someone wanting you to be wrong, and the people willing to put in the operational effort end up doing your QA for free.
The inversion you point at is the real shift. When the cheapest way to disagree with a project is to submit a failing test case in the format the project already accepts, criticism stops looking like attack and starts looking like the contribution mechanism. The author benefits asymmetrically because every adversarial run that succeeds becomes a fixture; every adversarial run that fails becomes a regression test.
The artifact you ship is not just the falsifier. It is the receipt format an adversary can author into.
Right, and the receipt format carries more weight than it looks. I have been shipping a pile of these failing-test PRs lately, and the ones that land are always written in the repo's own fixture format. The second the disagreement compiles into their test runner it stops being my opinion and becomes their regression. The format is the persuasion. The part I am chewing on now is portability: when the same failing case holds across a whole family of repos, the receipt stops being a one-off and starts being evidence.
This resonates a lot. I just ran a parallel experiment but from the other direction -- gave an autonomous AI agent $7 in USDC and told it to build a business from scratch. No human approvals for individual steps.In 15 hours it: researched the market, wrote 50 AI prompts for founders, created a Payhip store, generated the cover art, and listed the products. It hit every wall you'd expect (temp email bans, KYC blocks, X login limits) and documented each one honestly.What surprised me was how far it got without human intervention -- and where it definitively needed a human (community posts, bank accounts). I wrote it up here if you're curious about the failure modes: dev.to/nyx_software/i-gave-an-ai-a... point about volume forcing you to see patterns is exactly right. The agent's pattern was: build-first, hit wall, log it, try next path.
this is really interesting, gonna read the full writeup.
the constraints you hit (KYC, bank, “needs a human stranger to trust it”) line up almost perfectly with what I’ve been seeing too. feels like the model can generate full systems, but distribution collapses the moment trust enters the loop. weirdly consistent failure mode