Building My First CLI Taught Me More Than I Expected
When I started building GiMan, I thought the hardest part would be writing the code.
I was wrong.
The hardest part was naming it.
My First Two Names Failed
The original name was gitbuddy.
I built the initial version, wrote the README, and prepared everything for npm.
Then I tried to publish it.
npm ERR! 403
Already taken.
Fine.
I renamed everything to gitbro.
Updated the package. Changed the README. Tried again.
npm ERR! 403
Also taken.
After two renames, I settled on GiMan, short for Git Identity Manager.
That experience taught me one lesson I'll never forget:
Always check the name before you build something around it. 😄
Keeping Things Simple
The idea behind GiMan is surprisingly straightforward.
One JSON configuration file acts as the source of truth.
Everything else — Git configs, SSH configuration, and identity mappings — is generated from it.
That kept the architecture simple and made it much easier to add new features later.
The stack itself is nothing unusual:
- TypeScript
- Commander
- Inquirer
- Zod
- fs-extra
The challenge wasn't choosing libraries.
It was making configuration changes safely without breaking files users already had.
Real Users Find Real Bugs
The first version worked.
Then I started using it every day.
That's when the edge cases appeared.
Relative paths behaved differently than expected.
Removing identities left behind stale configuration.
SSH host names needed stricter validation.
Even the version command eventually drifted because I'd hardcoded it once and forgotten about it.
None of these bugs were particularly exciting.
But fixing dozens of tiny paper cuts made a much bigger difference than adding flashy new features.
Today, the tool feels significantly more polished because of all those small improvements.
What I'd Do Differently
Looking back, there are a few things I'd change.
I'd check package names before writing any code.
I'd spend more time thinking about edge cases from the beginning.
And I'd probably ship even earlier.
The first release didn't need every feature I thought it did.
Most improvements only became obvious after using the tool in real projects.
That's something I keep seeing with software projects:
You can speculate about what users need, but actually using the software reveals things you won't think of beforehand.
Why I Love Building Small Tools
GiMan isn't a massive application.
It's a small utility that solves one problem well.
Those are some of my favorite projects.
You get immediate feedback, people actually use them, and every release teaches you something new about writing software.
There's also something satisfying about building a tool that quietly removes an annoying problem from your workflow.
If GiMan saves someone else from accidentally committing to the wrong GitHub account, then it has already been worth building.
And if you're about to publish your own CLI, learn from my mistake:
Google the name first.