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

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

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

Что такое стек технологий и из каких слоёв он состоит?

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

• Язык. PHP, JavaScript/TypeScript, Python, Go, Java, C#. От языка зависит, каких специалистов искать и какой хостинг подойдёт.
• Фреймворк. Готовый каркас поверх языка: Laravel для PHP, Django для Python, React или Vue для интерфейса. Он задаёт структуру проекта, и опытный разработчик быстро в ней ориентируется.
• База данных. Где хранятся заказы, пользователи, товары: PostgreSQL, MySQL, иногда MongoDB или Redis для отдельных задач.
• Сервер и окружение. На чём проект работает: виртуальный сервер, контейнеры, облачная платформа, обычный хостинг.
• Выкладка. Как новые версии попадают на сервер: вручную по FTP или автоматически из репозитория. Второй вариант предсказуемее и оставляет историю изменений.

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

Почему заказчику вообще стоит думать о стеке?

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

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

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

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

Какие варианты стека встречаются чаще всего?

Для сайтов и сервисов малого и среднего бизнеса чаще всего предлагают PHP с Laravel, JavaScript/TypeScript с React или Vue и Node.js, Python с Django или FastAPI. Java, C# и Go встречаются в корпоративных и нагруженных системах. Все эти варианты рабочие — вопрос в соответствии задаче.

Отдельно стоят готовые CMS вроде 1С-Битрикс или WordPress: это не «язык», а готовая система со своими правилами. Сравнение CMS и разработки без неё — в статье «1С-Битрикс, WordPress или своя разработка», здесь повторять не будем.

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

Стек	Где уместен	Кто сможет поддерживать	На что смотреть
PHP + Laravel + MySQL или PostgreSQL	Сайты компаний, каталоги, кабинеты средней сложности	Широкий круг разработчиков, хостинг есть почти у любого провайдера	Версия PHP: старые ветки быстро выходят из поддержки
JavaScript/TypeScript: React или Vue + Node.js	Сервисы с богатым интерфейсом, кабинеты, SaaS	Много специалистов, один язык на фронтенде и бэкенде	Много зависимостей — их нужно регулярно обновлять
Next.js или Nuxt (фронтенд и сервер в одном)	Сайты, где важны скорость и поисковая индексация, плюс кабинет	Фронтенд-разработчики с опытом серверной части	Нужен хостинг с Node.js, обычный «PHP-хостинг» не подойдёт
Python + Django или FastAPI + PostgreSQL	Сервисы с обработкой данных, интеграции, внутренние системы	Python-разработчики с опытом веб-фреймворков; много готовых библиотек для работы с данными	Запуск на сервере сложнее, чем у PHP, нужен администратор или контейнеры
Java/Kotlin + Spring или C# + .NET	Крупные корпоративные системы, требования службы безопасности	Команды с опытом корпоративных систем	Для небольшого сайта избыточно: дольше и дороже без пользы
Go	Отдельные быстрые сервисы и API под нагрузкой	Команда с опытом именно Go — уточните заранее, кто возьмёт проект на поддержку	Как основа всего проекта для малого бизнеса — редко оправдан

Как стек влияет на смену подрядчика?

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

На смену подрядчика влияют не только сами технологии, но и то, как они оформлены:

• Исходный код в вашем репозитории, а не на ноутбуке разработчика. Что такое репозиторий и что в нём проверить без программиста — в статье «Репозиторий кода простыми словами».
• Инструкция по запуску: как поднять проект с нуля, какие нужны версии и настройки. Без неё даже стандартный стек превращается в квест.
• Список внешних сервисов: платёжный шлюз, почта, хранилище файлов, карты — с указанием, на чьём аккаунте они оформлены.
• Зависимости с открытым кодом или с понятной лицензией. Если проект держится на закрытом модуле, который нельзя передать, сменить команду не получится.

Что делать, если смена уже назрела, разобрано в статье о передаче проекта другому разработчику.

Технология	Срок поддержки версии	Что это значит для вас
PHP	4 года: 2 года активной поддержки и 2 года только исправлений безопасности	Раз в несколько лет сайт нужно переводить на новую ветку PHP
Python	5 лет с первого выпуска версии	Запас больше, но переход всё равно придётся планировать
Node.js	LTS-версии — около 30 месяцев; с версии 27 выпуск раз в год	В бою держат только LTS-версии и переходят на следующую до окончания поддержки текущей

Что стек меняет в поддержке и хостинге?

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

Сроки в таблице взяты с официальных страниц: поддерживаемые версии PHP, версии Python, выпуски Node.js. Например, по данным php.net, ветка PHP 8.2 получает исправления безопасности до 31 декабря 2026 года — проекты на ней пора переводить на более новую.

