Years ago I worked on an employee review system. Peers could submit feedback about each other. Managers wrote the reviews. HR administrators approved the content before anything got printed and signed.
It worked. People used it. And every single release, someone on the team spent four hours clicking through it by hand.
Not because we were sloppy. Because getting this wrong isn't a bug you patch next sprint — it's an HR incident. Someone leading that project wanted to see firsthand that a peer couldn't do a reviewer's job, and that nobody could wander into another team's reviews. That instinct was right.
The problem was what it cost to satisfy it.
Why Four Hours
Log in as a peer. Try the thing. Log out. Log in as a manager. Try the thing. Log out. Log in as that employee's actual manager, because that's different. Log out. Log in as HR. Try the thing.
Now do that for every action in the application.
Here's the part that matters: that grid didn't grow when we added a persona. It grew when we added anything. Every new action multiplied across every existing persona. The test matrix expanded faster than the feature list, and it expanded quietly, because nobody sits down and re-estimates the manual pass when they ship a small enhancement.
The Tax Nobody Escalates
Four hours is a terrible number.
If it were four days, someone would have fixed it. Four days is a crisis, and crises get budget. Four hours is just Thursday afternoon. It's small enough that raising your hand about it feels like complaining, and large enough that it quietly sets your release cadence for you.
That was the real cost. Not the hours — the frequency. On a small team, your release rhythm gets set by the slowest thing you're required to do before shipping. Ours was a person clicking through a grid. We weren't going to release weekly. We were never going to release daily. Not because of anything technical, but because four hours of somebody's attention had to be found first, and it had to be found every time.
Nobody ever decided that. It just became true.
What Was Actually Broken
The manual testing wasn't the disease. It was the only available treatment.
Two completely different questions lived tangled together in the same code:
Is this person allowed to do this? A manager can view a review for someone who reports to them. That same manager can't view a review for someone on another team. Swap the user, and the answer changes.
Does this action make sense right now? A review can only be printed and signed once every section is complete and HR has reviewed it. Swap the user — swap in anyone you like, the CEO included — and the answer doesn't move. The review either meets the bar or it doesn't.
Those are different kinds of questions. But they sat side by side in the same methods, interleaved, sharing local variables. And when two questions are fused like that, you can't test either one on its own. You can only test the combination, which means going in the front door: a real login, a real click-through, a real judgement call about what you're looking at.
That's why the matrix was a matrix. Not because there were a lot of permissions. Because there was no seam.
One Question
The fix started with a question we could apply to any check in the codebase, and it takes about five seconds to answer:
Swap the user. Does the answer change?
Look at those two right-hand boxes. "Can this review be printed and signed?" sounds like a permission. It reads like one. If you found it living in a permissions class, you wouldn't blink.
But the user isn't in the equation. It's a rule about the state of a document, and it applies identically to every human being in the company. That's not a permission — it's a business rule wearing a permission's clothes, and every one of those we untangled made the system easier to reason about.
Meanwhile "can this manager view this review" changes answer depending on both who's asking and which review. Same manager, their own report's review: yes. Another team's: no. That's authorization, and it's the kind that actually needs the specific record in hand.
Two checks. Same document. Same moment in the workflow. Completely different natures.
What Separation Bought
Once authorization was pulled into its own layer, we could ask it questions directly. No browser. No login. No clicking. Just: given this user and this review, what's the answer?
That's a unit test. It runs in milliseconds, and you can write forty of them in an afternoon.
The business rules got the same treatment from the other side. "Is this review complete and HR-approved?" doesn't need a user at all, so testing it never required setting one up.
The grid stopped multiplying. Permissions got tested as permissions. Rules got tested as rules. What used to be actions × personas × resources became actions + rules, and addition scales in a way multiplication never will.
How It Actually Ended
I want to be honest about this part, because the tidy version isn't true.
Nobody announced that manual testing was over. There was no meeting. What happened was slower and more human: over a few iterations, the tests kept being right. Someone would work through the manual pass anyway and find nothing the automated checks hadn't already caught. Then it happened again. Then again.
Confidence isn't a decision. It accumulates.
Eventually the four-hour pass just wasn't how the team knew the software worked. It stopped being load-bearing. And the manager who'd insisted on it in the first place didn't have to be talked out of anything — the evidence was there for everyone to see.
Wanting proof was never the mistake. It just needed to be cheaper to get.
A Question For Your Own Team
If any of this feels familiar, here's a question worth asking at your next planning meeting:
Which of our manual test steps exist only because we can't answer a permission question without logging in?
Not "is our testing thorough enough." That question gets you a defensive answer. Ask which steps are there because of the architecture rather than because of the risk. Your team already knows. They've been doing those steps by hand for months.
That list is your four-hour tax. And it's almost always smaller than it looks — because most of what's on it isn't a permission at all.
Separating the two also makes everything downstream easier. Tools that manage permissions — AuthorizationHub included — are more useful when there's a clear policy layer to point them at. They'll work regardless. But the cleaner the separation, the more you get out of them.