Thanks for getting in touch. 50 projects certainly does sound unmanageable, and is certainly not we’d normally expect. The right answer for your scenario will depend somewhat on your needs.
The typical pattern with Octopus is to have a build server with a single build project/pipeline and Octopus with a single project. The build server produces a set of binaries, in the form of a package, and pushes it to Octopus. Octopus is then configured to understand Environments and the Lifecycle you want to use for promoting the binaries through these environments (e.g. Dev => UAT => Staging => Production). Octopus allows you to define variables scoped to each of these environments and does variable substitution into your config files etc during deployment to an environment.
In this scenario the handling of the variables is “backloaded” in the pipeline, rather than “frontloaded” as what I understood from your description.
Could you verify whether Environment here holds the same meaning as what you consider an environment? For some customers, who host multiple versions of their software for different customers of theirs (tenants in our terminology), they sometimes create a completely separate environment per tenant. This is workable but a little more complex to set up.
I won’t try to dig into too much more detail here yet, if I can understand more about your setup then I can provide the right details about the right things.