Made with ❤️ by 2Nerds
The original idea was… ridiculously simple
We had a tiny idea: make a CLI that generates a cute little “Made with ❤️ by 2Nerds” tagline.
That was it.
No database.
No dashboard.
No auth.
No microservices.
No Kubernetes cluster that absolutely nobody asked for.
Just:
taggie
Answer a few questions.
Get a tagline.
Done.
Except… apparently humans are incapable of leaving a small idea alone.
Then we started asking “what if…?”
What if the CLI could actually put the tagline inside a real app footer?
Okay. Add that.
What if it detects whether the project is React, Next.js, Vue, Svelte, or plain HTML?
Sure.
What if there is no footer?
Then create one.
What if we create a Footer component?
Then wire it into the app automatically.
What if someone runs the command again?
Please don't duplicate the footer.
And that tiny requirement led us to one of the most important ideas in the project: idempotency.
Wait… what does idempotent even mean?
In Taggie terms, it basically means:
Run it once → add the attribution.
Run it again → don't create another one.
Run it 37 more times → still don't create 37 footers.
The result should converge to one correct state.
So instead of:
Made with ❤️ by 2Nerds
Made with ❤️ by 2Nerds
Made with ❤️ by 2Nerds
Made with ❤️ by 2Nerds
…Taggie updates its own block in place.
Because apparently even a footer needs boundaries.
Then came --check
Once Taggie could modify projects, we realized we needed a way to ask:
“Is this project actually configured correctly?”
So we added:
taggie --check
It is completely read-only.
It detects the framework, finds the footer, checks Taggie's attribution, and reports whether everything matches the configured standard.
It also returns meaningful exit codes, which means it can be used in CI.
So now Taggie wasn't just generating text.
It was checking project state.
Then came configuration
Typing the same flags every time gets old very quickly.
So we added taggie.config.json.
For example:
{
"by": "2Nerds",
"for": "Acme",
"emoji": "❤️",
"template": "byline"
}
Now the project has a defined attribution standard.
We also added profiles for cases like open-source projects:
taggie --sync --profile opensource
And CLI arguments can override configuration for a single run without modifying the config file.
Because configuration precedence is apparently a thing we care about now.
And then we built --sync
This was the point where the original “tiny tagline generator” had officially left the building.
taggie --sync
Sync means:
• add the attribution if it is missing
• update it if it is outdated
• do nothing if it is already correct
In other words, the project converges to the desired state.
Run it once.
Run it again.
Run it from CI.
Run it tomorrow.
Same correct result.
We also added --dry-run because trust issues are healthy
Before a CLI modifies your source code, it is reasonable to want to know what it is about to do.
So:
taggie --sync --dry-run
doesn't write anything.
It just tells you what WOULD happen.
Same idea for removal:
taggie --remove --dry-run
No files sacrificed for the greater good.
Then we realized people have… multiple projects
Naturally, someone eventually wants to run the same operation across several projects.
So Taggie supports:
taggie --sync ./projects/*
Each project is handled independently.
If Project A succeeds and Project B has a broken config, Project A doesn't suddenly become collateral damage.
Taggie keeps each target isolated and refuses to write outside the directory it was given.
Tiny CLI.
Suspiciously serious safety rules.
We even made it friendly to coding agents
This part was probably inevitable in 2026.
You can run:
taggie --init-skill
and configure integration for Claude Code or other coding agents through AGENTS.md.
The idea is simple:
Instead of manually editing a Taggie-managed attribution block, tell your coding agent to add, check, sync, or remove the attribution.
The agent uses Taggie's lifecycle instead of randomly editing files.
Because “let the AI edit my source code” becomes slightly less terrifying when the tool has explicit boundaries.
Safety became a whole section
At some point, we stopped thinking:
“How do we make this work?”
and started thinking:
“How do we make this NOT destroy someone's project?”
So Taggie follows a few rules:
• It doesn't blindly overwrite source files.
• It only updates content inside its own marker block.
• --check never writes.
• --dry-run never writes.
• --remove doesn't delete a Footer component it created.
• Multi-project sync stays inside each target directory.
• Unsupported structures are reported instead of guessed at.
Basically: if Taggie isn't confident it can safely modify something, it refuses.
The final result
The funny part is that we started with:
“Let's make a CLI that generates a cute footer.”
And ended up with:
• interactive generation
• framework detection
• footer injection
• automatic component creation
• automatic wiring
• configuration
• profiles
• check mode
• sync mode
• multi-project sync
• dry-run support
• safe removal
• CI support
• coding-agent integration
• idempotent updates
• project-root safety
• tests for all the boring edge cases we absolutely needed
At some point we looked at the project and thought:
Wait.
This is not a tagline generator anymore.
What I actually learned from building it
The biggest lesson wasn't “how to make an npm CLI.”
It was learning to think about tools as systems instead of scripts.
A script asks:
“How do I make this happen?”
A useful developer tool also asks:
“What if it runs twice?”
“What if the config is broken?”
“What if the project is structured differently?”
“What if the user changes the generated code?”
“What if the target doesn't exist?”
“What if there are ten projects?”
“What if this runs in CI?”
“What if the safest thing is to do nothing?”
Those questions are where a tiny project starts becoming a real engineering project.
And honestly, that was the fun part.
Where we are now
Taggie is published as taggie-cli on npm and can be used locally or through npx.
The goal isn't to pretend we've invented the next Git.
We just wanted a small developer utility that solves one annoying problem cleanly, safely, and without requiring a dashboard, account, or another SaaS subscription to exist in our lives.
Two nerds.
One tiny idea.
Way too many edge cases.
Classic.
Final thought
If you ever start a project saying:
“It's just a small CLI.”
Please know that I am quietly judging you.
Because we did the same thing.
And look where that got us.
Last but not least:
🔗 Give it a spin & show some love!
- NPM Package: npx taggie-cli
- GitHub Repo: github.com/2nerds/taggie
Top comments (0)