A while ago I wrote about cutting 80% of Nuxt store boilerplate with one createStore call. That post was about the idea.
This one is not about code. It's about what happened after I had to live with that idea every single day — and what it did to me.
🤫 First, the honest part
Harlemify probably has no users but us.
It's a small Nuxt library I built to solve a real need of our own, and our product DiPhyx runs on it under the hood. It's on npm. It has an MIT license. But I'm not going to pretend a crowd is waiting for my next release.
I am the user. Pretty much the only one. No issues from strangers. No feature requests, no discussions, no angry comments about a breaking change. The download count is mostly my own CI runs waving back at me. The whole "community" fits in a single chair — mine.
For a long time, I thought that meant open source wasn't really for a project like this. The dream — the users, the stars, the pull requests from strangers — clearly wasn't coming. So why write issues, changelogs, and migration notes for an audience of one?
I think a lot of developers stop right here. They look at their small project, see no crowd on the way, and quietly give up on doing it properly.
Then, almost by accident, I started doing the exact opposite.
And it became the most useful habit of my year.
📜 The first small rule
It started with a tiny promise to myself.
I was building a feature in our product, and the library got in my way. Nothing dramatic. Just a small moment where the tool I had built forced me to write something awkward.
The easy move? Patch it right there in the app and keep going. I had done that many times before.
This time, I stopped.
Instead of fixing it in the product, I opened an issue on the library. I wrote down what felt wrong, and why. Then I fixed the library itself, made a release, and went back to the app to use the new version.
It took longer. It felt a little silly, like writing a formal letter to myself. But it stuck. So I turned it into a rule:
When the library makes me write something awkward, I don't patch the app.
I open an issue, fix the library, and release.
That one rule quietly ran the whole project for the next few months. No roadmap, no users telling me what to build next — just me, the product, and the library.
You might call this dogfooding taken to its limit. I think of it as something simpler: self-driven. The whole direction of the project came from one place — me, using it for real.
🔁 The rhythm
After a while, it became a loop I didn't even think about:
- Hit some friction while building the product.
- Open an issue and describe the cause in plain words.
- Fix it, write a few tests, update the docs, ship a release.
- Upgrade the app and delete the old workaround.
Then the next rough edge would show up. And it would start again.
The surprise was step two — writing the issue.
I thought it would be a waste of time. It was the opposite. When you force yourself to explain why something is wrong, before you're allowed to touch the code, you stop fixing the surface and start fixing the real cause.
A lot of my best changes only became clear because I had to write them down first.
Slowly, it added up. Issue after issue, all written by me. Not a single bug report from anyone else. Release after release, several of them full rewrites. The tracker filled up, and every line in it had my name on it.
I don't tell you this to impress anyone. I tell you because it points to a simple idea I didn't expect to find: you can do real open source even when you're the only user. Maybe that's a new way to look at it — open source not as a project waiting for a crowd, but as a craft you can practice in full, even when you're the only one in the room.
💡 A few moments I still remember
Some issues stayed with me. Not because of the code — because of the lesson.
The day my own design broke.
I had decided actions could only be a few fixed names. It looked clean. Then the product needed something my clean idea simply could not express, and the whole thing fell apart. One of my early major versions came from my own product refusing to fit the box I had built for it.
The real world does not care how tidy your design looks.
The option nobody used. Not even me.
One day I noticed I kept turning the same setting off, everywhere. So I counted. Every single place that used it had turned it off. Not one used the default. So I deleted it.
Your own product shows you what's missing — and, just as clearly, what you should never have added.
The bug only a real user could find.
Everything passed in the tests. Then the app broke in a way the tests could never catch, because it only happened in the unpredictable timing of a real screen mounting and unmounting.
Tests are not the same thing as use.
None of these were big or famous. They were small, ordinary problems. But because I took each one seriously, each one made the library a little better — and made me a little better too.
🤔 Why I keep doing this for one user
Here's the question I expect:
Why put this much care into a library only you use? Just patch the app and move on.
And yes — patching the app is always faster today. But that answer measures the wrong thing.
The library was never the only output. The other output — the one that keeps paying me back — is the experience itself.
By running a tiny library as if real people depended on it, I got to practice the whole craft of open source in a place where mistakes are cheap. Over a few months, I got better at:
- Writing a real issue — one that explains the cause, not just the complaint.
- Sizing a change — small, or breaking? — and writing an honest migration note, even when the only person migrating was me.
- Doing the boring parts — tests, docs, changelog — every time, until they stopped feeling like extra work.
- Being bold safely — making a big change, getting it wrong, and fixing it next week with nobody angry at me.
A library nobody depends on turned out to be the safest, most honest training ground I've ever had.
The library getting better was a bonus. The real reward was the practice.
I won't pretend it's perfect, though. I am my own blind spot. Every problem in that tracker is a problem that I happened to hit. The ones I never hit — because of the way I think and build — are simply not on the list.
One real bug report from a stranger would still teach me something none of these did. This habit builds discipline; it can't give me someone else's eyes. But I'd rather build the discipline now, and be ready when those eyes finally show up.
🧭 What I'd tell you
If you keep a small library that powers your own product: don't wait for users before you act like a maintainer.
The roadmap is already being written for you. It's the quiet list of moments where your own product fights you. Every time you sigh and reach for a workaround — that's an issue asking to be written.
The steps are simple:
- Use your tool for real.
- Notice the friction.
- Write down why it's there, before you fix it.
- Ship the fix properly.
- Update your product, and wait for the next rough edge.
So maybe the open-source dream doesn't have to start with a crowd. Maybe it can start with one person, one real project, and the choice to treat it seriously. By that definition, every one of us can do open source — even if we turn out to be the only user it ever has.
My crowd never showed up. And somewhere along the way, I stopped waiting for it.
I just kept using it, kept filing issues, kept shipping. The library grew up. So did I. And that was the whole point.
Harlemify is MIT licensed and lives on GitHub and npm. Try it, star it, break it. And whatever you're building — even for an audience of one — run it like it matters.
Top comments (0)