Кто нужен в команду разработки приложения и сколько она стоит

Игорь, основатель Diaverse · 8 октября 2026 · 11 минут чтения

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

Кто есть кто в команде разработки?

Главное: каждая роль отвечает за свой риск. Если роли нет, риск никуда не девается: его берёт на себя кто-то другой — или вы.

Что значат фронтенд, бэкенд, UX/UI и деплой, коротко объяснено в «Словаре заказчика».

Почему кажется, что нужны все восемь человек?

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

В смете студии работа часто расписана по ролям: столько-то часов дизайнера, столько-то тестировщика, столько-то менеджера. Это способ посчитать цену, а не обязательный состав команды на полный рабочий день.

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

Мы разобрали больше 500 открытых историй, отзывов, вопросов и заявок о заказе разработки. Чаще всего до старта в них звучит вопрос, с чего начать и к какому специалисту вообще обращаться. Знать заранее, какой специалист нужен, не обязательно. Опишите задачу через пользователя и сценарий — кто пользуется продуктом, что делает, что получает, — и исполнитель скажет, какие роли нужны. Как уложить это в одну страницу — в статье «Как поставить задачу разработчику».

Кто нужен первому продукту?

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

1. Решать, что делаем, — это вы

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

До разработки полезно проверить, нужен ли продукт людям: это дешевле любой команды. Порядок проверки — в статье «Как проверить спрос на идею приложения».

2. Проектировать и писать — один-два сильных разработчика

Для первой версии обычно хватает одного-двух разработчиков полного цикла (fullstack): они делают и интерфейс, и сервер. Один из них должен отвечать за архитектуру и безопасность — где хранятся данные, кто имеет доступ, где лежат ключи от платных сервисов. В одной из историй, которые мы разбирали, до базы данных и ключей от сервисов мог добраться любой, у кого была нужная ссылка. Так бывает, когда за безопасность не отвечает никто конкретный.

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

3. Проверять каждую неделю — демо и приёмка

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

Сколько стоит своя команда?

Главное: восемь специалистов среднего уровня — около 1,4 млн ₽ в месяц на руки и около 2,1 млн ₽ с налогами и взносами. За год с налогами и взносами — примерно 25 млн ₽, и это только зарплаты.

В таблице — медианные зарплаты специалистов уровня middle по всей России за первое полугодие 2026 года, по данным Хабр Карьеры. Это суммы, которые человек получает на руки. Компания платит больше: сверху идут НДФЛ и страховые взносы.

Зарплаты — медианы Хабр Карьеры для уровня middle, 1-е полугодие 2026 года, вся Россия, на руки (отчёт, калькулятор зарплат; в калькуляторе по умолчанию открыт текущий срез, поэтому цифры там выше). «Для компании» — наш расчёт по ставкам НДФЛ (13–15%) и страховых взносов (30% в пределах базы) на 2026 год, без льгот для IT-компаний и без взносов на травматизм. В Москве зарплаты выше: медиана разработчиков всех уровней там 270 000 ₽ против 200 000 ₽ в регионах.

К зарплатам добавьте то, что в таблицу не попало:

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

Для сравнения: стартовый состав из двух fullstack-разработчиков среднего уровня — около 320 000 ₽ в месяц на руки и около 480 000 ₽ для компании. Работы они делают меньше, чем восемь человек, но и задач у первой версии с одним главным сценарием меньше. Как честно сравнить свою команду с внешней — в статье «Разработка стоит слишком дорого или подрядчик пропал».

Кейс Diaverse: на чём мы теряли деньги

Diaverse — наше собственное мобильное приложение: шагомер и игра с питомцами, в App Store с марта 2024 года. Полтора года назад у него была классическая команда: проджекты, менеджеры, поддержка, разработчики, дизайнеры. Только зарплаты команды обходились в $20 000–25 000 в месяц. Двигались медленно, а качество и результат нас не устраивали.

Когда мы разобрались, где деньги уходили впустую, список оказался коротким: лишние роли, долгие согласования, функции, которые никому не нужны, маркетинг до проверки спроса. Сегодня Diaverse разрабатывается меньше чем за $3 000 в месяц — это тот же объём разработки, и качественнее. Если сравнивать зарплаты команды тогда с расходами на разработку сейчас, выходит в 7–8 раз дешевле. Работу ведут сильные специалисты с современными инструментами, без огромных зарплатных фондов, отделов и слоёв менеджеров.

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

Когда добавлять остальные роли?

Главное: добавляйте роль, когда у неё появилась постоянная работа, а не потому, что «так принято».

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

Нужен ли CTO или технический партнёр за долю?

Главное: на старте нужен не титул, а человек, который отвечает за технические решения и умеет оценить работу остальных.

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

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

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

Частые ошибки

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

Чек-лист: вопросы о команде до старта

Читайте также

• Как выбрать подрядчика для разработки и не потерять предоплату — фрилансер, студия, свой штат или команда помесячно.
• Разработка стоит слишком дорого или подрядчик пропал: как сократить затраты и довести продукт — как честно сравнить свою команду и внешнюю.
• Сколько стоит разработка приложения и почему сметы отличаются в разы — из чего складывается цена проекта.
• Как проверить спрос на идею приложения до разработки — до найма кого-либо.
• Словарь заказчика: MVP, ТЗ, деплой и другие слова простым языком