Generate internal project and release codenames β the kind that need to be memorable in a stand-up and unambiguous in a commit message. No trademark or commercial dimension applies here, so this leans toward distinctive, easily said single words rather than descriptive phrases.
Settings
Recent results
Generated locally in your browser β your settings and results never leave this page.
Codenames do a different job
An internal project name is not marketing. Nobody has to be persuaded by it, it does not need to describe anything, and it carries no commercial or trademark weight. What it has to do is give a group of people an unambiguous way to refer to one specific piece of work.
That sounds trivial until you have worked somewhere that skipped it. Without a name, work gets referred to by description — “the migration”, “the new dashboard thing”, “the Q3 piece” — and descriptions drift, overlap and get applied to two different projects at once. A name is a handle that stays attached.
Because none of the commercial constraints apply, this tool leans toward distinctive single words rather than descriptive phrases.
What actually makes a codename work
It has to be unambiguous in writing. The name will end up in branch names, ticket prefixes, channel names and commit messages. If it collides with a common word in your codebase, searching for it returns noise forever.
It has to be sayable in a meeting. Anything that needs spelling out loud will be silently replaced by an abbreviation within a fortnight.
It has to be distinctive enough to search. A project called “Core” or “Platform” is unfindable in any tool your company uses. This is the single most common mistake and the most annoying to live with.
It should not mean anything load-bearing. A name that describes the plan becomes wrong when the plan changes, which it will.
Names that leak
Codenames escape. They turn up in public repositories, job adverts, conference talks, support tickets and screenshots, and they are frequently the first external signal that a piece of work exists.
So it is worth a moment’s thought about what the name would say if it were read by a customer, a competitor or a journalist. A name that describes the strategy — a target company, a market you are entering, a product you intend to replace — is a leak waiting to happen. A name that is arbitrary says nothing, which is the point.
Arbitrary also means nobody has to defend the choice later, which saves a surprising amount of time.
Themed sets
Many teams run a theme — rivers, mountains, birds, minerals, constellations — and it works well for two reasons. It removes the decision from every new project, and it makes the names feel like they belong to one system rather than to whoever happened to name them.
Two things to decide before you start. How large is the theme, and how will you know when it is exhausted? And is it pronounceable by everyone on the team, including people who do not share a first language? A theme built on names that half the team cannot say is a theme that quietly stops being used.
Set a keyword or a starting letter here if you are working within a theme and want candidates that fit it.
When a codename escapes into the product
Sometimes a codename is so obviously right that it becomes the real name. This is a good outcome and it needs one deliberate step: the moment that becomes a possibility, the name stops being internal and acquires every commercial constraint it was previously free of.
At that point it needs the checks a product name needs — is it in use, does it conflict in your category, can you secure what you need around it. A codename that has been in use internally for a year is not evidence that it is available.
What the score means here
Results are scored on pronounceability, structure, likely spelling, length and syllable count. For a codename, treat the score as advice about whether the name will survive daily use rather than as a judgement of quality.
The properties worth caring about are shortness and sayability. A four-syllable codename becomes a two-syllable one in practice, chosen by whoever speaks first.
Collisions that only show up later
The friction in a codename rarely appears on the day it is chosen. It appears three months in, and it comes from a small number of predictable collisions.
A word already in your codebase. If the name matches a class, a module, a variable or a common term in your stack, every search for the project returns unrelated code, permanently.
A reserved or special word. Names that clash with a package name, a command, a branch convention or a URL path create small annoyances that never quite get fixed.
Another team’s project. Two projects with the same codename in one organisation is worse than no codename at all, because references silently resolve to the wrong thing.
Something that is hard to type. Accents, unusual spellings and doubled letters get typed wrong in branch names, and the wrong version sticks around beside the right one.
All four take a minute to check and are effectively permanent once the name is in use.
Practical hygiene
Write the name down somewhere findable alongside a one-line description of what the project actually is, because in six months nobody will remember and the name deliberately does not tell them.
Check it does not collide with an existing project, an internal tool, or a common term in your stack before you commit it to branch names. And retire names when projects end rather than recycling them — a reused codename makes your own archive ambiguous, which is exactly the problem the name existed to solve.
How to use the Project Name Generator
- Optionally enter a theme word if your team names projects from a set — rivers, minerals, birds.
- Use "Must start with" if you are working through an alphabetical sequence.
- Keep the style on one word; codenames that need spelling out get abbreviated within a fortnight.
- Press Generate project names and take several rounds before choosing.
- Check the name does not collide with a common term in your codebase before committing it.
- Record the name alongside a one-line description of the project — the name deliberately will not tell anyone.
Frequently asked questions
What makes a good project codename?
It has to be unambiguous in writing, because it will end up in branch names, ticket prefixes and commit messages. It has to be sayable in a meeting, or it gets abbreviated. It has to be distinctive enough to search — a project called "Core" or "Platform" is unfindable in every tool your company uses. And it should not mean anything load-bearing, because a name that describes the plan becomes wrong when the plan changes.
Should the name describe what the project does?
No, and this is the most common mistake. Descriptive names drift out of date the moment scope changes, and they collide with ordinary vocabulary so searching for them returns noise. An arbitrary name stays attached to the work regardless of what the work turns into, and nobody has to defend the choice later.
Does it matter if a codename becomes public?
It often does become public — codenames turn up in repositories, job adverts, support tickets and screenshots, and are frequently the first external signal that a piece of work exists. That is an argument for arbitrary names: one that describes your strategy, a target company or a product you intend to replace is a leak waiting to happen. An arbitrary name says nothing.
How do I use this with a themed naming scheme?
Put the theme word in the keyword box, or use "Must start with" if you are working through an alphabetical sequence. Before adopting a theme, decide how large it is and how you will know when it is exhausted, and check it is pronounceable by everyone on the team — a theme half the team cannot say quietly stops being used.
What if the codename turns out to be the right product name?
That happens and it is a good outcome, but it needs a deliberate step. The moment it becomes a possibility the name acquires every commercial constraint it was previously free of, and needs the same checks a product name needs. A codename that has been in internal use for a year is not evidence that it is available.
Do I need to check availability for an internal project?
Not in the trademark sense, while it stays internal. Do check it does not collide with an existing project, an internal tool or a common term in your stack, because that collision is what makes a name annoying to live with. If the name might ever ship publicly, treat it as a product name and check properly.
Are the names I generate visible to anyone else?
No. Everything runs in your browser, nothing is uploaded, and saved names stay in your own browser's local storage. Generating names for unannounced work does not transmit anything.
