Naming creation
in Amsterdam

In the Netherlands, the right to use a business name comes largely from actual use. That right lives inside the Handelsnaamwet, the Dutch Trade Name Act. It sits apart from trademark law entirely. The logic is different too, built around use and confusion rather than exclusive ownership of a word on a register.

The Kamer van Koophandel, the Dutch Chamber of Commerce known as KVK, records every trade name in its business register. Its public register can be searched for identical and similar names before signup. That search is a first filter. It catches obvious duplicates. A clean result is not the same as a legally settled name.

The real test under the Trade Name Act comes later. It comes from other traders, not from KVK itself. KVK stops at the register. A name that causes confusion with an earlier trade name can be challenged by the earlier user. That only applies within the same area and the same line of business. If needed, the matter goes to court and the newer name gets changed. The standard is confusion in practice, not word for word identity.

Geography and sector both do real work in that standard. A furniture workshop in one town carrying a name close to a software company across the country faces little real risk. Neither audience is likely to confuse the two. Two consultancies with similar names operating a few streets apart in the same city face a very different situation. That is exactly the pattern most likely to end in a dispute.

This makes the KVK registration check only the first, thinnest layer of the work. A careful search before commitment reaches further. It covers the KVK register itself, filtered by sector and region rather than by exact string. It also covers an ordinary search of local competitors, directories and social profiles active in the same field. None of that requires a legal filing. A short search before a decision is far cheaper than a dispute after launch.

A second, separate test has nothing to do with law. It is about sound. Dutch pronunciation carries a handful of features that quietly reshape a candidate name. They surface once the name leaves an English speaking room and meets a Dutch one.

The hard g is the most obvious. It comes from the back of the throat, closer to clearing it than to the soft English g. That sound sits at the front of many ordinary Dutch words. A name that leans on a g for warmth in English can land differently in Dutch. Say it wrong, and it shows. It can sound harsh, or unintentionally comic, once pronounced the local way.

The digraph ij behaves like nothing in English. Read by a Dutch speaker it produces a sound close to the English word eye. A name that looks like a tidy English word ending in a y can be reinterpreted entirely once local spelling habits meet it. Ui causes a related problem too. It is a diphthong with no close English equivalent. It is easy to mangle if a founder simply guesses at how it will be said locally, without ever checking.

None of this is solved by a dictionary. There is no shortcut. The only reliable check is reading a shortlist aloud, cold, to a handful of Dutch speakers. None of them should be coached or shown the intended pronunciation beforehand. What comes out of that test is what matters, not what a founder hears in their own head. That is what a market will actually call the brand for years afterward, long after the launch party is forgotten.

A name chosen for a company sometimes needs to work twice. Once as a brand. Again as a live technical identifier inside app stores, code repositories and package managers. The rules governing that second use have nothing to do with trademark law. Different game entirely. They can quietly block a name that passed every other check, without anyone noticing until submission day.

Major app stores keep a single namespace for display names. Two apps cannot carry the exact same listed name inside the same store. Not even close variants. A store review process can also reject a name close enough to an already listed app to mislead a shopper browsing search results. That happens independent of any trademark dispute between the two companies involved.

Length matters more here than almost anywhere else a name appears. A display name that reads comfortably on a business card or a website header often needs shortening for an app icon. Only the first several characters show clearly beneath the artwork on a small screen. Long names get cut off mid-word. A name with no natural short form causes trouble at exactly this stage.

Certain words trigger extra scrutiny during store review. A name implying an official status it does not have can delay approval. So can borrowing a rival product name without permission, or overclaiming a feature the app does not deliver. None of this shows up until submission. Well after the name is already printed on marketing material and business cards.

Package registries used by developers, for code libraries, modules and command line tools, work on a first come basis inside each registry. First claimed, first served. That basis is entirely separate from any trademark or company registration. A name already claimed by an unrelated project inside one of these registries forces a scoped or modified variant for that particular technical use, even where the brand itself is free everywhere else.

A related but different decision is the identifier that ties an app to its store listing. It is commonly built as a reversed structure, such as a company domain read backward with the app name appended after it. This identifier is set once at first submission. Get it wrong, and there is no clean fix. It is expensive to change later, since existing installs, reviews and update history for every user stay attached to it. Changing it afterward effectively starts the app over from zero.

None of these checks belong naturally to a legal team. They sit with whoever manages the technical release. They are worth running early, rather than after a name is already committed to a logo, a domain and a printed set of stationery. A short search across the relevant stores and registries, done before naming is finalized, catches a blocked identifier while it still costs nothing to change.

Where the checks disagree, a small variation usually resolves the conflict without a full rename. Adding a short suffix helps. So does adjusting a single word, or reserving a scoped variant inside a package registry. Small fixes, not full rebuilds. Either move keeps the core name intact everywhere a customer actually sees it, while satisfying whichever narrower namespace caused the original block.