Count the browser tabs your engineers have open to verify last night's backups. That number is a design decision somebody else made, and you are paying for it in salary rather than licence fees.
It never appears on an invoice, which is why it survives scrutiny that a line item would not.
The daily cost of verification
Verification is the routine case, not the exceptional one. It happens every morning, across every client, whether or not anything went wrong.
Why the tab count is architectural
Portal crawl is the visible symptom of a platform built for one tenant and given a partner dashboard afterwards. Each client is its own context, sometimes its own credential set, occasionally its own console. The dashboard tells you something is wrong; fixing it means going somewhere else.
When the tenant is the unit of the data model, changing client changes your viewpoint rather than your session. One tenant graph, one audit chain, one key hierarchy. There is no second place to go, because there was never a first.
The same property is what allows a change to reach every client at once — a Conditional Access policy set, an authentication-method baseline — rather than being repeated per tenant with the drift that implies.
At sixty it is most of an engineer's morning, and at two hundred it is a headcount question. The architecture that is invisible at small scale is the one that decides whether growth is profitable.
What to measure before you switch anything
Time your own morning verification for a week. Count switches and reauthentications separately from clicks; the interruption cost of re-establishing context is where the minutes actually go.
Then ask a prospective vendor to demonstrate the same routine across three tenants without opening a second context. That demonstration is short, and it is difficult to fake.