Saboteur

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

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

Разделить разработку и поддержку.

Разработка - на тестовом енвайрнменте с тестовыми данными
Поддержка - ограниченным кругом доверенных специалистов.

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

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

Если же вы пишете сложный продукт, для которого нужно человек 5-10, им нужно согласовывать и стандарты и стек технологий, и чтобы упростить - не пишут велосипеды, а берут какой-то готовый движок.
А если вы сервер хостите где-то в облаке, следует обратить внимание, будет ли этот движок обновляться, или через 5 лет облако скажет "мы едем на новую версию ОС, где ваш движок не работает, переезжайте на другую версию или другой движок"

Совсем другой вопрос что дейсвительно существует море "усложнятелей", но об этом полно и анекдотов и реальных историй. Так что в данном случае нужен архитектор или грамотный менеджер, который понимает и необходимости бизнеса, чтобы работать и адаптировать ТЗ, и понимает риски со стороны технологий, чтобы выбирать или одобрять на чем будет это все написано, где хоститься и так далее.

Даже по названию папки понятно откуда она так называется. public слово понятно, html понятно.
Дефолтные настройки веб сервера для персональных страничек пользователей.
При включении они доступны по адресу www.site/~username

так и называется oauth.
Выдача токенов.
Обычное апи для авторизации + документация как ваше API использовать и интегрировать в другие сайты

web api, это api по веб протоколам (обычно http/https).

1. Под капотом скриптом написанном на JS(+CSS) одни элементы прячутся, другие отображаются.
2. При помощи того же JS идет обращение к сайту по API и запрашивается необходимая информация (технология называется ajax).

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

конечно в базе данных.

Начал практиковать qt, но как я понимаю написание дескоптных приложений на плюсах - такое. Тогда хочу попробовать разработку ПО, cофтов, драйверов и тд. Что можете посоветовать по изучении этой темы?

Что значит "такое"? Сложно, долго, неудобно?
Так да, программирование это не тяп-ляп и готово, это долго, скучно, неудобно.

Что такое разработка ПО и софтов по-вашему? Или десктопные приложения это не ПО и не софт? А что тогда?

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

Скачать страницу не браузером.

Ну то есть? Берешь и рисуешь колокольчик, если для юзера есть непрочитанные новости.
Алгоритм чего? Отрисовки надо или как gif колокольчика вставить?

Или (вруг) ты не знаешь про cookies?

Если что-то в готовом решении кажется сложным, значит ты не уловил какие именно проблемы успели порешать те, кто это решение писал.

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

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

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

С хрена ли это работа девопса? Поднять и запустить проект программист не способен?
Девопс на отдельную ставку - это оркестрация сотнями и тысячами виртуалок/контейнеров/пайплайнов и так далее.

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

но не просто в виде exeшника файла, а отдельного, опять же, десктоп приложения но с большим функционалом

Чем отличается приложение в виде экзешника от десктоп приолжения с большим функционалом? размером экзешника или ты плохо понимаешь что такое экзешник?

Здравствуйте, появилась идея создать кроссплатформенное приложение: ВЕБ + ДЕСКТОП

Отлично. Язык выбрал, а платформу ты какую выбрал для кроссплатформенности?
А еще лучше, какие ты уже приложения сделал, хотя бы некроссплатформенные?

Хочу синхронизировать десктоп приложение с веб составляющей

чего?

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

нарисуй в блокноте примерный вид админки который ты хочешь, со всеми кнопочками (может быть несколько страниц), потом опиши его словами.

Можно тщательнее узнавать техзадание, перед тем как браться за работу.
Сейчас у тебя появился опыт, что нужно с заказчиком уточнить вопрос инфраструктуры, прежде чем браться за заказ.
А так - нет никаких "нельзя" или "можно". Есть договоренности и оплата.
ДевОпс - это тоже не универсальный человек. Если девопс проработал с виртуализацией 5 лет, а потом его попросили разобраться с AWS - он будет также смореть на новые ворота.