Как выбрать стек технологий для проекта: критерии, а не мода

Выбор стека — бизнес-решение с горизонтом 3–5 лет

Технологический стек переживает команду, которая его выбрала. Средний коммерческий продукт живёт до полной переписи 5–7 лет, разработчики на проекте меняются каждые полтора-два года, а решение о технологиях принимается обычно за один созвон и почти всегда людьми, которые не будут платить за его последствия. Поэтому правильный вопрос звучит не «что лучше», а «на чём мы сможем нанимать людей через три года, сколько будет стоить их час и кто примет проект, если текущая команда уйдёт целиком».

В момент выбора вы фиксируете три статьи расходов сразу. Первая — стоимость найма: разница в средних ставках между стеками на одном и том же уровне сеньорности достигает 30–50%, и она умножается на количество лет и людей. Вторая — стоимость поддержки: сколько времени уходит на обновление зависимостей, закрытие уязвимостей и совместимость с новыми версиями рантайма. Третья — стоимость передачи: если продукт понадобится отдать другому подрядчику или инхаус-команде, экзотический стек превращается в скидку к цене вашего актива.

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

Отдельно про то, кто принимает решение. Подрядчик — не беспристрастная сторона: любое агентство предложит стек, на котором у него прямо сейчас есть свободные разработчики, и это нормальная экономика, а не заговор. Veltos.Tech здесь ничем не отличается, и правильная реакция заказчика — попросить обоснование в терминах вашего бизнеса, а не наших ресурсов: сколько людей на этом стеке на рынке, что будет с проектом при смене подрядчика, какие части заменяемы. Если обоснование не выходит за пределы «мы это хорошо умеем», решение принимаете не вы.

Правильный порядок: бэкенд → фронтенд → инфраструктура

Классическая ошибка основателя — начать со слов «делаем на Next.js». Это ответ на вопрос о рендеринге страниц, а не на вопрос о том, где живут данные, кто считает бизнес-логику, как устроены права доступа и что произойдёт с базой, когда записей станет десять миллионов. Фронтенд-фреймворк — самая заметная и самая легко заменяемая часть системы, поэтому решать с неё означает подчинить всё остальное самому недолговечному решению.

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

Профиль нагрузки задаёт всё остальное. Много чтения и мало записи — можно жить на кэше и репликах почти на любом языке. Много одновременных соединений и мало вычислений — сильная сторона Node.js и Go. Тяжёлые расчёты, отчёты, обработка данных — Python или Java. Строгие транзакции с деньгами — реляционная база и язык со зрелой экосистемой, без экспериментов. Если на вопрос «сколько запросов в секунду вы ожидаете через год» никто в проекте не может ответить хотя бы порядком, выбор стека преждевременный: сначала нужна аналитика.

Инфраструктура решается последней по порядку, но не в последний момент по времени. Контейнеризация, схема окружений, миграции и CI должны быть определены до первой строки продуктового кода, иначе через полгода вы получите систему, которая разворачивается только на ноутбуке одного конкретного разработчика. Для российских проектов сюда же относится вопрос размещения: если вы обрабатываете персональные данные граждан РФ, базу с ними нужно держать на серверах в России, и это ограничивает выбор облачных сервисов сильнее, чем любые технические соображения.

• Сначала ответьте на четыре вопроса: какие данные, сколько их, кто и как часто их читает, какие операции обязаны быть транзакционными.
• Выбор базы данных важнее выбора языка: сменить рантайм в разы дешевле, чем мигрировать схему на десять миллионов записей.
• Фронтенд-фреймворк — обратимое решение. Если спор о нём занял больше дня, вы обсуждаете не тот слой.
• Docker, миграции и CI закладывайте в первую неделю: позже это стоит вчетверо дороже и всегда откладывается.

Критерии выбора и их веса

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

Самый тяжёлый критерий — рынок найма, и он же чаще всего игнорируется. На российском рынке разница между стеками измеряется не только количеством резюме, но и скоростью закрытия вакансии: на массовый стек мидла находят за 2–4 недели, на редкий поиск растягивается на кварталы, а найденный кандидат стоит дороже рынка, потому что понимает свою редкость. Для продукта, который планируется развивать несколько лет, это прямые деньги и прямой риск остановки.

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

Требования 152-ФЗ стоит оценивать не как формальность, а как жёсткое ограничение множества вариантов. Если продукт собирает персональные данные российских пользователей, зарубежные managed-сервисы для основной базы отпадают, часть SaaS-инструментов аналитики отпадает, а модель хранения и логирования нужно проектировать сразу, а не «привести в соответствие потом». Приведение в соответствие после запуска обычно означает миграцию данных и переписывание слоя доступа, то есть месяцы работы без единой новой функции для пользователя.

Референсные стеки для шести типов проектов

Ниже — не догма, а рабочие точки отсчёта: комбинации, которые собраны сотни раз, имеют предсказуемую стоимость поддержки и не создают проблем с наймом. Отклоняться от них можно и нужно, когда есть конкретная причина, но отклонение стоит проговорить вслух: «мы берём не типовое решение, потому что вот это требование его ломает». Если причины сформулировать не получается, берите типовое.

