A client message came in that looked like a small bug. He could not re-add someone to the app. He had taken that person out weeks earlier, the name was gone from the list he was looking at, and now the app was telling him the email address was already in use.

Both things were true. He had deleted the invitation, not the account. The invitation is a piece of paper that says come in. The account is the person standing in the room. Deleting the first one takes the name off the guest list and changes nothing about the second, so when he tried to send a new invitation, the app checked the accounts it already had and found one.

In the same thread he asked for the person's password so he could hand it off. The answer to that is no, and it is a good no. We do not have it. Nobody has it. What is stored is a one-way scramble of the password, which is exactly what you want, and the only thing anyone can do is send a reset link. That answer is correct and it is also useless to him, because what he was actually asking was a real question with no button attached to it: how do I take this person's access away, and how do I give it to someone else.

That question had never been scoped. Not on that build, and not on most builds I have seen.

Every app is designed around arrival

Look at the requirements for almost any new product and you will find the growth path described in detail. Sign up. Invite your team. Set a role. Resend the invitation. There are usually three screens for it, because that is the part everyone imagines while the product is still an idea, and because that is the part that gets demoed.

Now look for the other direction. Someone quits. Someone gets moved to a different branch. A contractor's engagement ends. A person was added by mistake with a typo in their email. None of those show up in a discovery conversation, because nobody pictures their software shrinking while they are still trying to get the first ten people into it.

So the offboarding path ships as whatever happened to fall out of the database schema, which usually means nothing. And then the product becomes real, which is the exact moment somebody leaves.

You cannot just delete the row

The obvious fix is a delete button, and the obvious fix is wrong in a way that only shows up once there is real data.

By the time you want to remove someone, that person is attached to things. They created records. They approved things. Their name is on a timestamp somewhere. In the database those connections are real links, not decorations, so the delete either fails outright because the database refuses to orphan the records, or it succeeds and takes the history with it. The second outcome is worse, and it is quiet. A year of activity loses its author, or entire rows vanish, and nobody notices until someone goes looking for who did what in March.

The history is not a side effect. On most of the apps we build, knowing who entered a number is a meaningful part of why the app is trusted more than the spreadsheet it replaced. Deleting a person to revoke their access, and taking the record of their work with them, trades a small convenience for the thing that made the software worth paying for.

So removal is not deletion. Removal is deactivation: the account stays, the work stays attributed, and the person can no longer get in.

Deactivation is a set of decisions, not a checkbox

This is where it stops being a bug and starts being product work, because once you decide the account survives, someone has to answer questions that only the business can answer.

Does their name still appear on the records they created, or does it read as a former user? Do they keep receiving the notification emails the app sends out on a schedule? Can their email address be reused by a new account, or is it burned forever? If they owned something that needs an owner, an open request, a queue, a client, does it get reassigned on the way out or does it sit in a dead account? When an admin looks at the list of people, does a deactivated user appear grayed out or disappear entirely, and if they disappear, how does anyone reactivate them by mistake three weeks later?

None of those are hard to build. All of them are decisions, and a development team cannot make them for you without guessing. Which is why the work is cheap when it is scoped in week one and expensive when it arrives as a support message, because by then it comes with a person who is already locked out, or worse, already gone and still logged in.

What it costs to leave it out

When the product cannot remove a user, somebody still removes the user. That somebody is a developer, editing production data by hand.

For a founder, that means every departure is a ticket, a wait, and a dependency on the shop that built your software for an operation your office manager should be able to do. For us, it means a person with production access doing surgery on a live database because a screen does not exist, which is the kind of routine that works fine right up until the afternoon it does not.

The tell is simple. If your admin has to ask us to do something, that thing is a missing feature, and the number of times you have asked is the size of the gap.

What to ask before the first invitation goes out

The account lifecycle belongs in the first scope conversation, next to the login, not in a backlog item titled user management. Four questions get you most of the way there.

What happens to the records a person created after that person is removed? Get the actual answer, in words, before anyone writes the schema.
Can an administrator deactivate someone, or is that us? If it is us, ask what it costs to make it you, and ask now while it is a form and not a migration.
What is the difference in this app between an invitation, an account, and access? If your team uses those three words interchangeably, your software probably does too, and that is the bug behind most of these messages.
Can an administrator send a password reset instead of asking anyone for a password? If a shop will tell you a user's password, that is not helpfulness, that is a security problem you now own.

The point

Software for a growing team is easy to imagine and easy to sell. Software for a real team has to handle turnover, because turnover is not an edge case, it is a Tuesday.

An MVP does not need a full permissions console. It needs one honest answer to the question of how a person stops being a user, decided by a human before it is decided by a database constraint at the worst possible moment. Scope the exit with the entrance. It is a form and an afternoon on day one. It is a live incident and a manual database edit on day two hundred.

Adding a User Is a Feature. Removing One Is a Project.