And what problems do you have?

Different content in same URL comes after a login. When user logins server knows who this user is, what he can see, what access he has, etc. I don't understand why there is JS mentioned in the question. Forget about the JS hype, it is just a small tool to talk to browser. Browser has 0 connection to server and 0 connection to B2B or any serious enterprise app and actually on that level it is not a B2B app anymore, it always would be a B2B infrastructure. Learn how the web works, learn how it worked 20 years ago, I promise you, nothing changed since then.

B2B is about a complicated backend, a lot of data, security, logic and connection between models and not about JS. You store every access user has, every role, whatever he can see and can do in the DB, then server just returns HTML for this user.

Below is a very simple nav example:

<nav>
@foreach ($modules as $module)
  @if ($user->hasAccess($module))
     <a href="{{ $module->link }}">{{ $module->title }}</a>
  @endif
@endforeach
</nav>

Of course, there would a lot of modules with submenu items and you may also store order for every user or even store menu or any sets of data for each user in DB as well and render whatever user has in his huge settings with subsettings, subsubsettings, etc.

And of course you should not only display data depending on user role/access but every action also should check for the access on the first place. For most URLs or actions if user has no access server should return 403.

If your B2B infrastructure is even more diverse then you would make a huge and complicated architecture as well, for example, submicroservices extended from base for specific countries. The main point here is that on that scale you will never be able to handle that alone especially with 0 experience as I see. Get more domain, B2B and ecommerce knowledge and work for different companies, then and only then you will get a short answer to your question.

Usually, when you have the app on a subdomain, that's a whole other app. The subdomain points to a different ip address where the app is deployed.

That's a good solution because you can work on SEO on your landing page and have a PWA on a different place that don't necessarily need indexing or SEO.

Have you taken a look at AB testing? Assuming you already have a way to identify the business on load, something like that could be what you need.

Only it wouldn't be "testing" in this case, but built into the application and, instead of a random interface for each business, the UI elements would be decided by the business id.

I'd probably use React and design one high-level component per business type. Then I would write lower-level, functional components, and populate the "business" components with the lower-level ones on a needed/allowed basis.