A couple of possible answers.
In my case, the ONLY qubes set to start automatically are sys-usb and (I just added) sys-audio. So there’s not much order-dependency there. If I start (say) a browser qube, it will take care of firing up sys-net-wifi and sys-firewall-wifi. Of course that makes the browser qube slow to start the very first time because it must start the other two qubes first. On the other hand, they (and the cacher) will generally start up anyway once dom0 decides to check for updates; so if I wait ten minutes (easy if you have to do something else for a while) your browser qube will start up a lot faster.
It’s also possible to have a script start a bunch of qubes. How to do this is described here: How to have VM start on boot in the background? - General Discussion - Qubes OS Forum (qubes-os.org)
In essence you can put a script in ~/.config/autostart and it will execute when you log in. You can write qvm-start commands in it with delays and/or wait options; it won’t run until after you log in (that avoids the hassle of having to wait for autostart qubes to start up before you get a login screen). I’m probably going to set this up again, actually (for reasons having nothing to do with sys-audio).