Руслан Юсупов

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

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

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

P.S. Не тот программист хорош, кто старый мир разрушит и по-своему накосячит (а это обязательно произойдет), а тот, кто может огрехи найти, осмыслить и исправить без ущерба для бизнеса, который этот софт обслуживает. При этом, не забывая о разработке новых фич. (С) Я 2017

Я бы в лично заявил руководителю что-нибудь такое.

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

Аргументировать надо тем, что стоимость поддержки возрастает кратно, вероятность накосячить тоже, причем не по вашей вине.

Грубо говоря на вот эту фичу я потратил Х, а если была бы нормальная система, потратил бы Х/5, и хотя Х величина не такая уж большая, за Y времени набегает сумма сравнимая с переписыванием. Но отдаем мы только проценты по техническому долгу, а тело все увеличивается и увеличивается, и за Y*2 мы потеряем вот столько.

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

Первые четыре абзаца вопроса тоже хорошие, можно их использовать.

Никак

Они или дойдут до етого сами и тогда наймут приличного СТО, который с большой вероятностью уволит всю команду

Или не дойдут и медленно умрут

Если менее критично, то тебе нужно искать книги по практике переговоров

Также стоит убрать дизайнера от руководства тех деталями

react - clojure
https://www.youtube.com/watch?v=WssdWSbAPKE

Чаще всего так
5 тел пилят бек, 5 фронт
Просирают сроки напроч

Приходит один синьйор и за два дня переписывает все с 0

Для поисковиков нужна статичная хтмлка - ее кто-то должен рендерить
Реакт и ко такое умеют, ангуляр также.
Тк все там нода, то таким занимаются фронтендщики.
Бекенду остается делать апи для всего етого хозяйства

Если изначально рулили бекендеры, то реакты и ангуляры будут занимать нишу jQ

В каждом (длинном) проекте все происходит по-своему

каждая несчастливая семья несчастлива по-своему