Для контентного и корпоративного сайта главный критерий — скорость выпуска страниц и удобство редактора, а не архитектурная элегантность. Связка headless CMS плюс Next.js с предгенерацией страниц даёт отличные Core Web Vitals и нормальную админку без разработки собственной. Для рынка, где важна интеграция с 1С и привычность подрядчиков, 1С-Битрикс остаётся рациональным выбором, несмотря на всё, что о нём принято говорить в инженерной среде.

Для SaaS и веб-приложений выбор почти всегда сводится к NestJS на TypeScript или Django на Python поверх PostgreSQL. NestJS выигрывает, когда фронтенд и бэкенд пишет одна команда и важна общая типизация. Django выигрывает, когда нужна готовая админка, права доступа из коробки и быстрый выход на первую версию. Оба варианта дают предсказуемый найм и оба спокойно доживают до нескольких сотен тысяч пользователей без экзотики.

Высоконагруженные сервисы — единственная категория, где язык действительно решает. Здесь Go на горячем пути даёт предсказуемое потребление памяти и латентность, ClickHouse закрывает аналитику по событиям, а очередь вроде Kafka или NATS развязывает компоненты. Но заходить в эту архитектуру стоит только тогда, когда нагрузка подтверждена измерениями: преждевременный переход на микросервисы и брокеры сообщений — самый дорогой способ замедлить разработку продукта, который ещё никому не нужен.

Фронтенд: React, Vue, Angular или Svelte

Начнём с неудобного факта: бенчмарки фреймворков к вашему проекту почти не относятся. Разница в скорости рендеринга между современными React, Vue, Angular и Svelte на реальном коммерческом сайте меньше, чем эффект от одной несжатой картинки в шапке или одного лишнего скрипта аналитики. Выбирать фронтенд по замерам производительности — это оптимизировать переменную, которая в вашем уравнении стоит на третьем знаке после запятой.

React в России держит первое место по объёму открытых вакансий с большим отрывом, Vue уверенно второй, Angular и Svelte заметно ниже. Для заказчика это переводится в простое правило: на React вы найдёте замену любому ушедшему разработчику, и найдёте быстро. Обратная сторона — React ничего не навязывает, поэтому качество архитектуры целиком зависит от дисциплины команды, и плохой React-проект выглядит хуже, чем плохой Angular-проект. Next.js частично закрывает эту дыру, задавая структуру и маршрутизацию.

Vue заметно приятнее для небольшой команды и людей, приходящих из вёрстки: порог входа ниже, документация лучше, шаблонный синтаксис ближе к привычному HTML. Nuxt закрывает те же задачи, что Next.js. Angular — единственный из четвёрки, кто навязывает архитектуру, и это его главное достоинство в крупных корпоративных системах с длинным жизненным циклом и постоянной ротацией разработчиков: новый человек открывает незнакомый Angular-проект и сразу понимает, где что лежит. На небольшом проекте эта же строгость превращается в лишний вес.

Svelte даёт лучший опыт разработки и самые компактные сборки, но рынок найма под него тонкий, а библиотек под нишевые задачи меньше. Разумный сценарий его применения — команда, которая уже на нём работает, или продукт, где размер бандла критичен, например встраиваемый виджет. Итоговое правило простое: если в команде уже есть фронтендер, берите стек, который он знает. Если команды нет и вы нанимаете с нуля — берите React, потому что вы покупаете не фреймворк, а глубину рынка труда.

• Есть команда — решает её опыт. Нет команды — решает рынок найма, и это React.
• Крупная корпоративная система с ротацией людей и горизонтом 5+ лет — аргумент в пользу Angular.
• Небольшая команда без выделенного архитектора — Vue снижает шанс собрать нечитаемый код.
• Svelte — осознанный выбор под конкретную причину, а не потому что «он быстрее в тестах».

Бэкенд: Node, Python, Go, PHP или Java

Node.js с NestJS хорош там, где много одновременных соединений и мало тяжёлых вычислений: API-шлюзы, чаты, real-time, слой между фронтендом и несколькими внутренними сервисами. Главный практический плюс — один язык на всём проекте: типы моделей описываются один раз и переиспользуются на обеих сторонах, что реально экономит часы на согласовании контрактов. Главный минус — синхронные тяжёлые вычисления блокируют цикл событий, поэтому обработку больших объёмов данных приходится выносить в отдельные воркеры.

Python делится на два разных инструмента. Django — это «батарейки в комплекте»: ORM, миграции, права, готовая админка, из-за которой внутренняя система собирается на недели быстрее, чем на любом другом стеке. FastAPI — лёгкий асинхронный фреймворк для API и сервисов вокруг машинного обучения, и это единственный экосистемный вход в мир ML без прослоек. Если в продукте планируется хоть какая-то работа с моделями, наличие Python в стеке экономит целый слой интеграций.

