МК

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

Как выбрать стек технологий для IT-проекта: критерии оценки, сравнение фреймворков, баз данных и инфраструктуры. Гайд для тех, кто принимает решения, а не пишет код.

15 мин чтения

Неправильный выбор стека — одна из самых дорогих ошибок в IT. Не потому что «технология плохая», а потому что она не подходит под задачу. Стартап на Java EE будет запускаться год вместо трёх месяцев. Высоконагруженный финтех на WordPress не выдержит 1 000 одновременных транзакций. По статистике CB Insights, 18% стартапов называют «неправильный продукт/технологию» среди причин провала — это третья по частоте причина после отсутствия рынка и нехватки денег.

Эта статья — для тех, кто принимает решения (CEO, CTO, product owner), а не для разработчиков, спорящих о React vs Vue. Мы разберём: какие критерии действительно важны, какие стеки подходят для каких проектов, и как не оказаться заложником «модной» технологии, которую некому поддерживать.

18%
стартапов провалились из-за неправильной технологии
x2-3
удорожание при смене стека на продакшене
5 лет
минимальный горизонт, на который выбирается стек

7 критериев выбора стека (по убыванию важности)

1
Бизнес-задача и тип продукта. Это определяет 70% выбора. E-commerce — PHP (Laravel) или Node.js (Next.js). Финтех — Java, Go, Rust. Аналитика и ML — Python. Корпоративный портал — .NET, Java. Не технология определяет задачу, а задача определяет технологию
2
Доступность разработчиков. Самая элегантная технология бесполезна, если вы не можете найти людей. Проверяйте: количество вакансий и резюме на hh.ru, стоимость разработчика (грейды junior/middle/senior), наличие сообщества в России. Elixir — отличный язык, но найти Elixir-разработчика в Воронеже — квест
3
Time-to-market. Если нужен запуск за 2-3 месяца — выбирайте стек с богатой экосистемой (Django, Rails, Next.js). Если горизонт 6-12 месяцев — можно взять Go или Rust для производительности. MVP строится на скорости, а не на идеальной архитектуре
4
Масштабируемость. Сколько пользователей ожидаете через 2 года? До 10К DAU — почти любой стек справится. 10-100К — нужна правильная архитектура (не обязательно Go/Rust). 100К+ — архитектура критична, язык вторичен (Netflix на Java обслуживает 200М+ пользователей)
5
Зрелость экосистемы. Фреймворк, которому 2 года, может исчезнуть через год. Django (20+ лет), Spring Boot (10+ лет), React (10+ лет) — доказали жизнеспособность. Проверяйте: частота релизов, количество контрибьюторов, крупные компании-пользователи
6
Безопасность и compliance. Для финтеха, медицины, госсектора — критично. Java и .NET имеют зрелые библиотеки безопасности, сертифицированные криптопровайдеры. Python и Node.js — тоже годятся, но требуют большего внимания к зависимостям (npm supply chain attacks)
7
Стоимость владения (TCO). Не только разработка, но и серверы, лицензии, поддержка. Java-приложение съедает 512MB-2GB RAM (сервер от 2 000 руб/мес). Go-приложение — 50-200MB (сервер от 500 руб/мес). Разница за год: 18-36К. Для стартапа — ощутимо, для enterprise — неважно

Антипаттерн: «наш CTO любит Haskell». Личные предпочтения — худший критерий выбора стека. CTO уйдёт — и вы останетесь с кодовой базой на Haskell, для которой невозможно найти разработчиков. Стек выбирается по бизнес-критериям, а не по хобби технического директора.

Фронтенд: React, Vue, Angular — что и когда

React (Next.js)

Когда выбирать: 70% проектов. Самая большая экосистема, максимум разработчиков на рынке, универсален для любого типа интерфейса. Next.js добавляет SSR/SSG для SEO, API-маршруты, встроенную оптимизацию.

Стоимость разработчика: Junior — от 80К/мес, Middle — 150-250К/мес, Senior — 250-400К/мес.

Реальный пример: March Code использует Next.js + React как основной стек для веб-приложений. Этот сайт, корпоративные сайты и дашборды для клиентов — всё на Next.js.

Vue (Nuxt)

Когда выбирать: если в команде уже есть Vue-экспертиза, или проект относительно простой (админка, внутренний портал). Порог входа ниже, чем у React, документация отличная. Но экосистема меньше, разработчиков на рынке меньше.

Стоимость разработчика: на 10-15% ниже, чем React (меньше спрос → меньше зарплаты).

Angular

Когда выбирать: крупные enterprise-проекты с командой 5+ фронтендеров. Angular навязывает строгую архитектуру (DI, модули, сервисы) — хорошо для больших команд, избыточно для маленьких. TypeScript by default. Развивается Google.

