A developer founder does not really face the abstract branding question every startup guide asks: should your product and company share a name. The real version is more specific and harder to answer in the abstract. Does your GitHub organization match your product name or your legal entity. Does your npm scope match either of those. Does your domain redirect from a company name to a product name, or the other way around. And what happens when you add a second product and half of these decisions were made assuming there would only ever be one. Branding guides answer the first question. This one answers all four.
Why the branding answer is incomplete for a technical founder
Every existing guide on this topic, and there are many, frames it as a single branding decision. Should your company and your flagship product share one identity, or should they be distinct. The standard advice, keep them the same when you only have one product, is reasonable and not wrong. But it treats the decision as having one axis, brand identity, when a developer founder is actually managing four separate systems that each encode this decision independently. The GitHub organization that houses your repos, the npm scope your packages publish under, the domain your marketing site and app both need to resolve to, and the legal entity your invoices and contracts reference. These four do not have to match. Some genuinely cannot easily be changed once set. And the interactions between them are where founders get stuck, not the abstract branding question itself. The underlying npm and GitHub mechanics referenced throughout this piece are covered in more depth in the scoping mechanics covered in NameKit's npm naming guide. None of this means the standard branding advice is wrong. It just means it stops at the exact point where the technical decisions actually start.
The four systems, and how much each one actually costs to change later
Here is what each of the four systems actually costs to change once it is already set, ordered roughly from least forgiving to most forgiving.
Your GitHub organization
This is usually the first of the four to get set, and the hardest to feel confident about early, since it is often created before the company even has a name. It is common to start under a personal GitHub username, then move repos into an organization later once a name exists. Renaming a GitHub organization is technically possible, and GitHub does redirect the old URL automatically. But every collaborator's local remote, every CI badge, and every external link referencing the old org path needs manual updating afterward. This is the same redirect mechanic that applies to individual repos, just at a larger scale with more collaborators affected at once, and it is worth understanding before assuming a rename will be painless.
Your npm scope
An npm scope, the at sign prefix on published packages, is effectively permanent in practice even though technically renameable, since every consumer's package.json hardcodes the exact scoped name it installed under. If your company name changes after you have already published packages under the original scope, you are choosing between maintaining two scopes indefinitely or accepting that some consumers stay on the old name forever. This is the least forgiving of the four systems, since unlike a domain or a GitHub organization, there is no clean automatic redirect mechanism for npm scopes the way there is for git remotes. Treat this decision as close to permanent from the first package you publish onward.
Your domain
This is the most flexible of the four, and the one most guides focus on exclusively, since a domain change mostly just requires a redirect and some patience while search rankings catch up. But for a developer founder, the domain often needs to serve double duty: marketing site and product app, sometimes on the same domain and sometimes split across a root domain and a subdomain like app.yourdomain.com. That split decision, root domain for marketing versus a subdomain for the actual product, is worth making deliberately rather than accidentally, since it affects how search engines treat the two pieces of content, separately or together, for years afterward.
Your legal entity name
This is the one branding guides treat as fixed and unchangeable, but it is actually the most disconnected from the other three in daily practice. Your legal entity name appears on invoices, contracts, and tax documents. It almost never needs to match your GitHub organization, npm scope, or domain, and trying to force alignment here creates unnecessary friction with lawyers and accountants for a decision that has essentially zero effect on how developers or users discover and use your product. Keep this one separate in your head from the other three, and it stops feeling like a problem you need to solve alongside the technical ones.
What to actually decide, and in what order
Once you understand what each of the four systems costs to change later, the order to decide them in becomes clearer.
- 01Pick your product name first if you are a single product company right now, since this is the name that will appear in the most places: your domain, your marketing, your app store listing, and probably your GitHub organization.
- 02Set your GitHub organization to match the product name if there is any reasonable chance of it becoming your primary public identity, since organization renames are survivable but genuinely disruptive with multiple collaborators.
- 03Decide your npm scope deliberately if you plan to publish any packages, treating it as close to permanent, since it is the least forgiving of the four systems to change later.
- 04Choose your domain structure, one domain for everything versus a root domain plus a product subdomain, based on whether you expect multiple products eventually, not based on what is easiest to set up today.
- 05Leave your legal entity name as a separate decision entirely, made with an accountant or lawyer, disconnected from the other three unless there is a specific tax or liability reason to align them.
None of these five steps requires certainty about the future. They just require deciding each system on its own terms instead of assuming one decision covers all four automatically.
When you will actually face this again: the second product problem
This is the scenario that breaks a naming decision made too early. A founder builds one product, names the GitHub organization, npm scope, and domain identically to the product, and everything lines up cleanly. A year later, that same founder builds a second product and discovers the entire technical identity was built assuming there would only ever be one thing. The domain now has to awkwardly host two products, or a second domain has to be registered and somehow connected back to the same GitHub organization and the same npm scope in a way nobody planned for. This is precisely the situation the compound naming pattern in NameKit's micro SaaS guide addresses, choosing an organization or domain structure early that has room for a second product without requiring a full technical migration later, which is the same forward looking naming pattern covered in NameKit's micro SaaS guide. Planning for that possibility early, even if a second product never actually happens, costs almost nothing. Discovering the need for it a year in costs a real migration.
Decide the systems separately, decide them deliberately
This is not one branding decision. It is four technical decisions with very different costs to change later, and treating them as one question is how founders end up locked into a structure they never consciously chose. If you have not settled on a product name yet, NameKit's Startup Name Generator is a reasonable starting point for generating a candidate before you work through the four systems individually and decide each one on its own terms.
Frequently asked questions
Should my company name and product name be the same?
For a single product company, yes, in most cases, since maintaining two separate brand identities is expensive and confusing this early. The more useful question for a developer founder is whether your GitHub organization, npm scope, and domain all reflect that same decision consistently, since these often diverge even when the branding intent was to keep everything unified.
Can I rename my GitHub organization later without breaking things?
Yes, GitHub redirects the old organization URL automatically, similar to individual repository renames. However, every collaborator needs to update their local git remotes, and any hardcoded organization references in CI configs or documentation need manual updates, so it is disruptive with an active team even though technically survivable.
Is an npm scope permanent once I publish packages under it?
Not technically, but effectively yes in practice. Every consumer who installs your scoped package has that exact scope hardcoded in their own package.json. There is no automatic redirect mechanism the way there is for git remotes, so changing a scope after publishing means maintaining the old scope indefinitely or leaving some consumers behind.
Should my product live on my root domain or a subdomain?
This depends on whether you expect a single product long term or multiple products eventually. A root domain works cleanly for one product. A subdomain structure, like app.yourdomain.com for the product and yourdomain.com for marketing, leaves more room to add a second product later without restructuring your primary domain.
Does my legal entity name need to match my product name?
No, and trying to force this alignment often creates unnecessary friction with legal and accounting processes. Your legal entity name appears on contracts and tax documents, almost never in front of users or developers, so it can reasonably diverge from your GitHub organization, npm scope, and domain without causing any real world confusion.