Go выбирают за предсказуемость: стабильное потребление памяти, низкая латентность под нагрузкой, деплой одним бинарником без рантайма и зависимостей. Это правильный инструмент для сервисов, которые должны держать нагрузку и работать годами без сюрпризов. Расплата — более медленное прототипирование, меньше готовых решений для типовых задач вроде админок и более дорогой найм. Брать Go на CRUD-проект с десятью пользователями в день — трата денег на характеристику, которая никогда не понадобится.

PHP имеет репутацию хуже, чем реальность. Современный Laravel — зрелый и производительный фреймворк, а на российском рынке PHP даёт самый массовый и самый дешёвый найм плюс огромную базу готовых решений в электронной коммерции. Java и Kotlin со Spring — территория корпоративных систем: строгая типизация, зрелые инструменты интеграции, длинный жизненный цикл, предсказуемая поддержка. Плата за это — самая высокая стоимость разработчика и самый медленный старт, поэтому Spring на MVP стартапа почти всегда ошибка.

• Node.js и NestJS — real-time, API-шлюзы, единая типизация с фронтендом.
• Django — внутренние системы и всё, где готовая админка экономит недели.
• FastAPI — API и сервисы вокруг ML, лёгкий вход в экосистему машинного обучения.
• Go — сервисы с подтверждённой нагрузкой и требованиями к латентности.
• PHP и Laravel — электронная коммерция, ограниченный бюджет, быстрый и дешёвый найм.
• Java, Kotlin и Spring — корпоративные системы с горизонтом 7–10 лет и жёсткими интеграциями.

Цена ошибки и как сохранить стек заменяемым

Неверный выбор стека редко выглядит как катастрофа, он выглядит как медленное удорожание всего. Сценарий первый — переписывание: продукт упирается в ограничение технологии, и команда приходит с оценкой, которая составляет 60–100% от первоначальной стоимости разработки. Важно, что платить придётся дважды: параллельно с новой версией вы продолжаете поддерживать старую, потому что она обслуживает живых клиентов, и этот двойной период редко бывает короче полугода.

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

Сценарий третий — вендор-лок. Он возникает не только через проприетарные CMS с лицензиями, но и через облачные BaaS-платформы, чьи SDK прорастают в бизнес-логику: авторизация, хранилище, функции, очереди — всё завязано на одного поставщика, и цена миграции сравнивается с ценой переписывания. Для российских проектов сюда добавляется отдельный риск доступности зарубежного сервиса, который в последние годы перестал быть теоретическим.

Заменяемость стека — это не свойство технологии, а свойство того, как написан код. Работает простое правило: бизнес-логика не должна знать, какой фреймворк её вызывает и какое хранилище под ней. Обращения к внешним сервисам прячутся за собственный интерфейс, доступ к данным идёт через репозитории, а не через ORM-вызовы посреди контроллера, окружение описано в Docker и в файлах инфраструктуры, схема БД живёт в миграциях, а не в чьей-то памяти. Проект, построенный так, меняет любой отдельный слой за недели, а не за кварталы.

• Никаких SDK внешних сервисов в доменном слое — только за собственным интерфейсом.
• Стандартные протоколы вместо проприетарных: SQL, S3 API, OpenAPI, SMTP.
• Схема базы — в миграциях в репозитории, а не в ручных правках на проде.
• Docker и описанная инфраструктура: развернуть проект с нуля должно занимать час, а не неделю.
• Репозиторий, домен, доступы и лицензии оформлены на заказчика с первого дня.

Частые вопросы

Услуги по теме

• IT-консалтинг и продуктовый аудитСамые дорогие ошибки в разработке делаются до первой строчки кода: неверно понятая задача, стек, выбранный по привычке подрядчика, и ТЗ, которого нет. Консалтинг нужен, чтобы разобраться до того, как начнётся счётчик разработки: что именно строить, из чего, за сколько и в каком порядке. Результат — документ, а не мнение на созвоне.
• Разработка веб-приложений и Telegram Mini AppКогда сайта уже мало и нужен продукт: личный кабинет, дашборд, внутренний сервис или Mini App внутри Telegram. Проектируем архитектуру, пишем бэкенд и фронтенд, доводим до релиза.
• Разработка сайтов под ключДелаем сайты, которые не разваливаются через полгода: от одностраничника на CMS до магазина и веб-приложения на React и Next.js. Один подрядчик на дизайн, код, интеграции и запуск.

Читать дальше

• На чём делать сайт в 2026: Tilda, WordPress, Битрикс или Next.jsКонструктор, CMS или собственная разработка — выбор зависит не от вкуса, а от сценария и горизонта планирования. Разбираем стоимость владения за три года, потолки платформ и цену переезда, если вы ошиблись на старте.
• Flutter, React Native или натив: что выбрать в 2026Выбор между Flutter, React Native и нативом — это решение об экономике продукта, а не о технологии. Разбираем, где кроссплатформа экономит половину бюджета, где она обходится дороже, и что меняет российская специфика 2026 года.
• Техническое задание на сайт: структура, шаблон и разбор ошибокТЗ — это не бюрократия, а рычаг: всё, что не соответствует заданию, подрядчик исправляет бесплатно. Разбираем структуру по разделам, показываем заполненный пример для корпоративного сайта и объясняем, как писать критерии приёмки, которые можно проверить.