Капитан Пронин

Приходящие данные разбирать, десериализуя JSON, и сохранять в обычную реляционную СУБД с колонками на каждое поле в JSON. Затем составить запрос с группировкой по категории и последующим выводом результата в формате JSON.

а договора небыло. просто был прислан текстовый файл с заданием и я ответил что сделаю это.

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

Так что проще всего максимально оградить от проблем изначально, чтобы избежать недопонимания, как описал Владимир Коротенко . Ну и финансовая сторона. И действовать поэтапно, не выполняя работы без оговоренной предоплаты
Сроки и всё такое - должно быть описано, чтобы всегда был пункт

б) а если "так", то будет "вот так".

Это можно писать простым языком, не юридическим. Никому не хочется заниматься с судами и многие вопросы лучше заранее решать за их пределами.
Так что условия доставки ПО нужно хорошо обговорить. Кому-то достаточно доступа к GitHub,а кому-то нужно развернуть прямо в продакшен сервере. И даже на Маке ))

429 Too Many Requests

Уменьшить частоту запросов (не логично ли?). Не нужно "бомбить" сайт.

Стоит посмотреть на возвращаемые заголовки и посмотреть на заголовок Retry-After. Попытаться перезапланировать задачу скрэпинга на время согласно рекомендации заголовка.

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

Если схематично, то как-то так:
User flow / UX -> wireframe -> tech. design -> API contracts (OpenAPI) -> front-end + back-end (параллельно, начиная с API mocking).

Весь цикл разработки должен происходить итеративно, с поправками. Невозможно продумать всё до мелочей.
Разработаете прототип по этой схеме и продолжаете наращивать функции, по не будет достигнут MVP.

Добавлено:
И важно понять - ТЗ обычно не бывает, ибо всё делается на ходу. ТЗ это больше про средне-крупные организации, которые могут себе позволить это, теряя в скорости и делая упор на точность и соответствие по контракту.
А с макетами уже вполне можно работать в малых командах.

Есть много вопросов к тому что из себя будет представлять конечный программно-аппаратный комплекс и для каких условий работы он предназначен. Одно дело, когда он расположен где-то в "тепличных" условиях в офисе/дома. И совсем другое дело, когда находится в шумном и пыльном цехе, где по кнопкам и экрану будут тыкать грязными руками. Ко второму должны предъявляться совсем другого уровня требования по надежности и не только.

физически подключать свой ноут к серверу

В смысле? Пойдут в серверную и будут подключать ноут к серверу кабелем? Что за бред? Если не бред, то по какому протоколу? И этот ноутбук нужен для постоянной работы с оборудованием? Или "сервером" будет достаточно мощный ПК? ПК и ноутбук в цехе? Серьёзно?

с видеокамер на которых отображается деталь

Это видеокамеры со встроенными экранами? Или же без, а изображение должно передаваться по кабелю на сервер?

будет потоковое видео и его обработка

К потоковой обработке видео, я полагаю, есть достаточно высокие требования и к железу и к коммуникациям (ширина канала, задержки, кабели, маршрутизаторы и т.д.). Должен быть чип DSP (если встраиваемое оборудование) или достаточно мощный процессор на ПК/сервере, который потянет обработку.

web или desktop

Десктоп - настольное оборудование, web - передача данных преимущественно по HTTP. Одно другому не мешает. Наверное, речь больше про выбор клиент-серверной технологии, таких как терминал-сервера с терминал-клиентами (Citrix и др.) или же комбинированного оборудования с периферией (допустим, ПК с подключеннами экраном, веб-камерой и другими устройствами). Из-за необходимости обработки видео терминал-сервер, похоже, не подходит.

Если, скажем, брать (промышленный) вариант ПК, тогда обработка видео будет происходить на нём и по сети гонять ничего не надо. Тогда настольное приложение может состоять из модулей обработки видео, бизнес-логики и пользовательского интерфейса - всё в одном. Для настольных приложений обычно берут C# (WPF), C++ (Qt), Delphi, Java (Swing, JavaFX). Модуль обработки видео можно использовать, подключив как библиотеку (SO, DLL), реализованную на любом высокопроизводительном ЯП.

Веб-технологии пока достаточно специфичны и ограничены. У меня нет пока представления как происходит пакетная обработка видео в вебе. WASM едва только пробует войти в веб и мало распространён. Одно дело на веб-приложении крутить фильмы, а нечто другое - обрабатывать на лету и встроить в пользовательский интерфейс. Так что к настольным веб-приложениям я пока несколько скептически отношусь. Они пока не предназначены для промышленного использования.

Wix ?

Есть множество генераторов статических сайтов. Например, Jekyll

Jekyll - из самых простых, наверное. Там же и про хостинг написано.

По-большей части DevOps - это сисадминство, сопрягать и настраивать (в основном скрипты и языки) различное ПО и ОС, умение интегрировать облачные сервисы и строить системы для разворачивания ПО. Это не столько инженерия программирования, сколько умение разбираться в зоопарке технологий и практик. Что-то типа инженера-механика, мастера на все руки. Как верно замечено другими - автоматизация инфраструктуры (для ИТ-предприятий).
Упор нужен на знание инструментария ОС, комп. сети, информационную безопасность. Чтобы понимать как строить системы из готовых компонентов.
C# будет скорее всего лишним, а вот Питон очень понадобится и не раз.
Шаблоны проектирования - для общего образования, чтобы понимать откуда ноги растут.
Нужно знать что как работает DNS, HTTP и прочие протоколы. Как интегрировать различные облачные сервисы, строить системы для разворачивания ПО и пр.
SQL - не столько сам язык, как о том как оптимизировать план запроса к СУБД, резервировать и восстанавливать данные, реплицировать и другие функции DBA.
Веб-разработка, теория компиляторов и алгоритмы - скорее не надо. В случае необходимости всегда можно открыть книгу, статью или видео в интернете и дополнить свои знания.

Возможные причины:
1. Хостинг видео медленно отдает файлы.
2. Неустойчивая мобильная связь или недостаточная ширина канала.
3. Плохая аппаратная поддержка кодека видео.
4. Излишне загруженный JS скриптами сайт.

А среди облачных хранилищ рассматривали вариант с S3-совместимыми хранилищами, кои имеются в России и не только? У них ведь другие цены. Кроме AWS есть и другие игроки. Есть Oracle Cloud, Google Cloud, Azure Blob storage и прочие. Плюс ко всему, есть множество решений по CDN.
В дополнение ко всему, с точки зрения модели бизнеса вы можете разделить на хранение небольшого размера файлов и большого, где можно подобрать какое-то особое решение.

Зависит от используемых технологий. Нужно мигрировать в .Net 5 (Core) или использовать Mono.

Попробуйте Vanilla JS как замену jQuery.
А вообще рано списывать со счетов jQuery, поскольку у компаний есть много legacy кода.

Верное направление мышления.
Вот тут похожий вопрос был задан:
Как спарсить иностранный сайт с переводом?

куда как заливать чтобы он работал 24/7 (в vds?)

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