
I've been there. You build a tiny, beautiful widget. It works perfectly. You're proud of it. So you give it its own GitHub repository. You write a README. You set up CI. You tag a version. You feel like a proper open-source maintainer.
Then you realize: it's 7KB. One source file. Zero runtime dependencies. And nobody else on the planet will ever use it except your own projects.
I did exactly this with a feedback widget I built for Shinkofa. And last week, I killed the standalone repo, moved the 7KB into Shinkofa-Shared/packages/feedback-widget, and felt an immediate sense of relief.
Here's the decision framework I wish I'd had before creating that repo in the first place.
We romanticize small, focused repositories. They feel clean. They feel modular. They feel like we're doing architecture right.
But let's be honest about what a standalone repo actually costs:
The widget was 7KB. Its package.json was bigger than the actual source code.
After this experience, I wrote down three criteria. If you answer "no" to any of them, don't create a standalone repo. Put it in the monorepo.
A standalone repo makes sense when the component evolves on its own schedule — different release cadence, different maintainers, different consumers who don't share your monorepo.
My feedback widget? It changed when the main app changed. Always. Zero external consumers. No independent lifecycle.
Decision: Monorepo.
If your component has complex build steps, cross-platform testing, or deployment to a registry, a separate repo might justify itself.
My widget: one TypeScript file, compiled in 0.3 seconds as part of the main build. No tests beyond what the main app already ran. No deployment — it was bundled into the app.
Decision: Monorepo.
This is the honesty check. If you're creating a standalone repo because it "looks professional" but the code is trivial, you're optimizing for appearance, not engineering.
My widget was clean but trivial. 7KB. One file. Zero dependencies. Giving it its own repo was architectural cosplay.
Decision: Monorepo.
Here's what the actual migration looked like for Shinkofa-Shared/packages/feedback-widget:
# Before: standalone repo
~/repos/shinkofa-feedback-widget/
├── src/
│ └── index.ts # 7KB
├── package.json # 1KB (bigger than the code)
├── tsconfig.json # copied from main project
├── .eslintrc.js # copied from main project
├── .github/
│ └── workflows/
│ └── ci.yml # 40 lines, 90% boilerplate
└── README.md # 2KB (nobody read it)
# After: monorepo package
~/repos/shinkofa-shared/
└── packages/
└── feedback-widget/
├── src/
│ └── index.ts # 7KB (unchanged)
└── package.json # 5 lines, just name + version
I deleted 4 files, moved 1 file, and removed an entire CI pipeline. The widget still works exactly the same. But now:
I'm not anti-standalone-repo. I've worked at Meta with their massive monorepo and at AWS with thousands of polyrepos. Both have their place.
A standalone repo makes sense when:
But for a 7KB widget that only your app uses? No. Just no.
Here's what I learned that surprised me:
The desire to create standalone repos is often a symptom of not trusting your monorepo tooling.
I created that separate repo because I was afraid of coupling. I thought putting everything in one place would make the codebase messy. But the opposite happened — the monorepo forced me to be disciplined about boundaries without the overhead of separate repos.
The widget didn't need independence. It needed a home.
A monorepo with clear package boundaries gives you the best of both worlds: modularity without fragmentation. You get the isolation of separate packages with the discoverability and consistency of a single codebase.
The Ermite Shinkofa

Jay "The Ermite"
Holistic Coach & Consultant — Creator of Shinkofa
Coach and consultant specializing in neurodivergent support (gifted/high-potential, highly sensitive, multipotentialites). 21 years of entrepreneurship, 12 years of coaching. Based in Spain.
Learn more →