С хостингом логика такая:

• PHP-проекты запускаются почти на любом хостинге, включая недорогой общий.
• Node.js, Python, Go обычно требуют виртуального сервера или контейнерной платформы. Это не обязательно дороже, но нужен человек, который настроит и будет обновлять сервер.
• Java и .NET — требования к ресурсам сервера уточните у подрядчика заранее и заложите их в бюджет на размещение.

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

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

Настораживать должен не конкретный язык, а необъяснимый выбор: редкая технология без причины, «своя CMS» без исходников, отказ назвать версии или передать проект в ваш репозиторий. Каждый такой пункт стоит обсудить до договора.

1. Редкий фреймворк или язык без внятной причины. Если на вопрос «почему так» звучит «мы так привыкли», это аргумент подрядчика, а не ваш.
2. «Своя CMS» или «наш движок» без передачи исходного кода. Вы окажетесь привязаны к одной команде: никто другой не сможет его поддерживать.
3. Устаревшие версии на старте. Новый проект на версии языка, у которой заканчивается поддержка, — почти наверняка обновление уже в первый год.
4. Слишком сложный стек для простой задачи. Микросервисы, несколько баз данных и оркестрация контейнеров для сайта компании из восьми страниц — лишние расходы на поддержку.
5. Нет ответа, где и как будет работать проект. «Разберёмся потом» про сервер и выкладку обычно значит ручные правки на бою.
6. Конструктор или платформа без экспорта. Если проект живёт только внутри закрытой платформы, уйти с неё можно лишь переделкой.

Ни один пункт не означает, что подрядчик плохой. Но если объяснения нет, вы берёте на себя риск, о котором вам не сказали.

Что спросить о стеке до подписания договора?

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

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

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

Когда выбор стека не так важен?

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

Также не стоит переживать из-за выбора между двумя популярными вариантами — например, React или Vue, Laravel или Django. Разница между ними для бизнеса обычно меньше, чем разница в опыте конкретной команды. Пусть делают на том, что знают хорошо, если это распространённая технология с поддерживаемыми версиями.

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

Какие ошибки делают заказчики при выборе стека?

Самые частые ошибки — выбирать по моде или по совету знакомого, требовать «как у крупной компании» и не спрашивать о стеке вовсе. Все три ведут к одному: проект дороже в поддержке, чем мог бы быть.

• Выбор по моде. Технология на слуху не значит, что под неё легко найти команду в вашем бюджете.
• «Как у банка». Стек крупной компании решает её задачи: нагрузку, штат, требования безопасности. Сайту услуг он добавит стоимость, но не пользу.
• Смена стека ради смены. Переписать работающий проект на «более современное» стоит дорого и почти никогда не окупается само по себе. Обновить версии — обычно разумнее.
• Молчание о стеке. Не спросили на старте — узнали при первой смене подрядчика.
• Экономия на инструкции и репозитории. Самые дешёвые в моменте пункты, которые потом обходятся дороже всего.

Как мы выбираем стек и что передаём заказчику?

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

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

Ориентиры из прайса: корпоративный сайт — от 56 000 ₽, веб-приложение или SaaS — от 160 000 ₽, мобильное приложение — от 200 000 ₽; поддержка и развитие, включая обновления, — от 7 900 ₽ в месяц. Точную смету считаем после брифа, цену и срок фиксируем в договоре до старта. Подробнее о том, как устроена заказная работа, — на странице заказной разработки.

Короткие ответы на частые вопросы

Что такое стек технологий простыми словами?

Это набор инструментов, из которых собран сайт или сервис: язык программирования, фреймворк, база данных, сервер и способ выкладки. Стек определяет, кто сможет поддерживать проект и где его можно разместить.

Нужно ли заказчику самому выбирать стек?

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

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

Для типового сервиса подходят распространённые варианты: PHP, JavaScript/TypeScript, Python. Решают задача, опыт команды и требования к хостингу, а не мода. Редкий язык оправдан только конкретной технической причиной.

Как узнать, на чём написан уже готовый сайт?

Самый надёжный способ — спросить подрядчика и посмотреть репозиторий: по файлам вроде composer.json или package.json видно язык и зависимости. Браузерные расширения дают подсказку, но по ним не видно серверной части.

Плохо ли, если подрядчик использует свои готовые модули?

Нет, если модули передаются с исходным кодом и описанием и собраны на распространённых технологиях. Плохо, когда модуль — закрытый «чёрный ящик», без которого проект не запустится у другой команды.

Услуги и кейсы по теме: заказная разработка · типовые договоры · цены и сроки