Елизавета Борисова

В JS выбора по сути немного: pixi.js для более низкоуровневой разработки, и phaser для менее.

Помимо технической стороны, у проектов такого рода есть серьезные юридические вопросы ( и Вам неплохо бы о них знать). Например,
1. Использование картографической информации серьезно ограничено. Т.к. проект предполагается коммерческим, то это совсем невесело)
2.

Весь парк автобусов оснащён системой Глонасс и всё такое прочее,

соответственно данные принадлежат некоторой госкорпорации, будете пытаться договориться ?!

Самое главное, технический масштаб проекта не соответствует объему аудитории, окупить невозможно.

pixi.js - правильное решение

В 2017 заслуживает внимания Kotlin - он создавался для поддержки очень больших java-проектов, код действительно гораздо более компактный, и nullability!)
Node.js к сожалению не так хорош для самых больших проектов, сложно поддерживать, на каком-то этапе нужно переносить.
Python тоже возможен, местами, есть примеры.

При текущей конъюнктуре рынка, в РФ инвестиции в реальный сектор в среднем малоубыточны, около 18% могут рассчитывать на прибыль выше депозита. Ситуация давно отягощается активным законотворчеством и внезапными налогами.

Ваша проблема не в ноде, а в недостатке опыта в бекенде и проектировании как таковых. Язык, базовый сервер не так важны, и на данном этапе, возможно зря отказались от django.

Доки MDN, React,Vue,Django обожаю, с ними действительно не нужны особо другие источники. Совсем другая ситуация с нодой.

В django уже реализовано многое из коробки, а на express вы сами должны писать/собирать свое django, отсюда разница в документации. Т.е. это более низкоуровневый инструмент, отсюда ваши сложности. Берите более "жирный" фреймворк поверх экспресса, или сначала реализуйте достаточно большой бекенд на django.

Потому что phaser билдят с помощью cocoon ?

Какие есть подводные камни?

1. если у стартапа нет денег на оплату труда, он может быть не оформлен или не полностью оформлен, и никто вашей долей заниматься не будет
2. доля от 0 = 0, большинство стартапов не выходят на прибыль
3. в стартапе надо много работать, побольше чем в найме бывает

- best practices сборки статичных SPA, т.е. без бекенда и всяких изоморфных извращений:)
- системы сборки (gulp, webpack, brunch, jspm и тп)
- модули AMD, CJS, UMD. Как их правильно подключать и использовать в небольших проектах.
- сборка и подключение css. postcss

Все перечисленные вопросы к качеству приложения отношения не имеют, чисто технический момент. Если нужно качественные приложения научиться делать, надо качать что-то другое, с упором на тестирование и пятую точку. Чтобы качество возникало быстрее, чем у других, в любом случае потребуется 1-3 года практики, чтобы столкнуться с распространенными подводными камнями. За практическими заданиями и codereview можно ко мне обратиться.

У нас в вузах слово системный как-то неправильно трактуется повсеместно. Даже код специальности "системный программист" зачастую вообще не соответствует программе.
По поводу архитекторов, стоит отметить, что для веба это крайне редко выделено в отдельную позицию. За архитектуру отвечает техлид/тех.дир или старший разработчик, решения принимаются из совокупности своего и внешнего опыта.

Так вот где найти примеры с наиболее полным описанием процесса взаимодействия заказчика и исполнителя?

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

Интересует изначальная словестная постановка задачи заказчика

Словесная постановка задачи обычно сопровождается документацией. Если ее нет, то нет соглашения об объекте разработки, и нет проекта. Непосредственно разработчик редко взаимодействует сам с (недо-)проектом на данной стадии, т.к. это чревато.
Документация рождается путем сбора требований и (долгого) обсуждения вариантов/деталей/стоимости, в процесс могут вовлекаться специалисты предметной области, пользователи будущей системы, третьи стороны/компании.

Вам логично выбрать libgdx или нативное android приложение. Слишком объемную игру затевать не стоит, иначе не доживете до релиза. От месяца до трех достаточно для первого раза.
По поводу девушки, слишком много разговоров, но мало действий. Не открою секрет, если скажу, что надо разное пробовать, и правило 10 тысяч часов никто не отменял. Через 10к часов и выяснится, есть ли "жилка" или нет, ну или хотя бы на полпути. Начать можно с того, что Вы сами очень хорошо знаете.

Я всё чаще в последнее время начинаю себя называть "решателем проблем программным путём", т.к. у меня нет ни математической, ни алгоритмической теории вообще.

возможно, стоит доверить обучение профессионалам. Еще Вы совместно можете алгоритмами и математикой заняться, codeforces/codewars в помощь.

Ничто Вам не мешает искать команду, которая согласится на договор с гарантийным сроком. Если не с гарантийным сроком, но с оплатой за весь проект желающих много, но это, конечно не исключает больших проблем по поводу доработок. Разумно ввести поэтапную оплату и разбить уровень реализации на 3-4 стадии, например: прототип, продукт, продукт продакшн версия, тестирование.
Если же Вы из тех заказчиков, у которых продукт не формализован, но им срочно(!), нужен гарантийный срок, и ожидается море правок со всех уровней управления, то Вам все очень правильно предлагают: либо почасовка, либо в 3р. дороже. Если Вы не it или у вас есть арт-директор, надо еще +50% взимать)

при озвучивании своего образования моя кандидатура практически сразу сбрасывается со счетов и нужно очень сильно удивить своими познаниями работодателя чтобы тебя взяли на работу

для девушек именно так и есть, не для мужчин!

Проблемы будут в двух направлениях :
1. Работа без договоров, следовательно заказчики смогут воспользоваться этим, что происходит сплошь и рядом на фрилансе. Не важно, как лажает заказчик и скольк овремени он занял, но он вам на свое усмотрение может не оплачивать работы до исполнения требований.
2. Оплата труда группе фрилансеров, Вы не можете как физлицо регулярно перечислять зарплаты.

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

setTimeout не нужно сочетать с raf, но вообще на SVG производительную игру не сделать.

Но в канвасе думаю те же свг анимированные элементы использовать

canvas работает с растром, те же не выйдет.
Для канваса, конечно же, поробуйте pixi и pixi-spine

В определенных узких нишах сертификаты будут плюсом (cisco, oracle, microsoft...), но в остальных вам нужно очень крепко подумать, прежде чем включать их в резюме. Ведь если человек догадался пойти на курсы, это может о многом говорить: у него нет профильного образования, он не посидел пару лет над специализацией сам, т.е. не наработал заветный опыт, к тому же может ожидать, что его на работе должны обучать. Еще, в связи с тем, что курсы платные, люди склонны думать, что там истину в первой инстанции глаголят(уплочено же, нужн овсе запоминать намертво!), и переучивать сложно. В общем, вы рискуете под двойной досмотр попасть при приеме на работу, если не перекроете ваши курсы стоящим опытом.