Adamos

/**
     * Recursively collects all sub-companies IDs into $list
     */
    private function getSubcompaniesIds(CompanyInterface $company, array &$list)
    {
        $childCompanies = $this->companyRelationsResolver->getChildCompanies($company)->getItems();
        foreach ($childCompanies as $childCompany) {
            $list[] = $childCompany->getId();
            $this->{__FUNCTION__}($childCompany, $list));
        }
    }

Для основных сущностей, представленных самостоятельными классами - не стоит, головной боли будет больше, чем пользы.
А вот для вспомогательных (например, для хранения данных прикрепляемых к экземплярам разных классов файлов) - вовсю используется и описано в документации как Polymorphic Relationships.

При запуске системы никакой пользователь по умолчанию не загружается.
Это происходит при запуске DE (точнее, в DM), и действия по смене зависят от того, какое оно у вас.
У меня, например, автологинящийся пользователь прописан в /etc/lightdm/lightdm.conf

Если сайт активно использует ajax или вообще построен на React/Vue/etc - хрен вы "выкачаете" его контент, не эмулируя браузер.
Впрочем, вопросы с терминологией "потери внешнего вида" - это к авгурам.

Какой сервис посоветуете который позволит выписывать счета?

По-хорошему, это должна делать ваша CRM.
Платежная система тут не имеет смысла, оплата по счету приходит на ваш собственный банковский счет.
А вот бухгалтер, который будет проверять поступления и каким-то образом инициировать подписку по факту оплаты - понадобится.

В основу CMS должна ложиться сумма опыта по типовым проектам.
В качестве первого пет-проекта ее делать совершенно бессмысленно: либо выйдет нежизнеспособная дичь, либо - и скорее всего - просто завалит сложностью задачи и не выйдет ничего.

Сисадмин ещё спросил:
– А что из этих четырёх самое непрочное?
– Стыки между ними, – ответил Учитель.

Самое страшное в инновациях наших чиновников - это переходный период ;)
В теории цифра - это здорово и просто, но "гладко было на бумаге" - в реальности можно лихо накосячить при переносе данных и вполне возможной нестыковке данных ПФР и отделов кадров. Те данные, что были занесены в трудовые до 1997 года, официально и сразу признали непереносимыми.
Ну, и если у кого в трудовой вдруг были благодарности, то они так на бумаге и останутся... впрочем, они только той бумаги и стоят.

Теоретически - виртуалка все эмулирует, и никакие действия не могут выйти наружу.
Практически - https://ru.lmgtfy.com/?q=уязвимость+virtualbox

Скорее всего, ваш "проект" так успешно "продался" именно потому, что

Мы то сами не разработчики ни разу да и в технологии шарим "поверхностно"

Не разбираясь в технологиях, можно предлагать очень крутые плюшки, вступающие в непримиримое противоречие с технической реальностью. И теперь вам всего-то нужно - найти за копейку спецов, которые создадут по вашим фантазиям продукт, не имеющий мировых аналогов, на самой хайповой технологии десятилетия... к успеху идете, чо.

"Ведущие издатели очень заинтересованы в нашей ААА-игре об ограблении корованов, теперь нужно только ее написать".

Для обучения существуют учебники. По питону - хоть для 10 лет.
Если вы не можете изучить простой Питон по учебнику, который все разжевывает и кладет в рот - вам не стоит идти в IT в принципе.
Чтобы найти и скачать учебник в интернете, деньги не нужны.

Видеокурсы и подкасты - это иллюзия образования. Они тратят больше времени, чем чтение учебников и документации, при этом материал запоминается значительно хуже - это однозначно установлено психологами... но, конечно, в рекламе вам об этом не расскажут.

З.Ы. Автор ответа учил свои первые четыре языка исключительно по учебникам.

Застойный простатит к 30 легко заработает и обычный геймер-задрот, для этого профессионального образования не требуется. Достаточно прилипнуть к креслу.
Подобные проблемы есть следствие не профессии, а сидячего образа жизни. Вот туннельный синдром и остеохондроз действительно - болезни профессиональные... или, опять же, геймерские.

Тот код, в котором вы собрались делать "редирект" - это скрипт, вызванный обращением СЕРВЕРА Робокассы к вашему СЕРВЕРУ.
Причем произойти это обращение может через три часа после того, как клиент давно ушел с сайта, решив, что заплатить у него не получилось, только деньги сняли (потому что у какого-нибудь Мегафона пробка на серверах).

Просто вы, как и многие новички, не поняли, как работает оплата в платежных системах, и городите нереальные велосипеды. Изучайте дальше и приспосабливайте свою логику под реальность.

Например, взять генератор QR-кодов на чистом PostScript и дописать в него цикл из ста тыщ вызовов "начать страницу - поместить нужный код в нужное место - закончить страницу".
И отправить на печать поверх тех листовок. Можно предварительно отдистиллировать PDF и проверить, что получилось.

Это может работать, если вы можете идентифицировать пользователя и ваша страница активно общается с сервером по AJAX.
При открытии пользователю назначается токен, который сверяет сервер при каждом запросе.
При открытии второй вкладки будет сгенерирован другой токен, так что запросы с первой станут получать отлуп.

Иначе определить, закрыл ли пользователь предыдущую страницу перед открытием новой, вы на сервере никак не сможете.