Why the Word “User” Is Killing Your Software Design (And How to Fix It)

When you realize that the lightweight, simple assumptions you made at the start of a project were completely wrong after six months of work, you must now solve these problems to keep the system running, and you discover you have spent far more effort than expected; had you started correctly, this would not have happened.

Today I want to tell you about a common mistake, a word that brings endless problems: “users”.

This word has two fundamental errors: it is rarely a good description for your requirements, and it creates a basic design security flaw because the concept is vague; using more precise terminology almost always yields better results.

You have no users

No software system truly has users. For example, a ticket‑reservation system involves travelers, buyers, travel agencies, and airline staff, each with distinct roles. The term “user” is useless and would not be used in many requests that require specific identities such as traveler and agent credentials.

Unix has no “users”

In POSIX, there are entities that can log in and run code, but they represent different concepts: interactive login accounts, system services like nginx, shared admin accounts, and the root account. Treating all of these as “users” leads to security problems.

SaaS providers also lack a single “user” concept. As Jeremy Green noted, SaaS services are almost always paid by one person in an organization but used by one or more people. If you treat all of them as a single user, you cannot model teams or shared payment, leading to costly redesigns.

The “users” concept is too vague; you really need only two concepts: a team (to organize relationships and payment) and a member (the actual person using the service). The word “user” causes both business‑logic and security issues.

The term merges two ideas: a person and their representation in software.

Consider a malicious website that causes a browser memory overflow, allowing the remote server to upload your files. Because the browser runs under the system account, its actions are attributed to you, illustrating the Confused Deputy problem when “user” is used for both human and system identities.

Spending less effort on the same problem is key to being a high‑productivity programmer. Using vague concepts like “user” will waste a lot of time fixing issues later. Starting to code immediately may seem productive, but the opposite is true.

Next time you start a new software project, spend a few hours upfront defining your terminology and concepts. You may not get everything perfect, but you will do much better, and your future self will thank you for the preventive work.