The admin tab problem
Most SaaS products start with one application. Then somebody at the company needs to approve a signup, or suspend an account, or see how many workspaces exist. So an admin section appears behind a role check, and for a while that is fine.
It stops being fine quietly. The admin section starts holding data the customer application has no business touching. Its screens speak a different language: applications, provisioning, suspension, arrears. Its worst case is different too. A bug in a customer feature affects one workspace. A bug in the operator view affects the estate.
By the time this is obvious, the two products share a router, a state store, a session model and a deployment. Separating them is now a migration rather than a decision.
Drawing the line early
We split Isura into a control plane and a runtime plane before either had much in it.
The control plane is about becoming and remaining a customer. Applications get reviewed, tenants get provisioned, subscriptions get switched, lifecycles get recorded. Operators live here. The vocabulary is ours.
The runtime plane is the workspace itself. Users, roles, work, records, the day to day. Customers live here. The vocabulary is theirs, and it should never leak an implementation detail from our side of the boundary.
Two applications, two services, two audiences. A user is in one or the other, never in an ambiguous middle where the interface has to guess which product it currently is.
What the split buys
Ownership gets simple. When a question arrives about who owns a feature, the answer is the plane the user is standing in. That sounds small. It removes an argument that otherwise recurs monthly.
Blast radius shrinks. An operator surface can be down for an hour without a single customer noticing. The reverse should also be true, and with separate services it is.
Copy gets honest. The tenant application never has to explain a platform concept, because it does not have one. Nothing in it says provisioning, because provisioning is something that happened to the tenant, not something the tenant does.
And the tenant data boundary holds. Tenant users live in the tenant service. The platform side never holds them, which means the most sensitive records in the system are structurally out of reach of the surface that operators use.
The cost, honestly
You build two of some things. Two shells, two session flows, two deployment pipelines. A shared UI library absorbs most of that, but not all, and pretending otherwise would be dishonest.
You also have to decide, for every new capability, which plane owns it. That decision is occasionally hard. It is also the decision you were previously avoiding by putting everything in one application and letting a role check pretend to be an architecture.
The test
Here is the question worth asking about any admin section you currently maintain. If you handed it to a new engineer with no context, would they be able to tell from the interface alone which company the user works for?
If the answer is no, you are running two products in one codebase, and only one of them is being designed.