Когда НЕ выбирать: стартапы, MVP, маленькие проекты. Boilerplate-код в Angular — x2-3 по сравнению с React/Vue.

Без фреймворка (HTMX, Alpine.js)

Когда выбирать: контентные сайты, лендинги, серверные приложения с минимумом интерактива. HTMX + серверный рендеринг (Django, Laravel, Rails) — мощнее, чем кажется. Нет билд-шага, нет npm-зоопарка, минимум JS.

Бэкенд: Node.js, Python, Go, Java, PHP

Node.js (NestJS, Express, Fastify)

Плюсы: один язык на фронте и бэке (JS/TS), огромная экосистема npm, отличная асинхронность для I/O-задач. Минусы: однопоточность (CPU-bound задачи тормозят), «callback hell» в legacy-коде, качество npm-пакетов неровное. Лучше всего для: API-сервисы, реалтайм-приложения (чаты, уведомления), BFF (Backend For Frontend).

Python (Django, FastAPI)

Плюсы: читаемость, скорость разработки, лучшая экосистема для ML/AI, Django — «батарейки включены». Минусы: медленнее Node.js/Go в чистых бенчмарках (но для 90% задач это неважно). Лучше всего для: MVP, аналитика, ML-проекты, REST API, AI-продукты.

Go

Плюсы: скорость (близко к C), низкое потребление ресурсов, встроенная конкурентность (goroutines), статическая типизация. Минусы: меньше разработчиков на рынке, беднее экосистема (нет аналога Django/Rails). Лучше всего для: микросервисы, высоконагруженные API, инфраструктурные сервисы, CLI-инструменты.

Java (Spring Boot)

Плюсы: зрелость (25+ лет), enterprise-экосистема (Spring, Hibernate), JVM-оптимизация, много разработчиков. Минусы: verbosity (много кода), высокое потребление памяти, долгая компиляция. Лучше всего для: банкинг, страхование, enterprise ERP/CRM, крупные системы с командой 10+.

PHP (Laravel)

Плюсы: самый дешёвый хостинг, огромное количество разработчиков, Laravel — элегантный фреймворк. Минусы: репутация (хотя PHP 8.3 — вполне современный язык), потолок производительности ниже. Лучше всего для: e-commerce, контентные сайты, CMS, если бюджет ограничен и нужен быстрый старт.

Правило 80/20 для выбора бэкенда

Если вы не знаете, что выбрать — берите Node.js (NestJS) или Python (Django/FastAPI). Они покрывают 80% бизнес-задач, имеют максимум разработчиков на рынке, масштабируются до 100К+ пользователей при правильной архитектуре. Go и Java — для случаев, когда вы точно знаете, зачем они вам нужны.

Базы данных: PostgreSQL, MongoDB, Redis

PostgreSQL

Универсальный выбор для 90% проектов. Реляционная, ACID-совместимая, с поддержкой JSON (нереляционные данные), полнотекстового поиска, геоданных (PostGIS), векторных вложений (pgvector для AI). Бесплатная. Если сомневаетесь — берите PostgreSQL.

MongoDB

Документоориентированная. Хороша для: логов, аналитических данных, контента с произвольной структурой, прототипов. Плоха для: транзакционных систем (финансы, заказы), данных со сложными связями. В 80% случаев, когда выбирают MongoDB, PostgreSQL справился бы лучше.

Redis

In-memory хранилище. Используется как кэш (сессии, частые запросы), очередь сообщений, pub/sub. Не замена основной БД, а дополнение. Ускоряет приложение в 10-100 раз для кэшируемых данных.

ClickHouse

Аналитическая СУБД от Яндекса. Для OLAP-запросов (аналитика, отчёты, дашборды) — в 100-1000 раз быстрее PostgreSQL. Не подходит для транзакционных операций (CRUD). Используйте как дополнение к PostgreSQL для аналитики.

Инфраструктура: Docker, Kubernetes, облака

Docker

Контейнеризация — стандарт в 2026 году. Docker гарантирует: «если работает на моём компьютере — работает на сервере». Для 90% проектов достаточно Docker + docker-compose. Стоимость: 0 (open-source) + VPS от 1 000 руб/мес.

Kubernetes

Оркестрация контейнеров. Нужен при: 10+ микросервисов, автоскейлинге (нагрузка скачет в 10+ раз), требовании high availability (99.99%+). Не нужен при: монолитном приложении, команде без DevOps-инженера, бюджете до 500К. Kubernetes добавляет сложность — убедитесь, что получаете от неё пользу.

Облачные платформы

