В прошлом году ко мне пришел основатель B2B-сервиса и хотел сразу собрать «нормальную» команду: бэкенд, фронтенд, mobile, QA, PM. На бумаге все выглядело солидно, но найм первого сильного in-house разработчика у него уже шел 7 недель. Мы сели, разложили задачу, и быстро стало видно: стартап - это не маленькая версия большой компании, а проект с высокой неопределенностью.
На ранней стадии главный дефицит — не код, а ясность. Поэтому вопрос я бы ставил так: кто нужен в ближайшие 30-60 дней, чтобы проверить гипотезу, а не строить отдел заранее. Короче, сначала цикл проверки, потом штат.
Вы собираете не отдел, а короткий цикл проверки
Самая частая ошибка - нанимать людей под будущий масштаб, которого еще нет. Для идеи или раннего пилота это просто лишний расход бюджета. На практике выигрывает команда, которая быстро проходит короткий цикл: придумали, собрали, показали, выкинули лишнее, переделали.
У нас был B2B SaaS для небольших отделов продаж. Основатель закладывал команду из 5 человек и бюджет около 1,8 млн ₽ на первый этап. После декомпозиции оставили UX/UI-дизайнера, одного full-stack на Laravel 11 + PostgreSQL 16 и меня как part-time CTO на 10 часов в неделю. Входной бюджет стал 720 тыс. ₽, а первый рабочий сценарий показали через 9 недель.
Ранняя команда должна оптимизировать количество проверенных предположений, а не количество ролей в чате.
Видел и обратный сценарий. Основатель маркетплейса настоял на двух узких разработчиках вместо одного сильного full-stack. На синхронизацию ушло почти 3 недели, и спорили они в основном про слои архитектуры, которые бизнесу на том этапе вообще не были нужны.
Прототип, MVP и первый рабочий релиз стоят по-разному
Здесь многие теряют деньги просто на терминах. Прототип нужен, чтобы проверить логику и реакцию пользователя. MVP - чтобы человек сделал ключевое действие, а вы получили цифры: заявку, оплату, повторный вход. Первый рабочий релиз - это уже история про надежность, поддержку и более аккуратную архитектуру.
Для логистического сервиса мы вообще не писали бэкенд на первом шаге. Сделали Figma, лендинг на Webflow, связку с Airtable и уведомления. Первые платные лиды пришли через 9 дней, а код на Node.js 20 + NestJS появился позже. И это был правильный ход: рынок сначала подтвердил спрос, потом мы начали автоматизацию.
Кликабельный прототип: Figma / Framer — 1-2 недели
No-code MVP: Bubble / Webflow + Airtable — 2-4 недели
Code MVP: Next.js 15 + Node.js 20 + Supabase — 8-12 недель
Если ваш вопрос звучит как «люди вообще оставят заявку?», код может быть лишним. Я бы сначала проверил спрос дешевым способом, а уже потом открывал список задач на разработку.
На старте обычно хватает 3-4 ролей
В большинстве проектов первая команда укладывается в 3-4 роли. Этого хватает, чтобы собрать первую версию за 8-12 недель, если держать фокус на 1-2 сценариях.
Обычно нужны:
- основатель или product owner, который принимает решения каждый день;
- UX/UI-дизайнер, чтобы быстро собирать и менять сценарии;
- один сильный full-stack разработчик;
- part-time CTO или tech lead, если домен сложный или много интеграций.
Обычно не нужны сразу:
- отдельный QA на полный слот;
- мобильная команда, если гипотезу можно проверить через web;
- project manager «для порядка» в команде из 2-4 человек;
- DevOps, если деплой идет в Docker на одном сервере или в managed-сервисах.
Мы сами когда-то подключили отдельного QA и DevOps уже в первый месяц на маленьком продукте. Это была ошибка: трафика почти не было, релизы шли редко, а созвонов стало больше. Скорость не выросла вообще.
Где искать разработчиков и как считать риск
Когда спрашивают, где искать разработчиков для стартапа в 2026, почти все смотрят на ставку. Я бы считал по-другому: сколько времени уйдет на старт, сколько управления ляжет на основателя и как быстро можно заменить человека, если что-то пошло не так.
| Формат | Старт | Нагрузка на вас | Риск срыва | Когда подходит |
|---|---|---|---|---|
| Фриланс | 1-3 дня | высокая | высокий | точечный прототип |
| Студия | 1-2 недели | средняя | средний | прототип, MVP |
| In-house | 6-10 недель | высокая | средний | когда уже есть процесс |
| Аутстаф | 1-3 недели | очень высокая | средний | если внутри есть CTO |
Фриланс хорош скоростью входа, но нужен резервный план на код и контекст. In-house дает контроль, но для ранней стадии это часто самый медленный путь. Слаженная внешняя команда удобна там, где надо быстро собрать, проверить и не тратить месяц на найм.
Проверяйте людей короткой работой, а не длинным интервью
Обычное собеседование плохо показывает, как человек ведет себя в неопределенности. Тестовое на 10 часов часто отпугивает сильных специалистов. Мы обычно смотрим людей через оплачиваемый пробный спринт на 5-7 дней.
За такую неделю видно главное. Человек спрашивает про метрику успеха или сразу идет писать код, умеет ли упростить первый релиз, может ли назвать, что точно не нужно делать сейчас, дает ли оценку с допущениями или обещает «все сделаем».
Вот простой чеклист, который я бы держал перед любым наймом:
- есть ли один сценарий, который надо проверить первым;
- кто в команде принимает решение без созвона на полдня;
- что можно собрать без кода или с минимальным кодом;
- кто подхватит проект, если исполнитель пропадет;
- какой сигнал вы хотите получить через 2-4 недели.
Я сам не раз ошибался в одну сторону - брал людей раньше, чем продукт этого заслуживал. Почти всегда дешевле нанять на месяц позже, чем полгода содержать команду, которая строит аккуратную вещь без подтвержденного спроса. Самый дорогой разработчик в стартапе - тот, кого вы наняли до первого ясного вопроса к рынку.
