I Shipped a Component Library. I Have No Idea If Anyone Actually Uses It.
I built a component library. It's called Projex. It's on npm at @manningworks/projex. It does one thing: makes it stupidly easy to put your GitHub repos, npm packages, Product Hunt launches, Gumroad products — all of it — on a portfolio page with stat counters, links, learnings and zero manual updating.
I wrote about building Projex and dogfooding it on dev.to if you want to read the full story.
v1.3.1 is shipped as of this article. It's Public on Github and npm.
Over six hundred people downloaded it last month according to NPM stats.
I have no idea if any of them actually used it.
The Problem I Was Solving
I wanted a portfolio page. I didn't want to manually update it every time I pushed a commit. I wanted live data — GitHub stars, npm downloads, that kind of thing — to just be there.
I looked around. GitHub Readme Stats exists. It's just badges. README generators are for READMEs. Nothing I found did the thing I wanted: a proper portfolio page, shadcn-style, where you own the components, where the data comes from the actual APIs.
So I described the problem to my AI agent and we started building.
That was months ago.
What the Code Review Turned Up
Last week I asked my AI agent to do a proper review. Line by line through the normalisation function, the fetchers, the component API. I wanted it to evaluate code but I also wanted to consider the perspective of a user trying to implement Projex.
It found twelve issues.
Some of them were real problems I'd missed. The error handling was inconsistent — Zod validation throws, but API failures return null and warn. The 400-line normalise function does too much: validation, seven different API calls, field resolution, commits fetching. The TypeScript output types don't match runtime behavior — a github type project can theoretically have Lemon Squeezy revenue stats in the type system even though it never will.
Twelve issues. The code still works. My own Projects page is proof of that.
The issues were real. They were also not the problem.
The Question I Couldn't Answer
I was talking through the findings with my agent and it asked me something I didn't have a good answer for.
"Could you demo this in 60 seconds?"
I sat with that for a while. Here's what getting Projex running actually involves right now:
- Install it
- Write async data fetching code
- Understand that GitHub data only loads at build time, not dev time — the fetches are server-side and only run during a build, so
pnpm devshows empty cards until you actually build - Wire up a server component for the data fetch
- Wire up a client component for search
- Deal with the server/client split
That is not demoable.
I couldn't show you what Projex does in 60 seconds because to see what it does, you have to build something with it. The value is hidden behind implementation.
Six hundred installs tells me people are curious enough to try. It doesn't tell me anyone got to the part where it clicks.
The Thing Blocking Everything
The code isn't the blocker.
The first-time experience is the blocker.
If I can't show someone "install this, add these five lines, here's your live portfolio" in under five minutes, the demo falls apart. If the demo falls apart, Product Hunt doesn't make sense. If PH doesn't make sense, the distribution strategy doesn't work.
I started picturing what the demo would actually look like. Me, a fresh Next.js project, pasting in a snippet and getting a live portfolio back. For that to work, the async fetching and the server/client split have to disappear inside one component. The person using it shouldn't have to know any of that exists.
The thing I need is something like a <ProjectGrid> component. One component that accepts the config, handles the data fetching internally, works with just <ProjectGrid projects={projects} /> in a page.
No manual async. No server/client split. No reading 575 lines of getting-started docs first.
Just add your project details. Here's the grid. Done.
Once that exists, I can screenshot it. Once I can screenshot it, I can demo it. Once I can demo it, I can ship it on PH. The chain is short but it starts with that component.
What I Learned Building in Public With an AI
I don't know if I'm doing this right.
I describe problems to an AI agent. It suggests solutions. We iterate. Sometimes I understand why. Sometimes I just know it works.
The code review was the first time I really sat with what we'd built and asked "but is this good?" Not "does it work?" I know it works. I just hadn't put much thought into whether it was good.
The twelve issues were real. The agent found them faster than I would have. But the question of whether it matters is still mine to answer.
And the answer, I think, is that the library is probably fine. The problem is I've been building a library when I should have been building an experience.
I went back to the getting-started docs after that conversation. Five hundred and seventy-five lines. All necessary, as far as I could tell when I wrote each one. None of it gets a person to the moment where Projex clicks. Nobody stumbles into five hundred lines of setup and comes out thinking "oh, this is what I needed."
The six hundred people who installed it found it because they were already looking. They searched, they read a post, they followed a link. That's a real audience and I'm grateful for it. But they'd already decided they needed something like this before they got there.
This is what I keep posting into the void about. I know people downloaded it. I don't know if any of them got to the part where it clicks.
Same codebase. Different demo.
What I'm Going to Find Out
I'm going to build the <ProjectGrid> component. I'm going to get it to the point where I can open a fresh Next.js project and have a live portfolio in under five minutes.
Then I'm going to actually try to demo it.
I don't know if it'll work. I don't know if 612 installs becomes 6,000 or stays at 612 or drops to zero.
But I know the code isn't the problem anymore.
I think I needed to talk to my AI agent about it to figure that out.