Yandex Cloud — лидер в России, серверы в РФ (152-ФЗ), хорошая интеграция с российскими сервисами. VK Cloud — альтернатива, растёт. Selectel — bare-metal и VPS, хорошее соотношение цена/качество. AWS/GCP — если нет требований к локализации данных, максимальная экосистема.

Рекомендации по типам проектов

MVP / стартап

Стек: Next.js + NestJS (или FastAPI) + PostgreSQL + Docker + VPS. Почему: максимальная скорость разработки, один язык (TypeScript) на фронте и бэке, дешёвый хостинг. Смена стека на более «серьёзный» — когда будет product-market fit и деньги.

E-commerce

Стек: Next.js + Node.js (NestJS) + PostgreSQL + Redis + Elasticsearch. Почему: SSR для SEO, Redis для кэширования каталога, Elasticsearch для поиска. Альтернатива: Laravel + Vue, если нужен быстрый старт с меньшим бюджетом. Подробнее — в статье как создать интернет-магазин.

Корпоративная система (ERP, CRM)

Стек: React + Java (Spring Boot) или .NET + PostgreSQL + RabbitMQ. Почему: строгая типизация, enterprise-библиотеки, транзакционная надёжность. Для российского рынка: 1С как учётное ядро + кастомный фронтенд.

AI/ML-продукт

Стек: React + Python (FastAPI) + PostgreSQL + Redis + Celery. Почему: Python — единственный разумный выбор для ML-бэкенда (TensorFlow, PyTorch, scikit-learn, LangChain). FastAPI — async, быстрый, типизированный.

Мобильное приложение

Стек: Flutter или React Native + Node.js/Python + PostgreSQL. Почему: кроссплатформенная разработка (iOS + Android из одной кодовой базы). Flutter vs React Native — зависит от требований к нативному UX.

FAQ: частые вопросы о выборе стека

Можно ли сменить стек после запуска?

Технически — да. Практически — это стоит x2-3 от первоначальной разработки и занимает 3-12 месяцев. Фронтенд менять проще (React → Vue — 1-2 месяца). Бэкенд сложнее (Python → Go — 3-6 месяцев, переписывается вся логика). БД — самое болезненное (миграция данных, изменение структуры).

Стоит ли использовать микросервисы с самого начала?

Нет. Начинайте с монолита (или «модульного монолита»). Микросервисы оправданы при: 10+ разработчиках, разных языках/стеках в разных частях системы, необходимости независимого масштабирования компонентов. Для 90% проектов монолит — правильный старт.

Что важнее — скорость разработки или производительность?

Для MVP и стартапа — скорость. Для высоконагруженных систем (1000+ RPS) — производительность. Для всего остального — скорость разработки + оптимизация узких мест. Преждевременная оптимизация — зло: вы потратите месяц на 10% ускорения, которое никто не заметит.

Как оценить квалификацию подрядчика по стеку?

Спрашивайте: почему выбран этот стек (должны обосновать бизнес-задачей, а не «мы так привыкли»), какие альтернативы рассматривали, какие проблемы ожидают и как будут решать. Подрядчик, который говорит «мы делаем всё на [единственная технология]» — красный флаг. Подробнее — как выбрать подрядчика.

Насколько важен TypeScript?

Критически — для проектов с 2+ разработчиками. TypeScript ловит 30-40% ошибок на этапе компиляции (до того, как они дойдут до пользователя). Для solo-разработчика на прототипе — можно обойтись JavaScript, но при масштабировании TypeScript экономит сотни часов на отладке.

Стоит ли использовать low-code/no-code платформы?

Для прототипов и внутренних инструментов — да (Retool, Bubble, AppSheet). Для продакшн-продукта — нет. Low-code ограничивает кастомизацию, привязывает к платформе (vendor lock-in), плохо масштабируется. Используйте для валидации идеи, потом переписывайте на нормальном стеке.

Об авторах

Команда «Мартовский Код»

Мы — студия разработки из Краснодара. Помогаем бизнесам переводить процессы в цифру: строим веб- и мобильные приложения, автоматизируем рутину, внедряем ИИ туда, где он действительно нужен.

За это время реализовали более 20 проектов — от MVP для стартапов до сложных SaaS-платформ и enterprise-решений. Среди клиентов — гостиничный бизнес, e-commerce, логистика, образование. Каждый проект для нас — это не просто код, а продукт, который должен работать на результат.

Мы ходим на мероприятия вроде «Стартап-утра» не ради нетворкинга, а потому что верим: настоящие истории предпринимателей полезнее любых учебников. Записываем, осмысляем и делимся — чтобы опыт одних помогал расти другим.

Нужна разработка?

Расскажите о задаче — оценим сроки и бюджет за один звонок. Без обязательств.

Обсудить проект