Permissions Are the Product

A client sent over what looked like a small request. Two kinds of people use the app we are building for them: the people doing the day to day work, and the person reviewing it. The request was one sentence. Make it so the reviewer does not automatically see the full history of everything the other users enter. Put it behind a toggle.

On a task list, that reads like a twenty minute job. Add a setting, hide a panel when the setting is off. In reality, that one sentence is a decision about who is allowed to see what, and once more than one kind of user touches the same records, that decision quietly becomes half the product. It touches every screen, every list, every export, and every notification. It is the least glamorous work in the build and the part users feel the most.

The features are the easy part

When a founder describes an app, they describe the nouns and the verbs. A user creates a record. A manager approves it. A reviewer views it. A dispatcher assigns it. Those are the features, and features are genuinely the easy part now. A small senior team with good tools can stand up the screens that do those things quickly. What takes the thinking is not what each role can do. It is what each role can see, and who they are hidden from.

The moment two different kinds of people log into the same data, you have a matrix, whether you drew it or not. For every type of record and every role, there is an answer to three questions. Can this role see it. Can this role change it. And is this role even supposed to know it exists. Most founders scope the first version around the first question and meet the other two mid build, usually when someone asks a version of the sentence my client asked. Can we make it so this person does not see that.

Why "just add a toggle" is never just a toggle

Say yes to the toggle and here is the tail that comes with it. If the reviewer sometimes sees the history and sometimes does not, every screen that shows history now has two versions, and you have to decide which one loads by default. If a staffer enters records under one setting and the toggle later flips, you have to decide whether the old entries follow the new rule or keep the old one. If a summary counts records the reviewer is not allowed to open, the totals will not match what is on screen, and someone will file that as a bug. If a notification fires when a hidden record changes, the notification just leaked the thing you were hiding.

None of that is exotic. It is the ordinary consequence of a visibility rule meeting a real system that already has lists, counts, exports, and alerts in it. The rule is cheap to honor when you design the data and the screens around it from the start. It gets expensive in exact proportion to how much you built before you asked the question, because by then the assumption that everyone sees everything is baked into queries you now have to unwind.

Build it into the data, not on top of it

There is a right time to make visibility cheap, and it is before the data has a shape. If a record knows from the start who it belongs to and who is allowed to see it, then every list, count, and export can ask the same question and get a consistent answer. Visibility becomes a property of the thing itself. If instead you let everyone see everything for the first few weeks because it is faster, you end up bolting a filter onto each screen one at a time later, and every screen you forget becomes a leak. The cost was never in the toggle. It is in whether the foundation was poured with the rule in mind.

The grid to draw first

Before you build any app that more than one type of person logs into, write two lists and one grid. The first list is the roles. Not job titles, roles. The person doing the work, the person checking the work, the person who owns the account, the outside party who gets a peek. The second list is the kinds of records the app holds. Then draw the grid. For every role and every record type, fill in one of four answers. Sees and edits. Sees only. Sees a summary but not the details. Does not see it at all.

That grid takes an afternoon, and it is boring, and it will surface most of the hard product questions in your app before any of them is expensive. A permission question is really a question about who your app is for and what it is protecting. When you cannot fill in a cell, you have found a decision no one has made yet, not a detail to defer to the developers. A few prompts that tend to shake the rest loose. Who administers the toggles, you the founder or the vendor. When a new person is added, what do they see by default, and which way is safer to be wrong. If two roles disagree about whether something should be visible, who wins.

Visibility is a promise, not a setting

The reason this matters beyond tidy engineering is that a permission is a promise to the person on the quiet side of it. When someone puts information into your app, they are trusting that it goes where you said it would and not somewhere else. A tool that shows the wrong person the wrong record has not shipped a bug. It has broken a promise, and in the kind of app where roles matter, that is the fastest way to lose a user who otherwise liked the software.

So when a request arrives that sounds like a setting, read it as a promise instead. Ask who is on the other side of it, what they are being protected from, and what every list, total, and alert should do once that promise is in place. Get the grid down before you get attached to the screens. The features are not what will make your app feel trustworthy or careless. The visibility rules are.