Architecture30 сентября 2026 г.4 мин чтения

На чём делать продукт: выбор технологий глазами бизнеса

Коротко

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

Содержание
  1. 01Почему «на чём писать» — не ваш вопрос
  2. 02Критерий 1: рынок специалистов
  3. 03Критерий 2: стоимость владения
  4. 04Критерий 3: соответствие сценарию
  5. 05Критерий 4: свобода сменить подрядчика
  6. 06Критерий 5: опыт команды именно в этом
  7. 07Вопросы подрядчику вместо холивара

Почему «на чём писать» — не ваш вопрос

Заказчика часто втягивают в технический спор: React или Vue, Flutter или React Native, Node или Python. Со стороны это выглядит как выбор, от которого зависит судьба продукта, но на деле для большинства бизнес-задач подойдут несколько стеков — разница будет не в возможностях, а в стоимости владения и рисках.

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

Ниже — пять критериев, по которым можно оценить предложенный стек, не разбираясь в программировании.

Критерий 1: рынок специалистов

Самый практичный критерий. Если завтра ваша команда разойдётся, насколько быстро вы найдёте замену?

Распространённые технологии

  • Специалистов много
  • Ставки конкурентные
  • Знания легко передаются

Редкие технологии

  • Поиск может занять месяцы
  • Ценник диктует рынок из трёх человек

Мы сознательно работаем на массовом стеке: TypeScript, Node.js, PostgreSQL, React. Это не самый модный выбор на конференциях, зато вы не привязаны к нам — любая команда с этим набором продолжит работу по документации.

Критерий 2: стоимость владения

Разработка — разовый платёж, поддержка — постоянный. В стоимость владения входят:

  • хостинг и инфраструктура;
  • обновления зависимостей и безопасности;
  • доработки;
  • а главное — скорость, с которой новый разработчик разбирается в проекте.

Косвенные признаки дорогой поддержки

  • Самописный фреймворк «нашей собственной разработки»
  • Нестандартная архитектура без документации
  • Тяжёлая инфраструктура под простую задачу
  • Всё это может быть оправдано, но подрядчик должен объяснить, чем именно

Обратная крайность: конструкторы и шаблонные CMS

  • Дёшевы на старте
  • Упираются в потолок, когда нужен нестандартный сценарий
  • Тогда переписывать приходится целиком — и это дороже, чем сразу заложить запас

Критерий 3: соответствие сценарию

Технология должна соответствовать тому, что продукт реально делает. Несколько практических примеров:

Контентный сайт с задачей приводить клиентов из поиска

Что критично
Серверный рендеринг
Комментарий
Иначе поисковики и ИИ-ассистенты видят пустую страницу

Личный кабинет или внутренняя система

Что критично
Роли, права доступа и надёжная работа с данными
Комментарий
Красота анимаций вторична

Мобильный сценарий с камерой, фоновой геолокацией или офлайном

Что критично
Натив либо кросс-платформа с доступом к этим возможностям
Комментарий
Подробный разбор — в статье про PWA и приложения

Высокая нагрузка или реальное время

Что критично
Архитектура важнее языка
Комментарий
Очереди, кэширование, разделение сервисов

Критерий 4: свобода сменить подрядчика

Хороший стек не привязывает вас к исполнителю. Проверяется тремя вопросами:

  • Код лежит в вашем репозитории?
  • Инфраструктура на ваших аккаунтах?
  • Документации достаточно, чтобы другая команда вошла в проект без вас?

Это тот же принцип, что и в договоре: права на код без практической возможности им пользоваться — половина гарантии.

Критерий 5: опыт команды именно в этом

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

Вопросы подрядчику вместо холивара

Короткий список, который заменяет технический спор:

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

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

Расскажите о задаче — мы изучим запрос и свяжемся с вами

Есть задача?
Обсудим и оценим — бесплатно.

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

  • Оценка объёма и рисков до старта
  • NDA — по вашему или нашему шаблону
  • Старт работ в течение недели

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

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