← Back to articles

Dissociate Technical and Business Terms

Here’s a quick article to describe a situation I’ve encountered multiple times during my career. At the beginning of a tech company (let’s say AcmeTech), the founding engineers create a code repository named acme. Inside, you’ll often find directory names containing acme, and the same goes for programming symbols (e.g., AcmeStorageRepository).

Fast forward a few years — after great financial achievements — AcmeTech is rebranded with a more serious name to attract investors (let’s call the new name Hooli). And thus begins the very tedious task of renaming everything from acmeto hooli.

The Two Layers of Change

  1. Consumer-Facing Changes 🖥️ This includes renaming the company name on the website, updating the apps distributed by the company, changing the domain name, and so on.
  2. Internal Technical Changes 🛠️ To maintain consistency, you also need to rename:

This process is extremely tedious and can span multiple years. 😩

What Could Go Wrong? 🤔

Let’s say the renaming is still in progress when the company gets acquired. Now, you’re faced with yet another name change, even though the previous migration isn’t finished. This leads to a never-ending cycle of renaming.

Avoiding the Naming Nightmare

To prevent this costly and time-consuming problem, I’d encourage founding engineers to avoid using the company name in any internal technical naming.

Instead, follow these best practices:

  1. Use a code name or project name (e.g., use Meh instead of Acme).
  2. Keep everything consumer-facing configurable via a settings file. For example:

With this approach, your company can change its business name every six months if needed, and you won’t need to make significant technical changes. Everything stays clear as long as you document and explain the technical meaning of Meh.

Another Option 🛑

Alternatively, you could keep the original company name in technical layers, even after multiple business name changes. However, this approach can be confusing and introduces a legacy vibe to the project — a feeling that might not sit well with modern teams.


By decoupling technical terms from business branding, you save yourself (and your company) from unnecessary complexity, allowing you to focus on growth and innovation. 🚀