More like “didn’t particularly pay attention to”. You can find folks who’ll decry the use of ANYTHING - even if statements! - and I wasted waaaaaaay too much time arguing with that sort in Rails-land.
I’ve seen an umbrella solve OP’s specific problem very efficiently - the system was one that coordinated delivery companies (+ drivers) and stores. The key problem the umbrella solved was keeping UIs for different audiences entirely separated; apps were roughly like:
core: giant ball of DB schemas + business logicstore_web: UI for stores to use to submit & track delivery requestsdriver_web: UI for drivers to use when making deliveries. Mobile-first, designed to tolerate drivers losing network connectivity intermittenttlydispatcher_web: UI for the dispatchers to manage their driver’s work and check status
We didn’t do anything fancy for deployment like splitting subparts (for instance, deploying core + store_web separately) but the built-in boundary checking means we could.
This setup really showed its benefit when Bigco asked us for a new interface that would let Bigco management admin all of their stores. It found a straightforward home as a new bigco_admin_web, with a separate asset pipeline so BigCo could have their logo plastered on everything.
Another nice momement was when we needed to add SAML as a login option, but only for stores. This involved “splitting” the login form to ask for email first, and then either prompt for password or redirect to the IdP. Since each audience has its own _web, it was straightforward to modify only the one for stores.
None of these are strictly “only umbrella could do this”; a team with sufficient organization and discipline could accomplish the same thing all wedged into one Phoenix app, the same way a team like that could make a well-factored Rails monolith. Here in the real world, IMO the umbrella helped us keep things organized despite the hectic schedule of a startup.
