Стек технологий для разработки: как выбрать

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

Фронтенд — то, что видит пользователь: HTML, CSS, JavaScript или TypeScript и фреймворк вроде Vue, React или Angular. Для мобильных приложений сюда же относится Flutter или нативные Swift и Kotlin.

Бэкенд — серверная логика: язык (PHP, Python, Go, Java, Node.js) и фреймворк (Symfony, Laravel, Django, Spring). Здесь живут бизнес-правила, интеграции и всё, что нельзя доверить браузеру.

Хранение данных — реляционные СУБД (PostgreSQL, MySQL), нереляционные (MongoDB), кеш и очереди (Redis, RabbitMQ, Kafka), аналитические хранилища (ClickHouse).

Инфраструктура — где и как это запускается: сервер или облако, Docker, оркестрация, CI/CD, мониторинг, резервное копирование.

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

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

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

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

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

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

Самый недооценённый пункт. В обзорах стеков он умещается в строку «учитывайте опыт команды», хотя на практике решает больше, чем сравнение фреймворков.

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

В российских реалиях 2026 года широкий рынок специалистов — это PHP, Python, Java, JavaScript и TypeScript, Go набрал массу и уверенно растёт. Экзотика вроде Elixir, Scala или Haskell даёт технически элегантные решения и очень узкий рынок найма: такие проекты живут, пока в них есть тот, кто их начал.

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

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

React — самый большой рынок и экосистема, много готовых решений, широкий выбор специалистов. Цена — свобода в архитектуре: одинаковых проектов на React не бывает, и качество сильно зависит от команды, которая задала правила.

Vue — более цельный и предсказуемый: в нём меньше способов сделать одно и то же, порог входа ниже, код разных команд похож. Именно поэтому Vue и TypeScript — наш продуктовый выбор: на длинных проектах предсказуемость дороже гибкости.

Angular — самый структурированный и тяжёлый, со встроенными решениями почти на всё. Уместен в крупных корпоративных системах с большими командами и долгим жизненным циклом.

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

Здесь больше всего мифов. «PHP умер», «Go для всего», «Node.js потому что один язык на фронте и бэке». Реальность прозаичнее: у языков разные сильные стороны, и выбор диктует задача.

Постановка «выбрать между SQL и NoSQL» устарела: в реальном продукте обычно есть и то и другое, каждое под свою задачу.

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

Нативная разработка — Swift для iOS и Kotlin для Android. Максимальный доступ к возможностям платформы и предсказуемое поведение, но две кодовые базы: две команды, два бюджета, двойные правки на каждое изменение.

Кроссплатформенная разработка на Flutter — одна кодовая база на обе платформы, интерфейс неотличим от нативного, скорость выше. Это наш основной мобильный стек; нативные вставки добавляем там, где нужны специфические возможности устройства.

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

React Native и Kotlin Multiplatform на рынке есть, и мы честно говорим, что не работаем с ними: держать глубокую экспертизу в трёх кроссплатформенных технологиях одновременно нельзя, а поверхностная в продакшене опаснее её отсутствия.

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

Локализация персональных данных. Данные российских пользователей должны обрабатываться на серверах в России. Практически это означает: основное хранилище — в российском облаке или на своём железе в РФ. Зарубежные облака в контуре продукта с персональными данными — прямой юридический риск.

Реестр отечественного ПО. Для госкомпаний, объектов КИИ и части закупок нужны решения из реестра Минцифры, а требования к нему в 2026 году ужесточились. Это влияет на выбор СУБД (Postgres Pro), операционных систем (Astra Linux, РЕД ОС) и отдельных компонентов инфраструктуры.

Из российских облаков в проектах обычно фигурируют Yandex Cloud, VK Cloud и Cloud.ru — они закрывают базовые потребности: виртуальные машины, управляемые базы, объектное хранилище, Kubernetes.

Инфраструктурный минимум, который стоит требовать в любом проекте независимо от стека: Docker для повторяемого окружения, автоматический деплой через CI/CD, мониторинг с алертами, регулярные бэкапы с проверкой восстановления. Отсутствие последнего пункта обнаруживается всегда в один и тот же момент.

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

Отдельный сюжет, с которым к нам приходят чаще всего: «у нас старый код, нам говорят переписать с нуля». Иногда это правда, чаще — нет.

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

Рабочая альтернатива — постепенное вытеснение: новые модули пишутся на новом стеке рядом со старым, трафик и функции переносятся частями, старая система постепенно теряет ответственность и в какой-то момент отключается. Дольше по календарю, безопаснее по риску, и продукт всё это время работает.

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

Мы не пытаемся уметь всё — держим глубокую экспертизу в ограниченном наборе и говорим об этом прямо.

Бэкенд — PHP с Symfony и Laravel как основной, Go для нагруженных сервисов, Python для ML-части и обработки данных. Фронтенд — Vue.js и TypeScript, с серверным рендерингом там, где нужен поисковый трафик. Мобильное — Flutter, нативные Swift и Kotlin под особые задачи. Данные — PostgreSQL как основа, Redis и очереди, ClickHouse под аналитику. Инфраструктура — Docker, CI/CD, российские облака.

Чего мы не берём: React как продуктовый стек (наш выбор — Vue), React Native и Kotlin Multiplatform, десктопные приложения на Electron — вместо них предлагаем PWA, — а также Bitrix в роли платформы для продукта. Это не оценка технологий, а честная граница компетенции.

Про деньги, чтобы разговор был предметным. Если выбор стека сам по себе — задача (нужно спроектировать решение, сравнить варианты или проверить смету другого подрядчика), это консалтинг: 300–900 тыс. ₽ в зависимости от объёма. Аудит существующего кода и архитектуры — 200–600 тыс. ₽. Разработка веб-продукта начинается от 1 млн ₽, продукта под сложный бизнес-процесс — от 1,7 млн ₽.

Точная сумма зависит от задачи, а оценка проекта у нас бесплатная и быстрая: опишите, что нужно сделать — вернёмся с архитектурным решением и сметой по этапам.

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

Гнаться за новизной. Технология с прошлогодней конференции может оказаться прекрасной — а может лишиться поддержки. Для продукта на годы важнее зрелость и размер сообщества.

Игнорировать найм. Стек, на котором в вашем регионе три специалиста, превращает команду в единственную точку отказа.

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

Забыть про требования закона. Локализация данных и реестр отечественного ПО — не бюрократия, а условия ввода в эксплуатацию. Проверять их надо до проектирования.

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

Короткий чек-лист, чтобы проверить обоснованность предложенного стека, не будучи техническим специалистом:

• Почему именно эти технологии для нашей задачи, а не более распространённые?
• Сколько специалистов на рынке смогут поддерживать это, если мы расстанемся?
• Что будет со стеком, если нагрузка вырастет в десять раз?
• Какие лицензии платные и сколько стоит инфраструктура в год?
• Где будут храниться персональные данные и подходит ли решение под требования реестра, если они к нам применимы?
• Как вы обеспечите повторяемость окружения, деплой и бэкапы?
• Что из существующих у нас систем и кода можно переиспользовать?

Если на большинство вопросов отвечают уверенно и с обоснованием — стек, скорее всего, выбран под задачу. Если ответы сводятся к «это современно и всем нравится», стоит попросить второе мнение.