Гайд для нетехнического фаундера: как нанять партнёра по разработке (2026)

Зачем Фора Софт написала этот плейбук

С 2005 года Фора Софт реализовала более 625 проектов для 400+ клиентов. Мы провели многих нетехнических фаундеров от формулировки «вот моя идея» до питч-дека Series A: BrainCert вырос с MVP до 750 млн ₽ годовой выручки; TransLinguist прошёл путь от концепции до контракта с NHS Великобритании; Sprii привлёк 727 млн ₽ в раунде Series A; StreamLayer поднял 1 млрд ₽ и обслуживает NBC, CBS, Red Bull, Chelsea FC.

Мы также видели более 100 фаундеров, которые потеряли первые шесть месяцев и 30–60 % посевного бюджета на неподходящем партнёре. Закономерности предсказуемы. Этот гайд — тот самый плейбук, которого нам хотелось бы для каждого фаундера до подписания первого контракта на разработку.

Если вы нетехнический фаундер, эксперт в предметной области (врач, преподаватель, продюсер вещания) с идеей и без технического сооснователя или BizDev-руководитель в крупной компании, запускающей инновационные проекты, — этот гайд подскажет, какой архетип партнёра подходит вашей стадии, как написать ТЗ, на что смотреть в коммерческих предложениях и где обычно ломаются такие сотрудничества.

Четыре ошибки фаундеров

1. Выбор по самой низкой цене. Самое дешёвое предложение почти всегда упускает нефункциональные требования (NFR), пропускает discovery или прячет скрытые расходы в change-orders. Подрядчик, который на 50 % ниже медианы, либо съедает свою маржу (и компенсирует её через change-orders), либо срезает углы (и сделает не то). Самое дешёвое предложение при том же объёме работ — нормально; самое дешёвое предложение, в котором «согласились на всё», — нет.

2. Пропуск discovery. Подрядчики, которые готовы начать кодить уже на следующей неделе и пропускают этап архитектурного проектирования, потратят 30–60 % бюджета на переделку архитектуры в середине разработки. В 2025 году мы провели аудит четырёх таких проектов — всем четырём требовалась серьёзная доработка, которой удалось бы избежать с помощью discovery за 750 тыс. ₽ на старте.

3. Размытое ТЗ. «Сделайте нам Uber для X» — это не ТЗ. В нём 50 скрытых решений, и подрядчик с самой низкой ценой решит каждое самым дешёвым способом, а не правильным. Потратьте 1–2 недели на доводку ТЗ перед тем, как рассылать его на оценку.

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

Пять архетипов партнёров

Фрилансер. Один разработчик через Toptal, Upwork или сетевую рекомендацию. Дёшево и гибко, но без менеджера проекта, без QA, без ревью архитектуры. Подходит для прототипов и 1–3 новых фич в существующих системах. Не подходит для продакшен-продуктов с нуля.

Бутиковая студия. Команды по 5–25 человек, часто с упором на конкретную вертикаль. Подходит для MVP и продуктов уровня Series A. Сильные стороны: senior-команда, выделенный менеджер проекта, отлаженные процессы качества. Слабые стороны: ограниченная мощность для параллельных проектов, может не хватать опыта в нестандартных предметных областях.

Средняя компания (где находится Фора Софт). Команды по 50–200 человек, специализация по вертикали или технологиям. Подходит для масштабируемых платформ со сложной доменной логикой (видео, AI, реальное время, телемедицина). Сильные стороны: подтверждённые поставки, опыт в нескольких предметных областях, способность вывести 20+ инженеров на один проект. Слабые стороны: дороже бутиковой студии, менее гибкая, чем одиночный фрилансер.

Корпоративный интегратор (Accenture, EPAM, Capgemini). Контракты от 375 млн ₽, многолетние сроки, обычно крупные трансформации. Сильные стороны: процессы управления, масштаб, бренд. Слабые стороны: дорого, медленно, в команде часто джуниор-консультанты под надзором партнёров. Не подходит для стартап-стадии.

«Соберите команду» / staff augmentation. Toptal, AWS Staff Augmentation, отдельные подрядчики через ваш собственный найм. Подходит для постоянной мощности, когда продукт уже выпущен и у вас есть инженерный руководитель, который ставит задачи. Не подходит для запроса «постройте мне продукт» с нуля.

Как написать ТЗ, по которому дают точные оценки

ТЗ из 12 разделов сжимает разброс оценок по подрядчикам с 5× до менее 1,5×. Сами разделы (мы используем их в нашем discovery-шаблоне; подробнее о них — в нашем гайде CTO по оценке проекта):

Шаблон RFP — 12 разделов

1. О компании. Кто вы, чем занимаетесь, размер команды, стадия инвестиций.

2. Проблема и пользователи. Какую боль вы решаете, кто пользователи, что они делают сейчас, почему это важно.

3. Функциональный объём. User stories или эпики с критериями приёмки. Не функции — результаты. «Пациент может записаться к свободному врачу», а не «постройте календарь».

4. Нефункциональные требования (NFR). Производительность (целевая задержка, пропускная способность), безопасность (аутентификация, шифрование, комплаенс), масштаб (DAU, пиковые одновременные подключения), доступность (целевой SLA), доступность интерфейса (уровень WCAG), платформы (веб, iOS, Android, CTV).

5. Технологические предпочтения. Или явное «подрядчик предлагает». «Node + React + Postgres» — нормально, если у вас есть мнение; «предложите оптимальный стек» — тоже нормально. Будьте честны об ограничениях (существующая инфраструктура, кадровый рынок).

6. Сроки и контрольные точки. Жёсткие даты (запуск мероприятия, продление контракта, точка раунда инвестиций) и желательные. Подрядчики строят план совершенно иначе, если запуск жёсткий.

7. Бюджетные рамки. Диапазон, фикс, time&materials. Открыто сообщайте ограничения. Подрядчики, угадывающие ваш бюджет, теряют и ваше, и своё время.

8. Критерии оценки. Какие факторы влияют на ваше решение (цена, релевантность портфолио, технологическая глубина, коммуникация, локация). Сообщите подрядчикам, как вы будете их оценивать.

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

10. Требования к подаче. Формат, дедлайн, кто рассматривает, сроки решения. Согласуйте ожидания с обеих сторон.

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

12. Ожидания по референсам и портфолио. Какие прошлые работы вы хотите увидеть. «Покажите 3 видеопродукта, которые вы выпустили и которые масштабировались выше 100 тыс. DAU.»

Как оценивать предложения — 7 сигналов

1. Оспаривали ли они ваш объём работ? Хороший знак. Senior-команда подсвечивает неоднозначности, спрашивает «почему именно эта функция, как выглядит успех?», предлагает альтернативы. Подрядчик, ответивший «да, сделаем ровно как написано», либо не понял написанного, либо ему всё равно.

2. Спрашивали ли они про NFR? Сильные инженерные команды думают о масштабе, безопасности, производительности, комплаенсе. Если в предложении этого нет — всё это станет «вне объёма» на четвёртом месяце, когда уже больно.

3. Показали ли портфолио в ВАШЕЙ вертикали? Универсальные SaaS-портфолио не переносятся на видео, телемедицину, финтех, гейминг. Просите 3 конкретных кейса в вашей предметной области. Если их нет — учиться будут на вашем проекте.

4. Прозрачность ценообразования. Фикс или time&materials? Что входит (менеджер проекта, QA, ревью кода, девопс)? Что вызывает change-order? «15 млн ₽ за проект» без раскладки — красный флаг.

5. Состав команды. Кто на самом деле будет работать? Senior-архитекторы на встрече по продаже, а на проекте мид-инженеры — классическая подмена. Настаивайте на поимённом списке и закрепите его в контракте.

6. Ритм коммуникации. Ежедневные стендапы? Еженедельные демо? Ежемесячный наблюдательный комитет? Подрядчики, не предложившие ритм, на 2 недели уходят в радиомолчание, и вы узнаёте об отставании только на следующем демо.

7. Референсы клиентов на схожей стадии. «Поговорите с нашим клиентом из Fortune 500 на 37,5 млрд ₽» бесполезен, когда вы стартап с 75 млн ₽ годовой выручки. Просите референсы на вашей стадии и в вашей вертикали. Реальные подрядчики с радостью соединят вас с 2–3 фаундерами или вице-президентами, для которых поставляли проект.

Первые 30 дней — этап discovery

Как выглядит хороший discovery. 2–4 недели. В работу вовлечены senior-архитектор, ведущий дизайнер, менеджер проекта. Результаты: диаграмма архитектуры системы, прототип (кликабельный Figma или код), спринт-план с контрольными точками, реестр рисков, уточнённая оценка стоимости. Стоит 375 тыс.–1,1 млн ₽ для проекта на 15 млн ₽; экономит 3,7–11 млн ₽ в середине проекта.

Чем discovery НЕ является. Прочитать ваше ТЗ и сказать «звучит хорошо, поехали». Discovery без архитектурной работы, прототипирования и спринт-плана — это не discovery, а презентация продаж.

Почему это экономит деньги. Переделка архитектуры в середине проекта стоит в 3–5 раз дороже исходной работы, потому что часть кода придётся выбросить. Discovery поднимает архитектурные решения, когда их цена — одна встреча, а не один спринт. Подрядчик, который вкладывается в discovery, выходит ближе к исходной оценке.

Как его оформить. Discovery — отдельный контракт: 375 тыс.–1,1 млн ₽, 2–4 недели, артефакты определены заранее. После discovery вы вправе уйти. Подрядчик берёт на себя риск discovery; вы соглашаетесь на стройку только увидев архитектуру.

Что обязательно должно быть в контракте

1. Передача интеллектуальной собственности. Весь код, дизайн и данные, созданные в ходе работы, переходят к вам по факту оплаты. Подрядчик сохраняет права только на действительно общие шаренные фреймворки (которые перечисляет заранее).

2. Гарантийный период. 30–90 дней после поставки подрядчик чинит баги в своей работе бесплатно. Без этого пункта каждый постзапусковый баг становится новой счёт-фактурой.

3. Эскроу исходного кода. Критично для аудитов HIPAA/SOC 2 и due diligence при сделке M&A. Код хранится в стороннем эскроу-сервисе; вы можете забрать его, если подрядчик обанкротится или откажется передавать.

4. Аддендум GDPR / DPA. Если ваша платформа обрабатывает любые данные пользователей из ЕС, подрядчик обязан подписать соглашение об обработке данных (DPA). Это не обсуждается с точки зрения соответствия требованиям ЕС.

5. Условия расторжения. Обе стороны могут прекратить сотрудничество. Стандарт: уведомление за 30 дней, оплата работы в работе, обязанность по передаче знаний, передача исходного кода. Никаких «вечных» условий привязки.

6. Процедура change-order. Письменная, структурированная. Новые элементы объёма оцениваются отдельно и подписываются обеими сторонами до начала работ. Без этого подрядчик будет «съедать» ваши изменения бесплатно, пока сможет, а потом удивит шестизначным change-request.

Как управлять партнёром по разработке

Ритм спринтов. Двухнедельные спринты с планированием в начале, демо в конце, ретро после демо. Не пропускайте ничего. Именно ретро ловит процессные проблемы до того, как они сломают сотрудничество.

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

Slack/асинхронная переписка против синхронных встреч. Slack каждый день — нормально; синхронный созвон раз в неделю — обязательно. Не топите инженерную команду в реальном времени — берегите её время на фокус.

Паттерны красных флагов. Два демо на моковых данных, спринт закрывает 50 % запланированных историй, подрядчик предлагает «срезать объём, чтобы успеть», ведущий разработчик меняется без уведомления. Каждый сигнал по отдельности — жёлтый флаг; два вместе — повод эскалировать к руководству подрядчика.

Не микроменеджите. Вы наняли senior-команду, чтобы она принимала инженерные решения. Доверяйте техлиду в архитектуре; вмешивайтесь в результаты («делает ли эта функция X?»), а не в реализацию («почему вы используете Postgres вместо MongoDB?»).

Когда уволить партнёра

Правило трёх страйков. Первый страйк: спринт не закрывает 30 % запланированных задач. Второй: то же самое в следующем спринте плюс задержанное демо. Третий: то же самое плюс смена ведущего разработчика без предупреждения. После трёх — эскалация к руководству подрядчика с формальным дедлайном «исправить или расторгнуть» (обычно 14 дней).

Как чисто расстаться. Используйте 30-дневное уведомление по контракту. Оплатите работу в работе. Требуйте передачи исходного кода, документации и сессий по передаче знаний. Не тяните отношения — раз доверие ушло, следующий спринт его не вернёт.

Сроки замены. Найдите следующего подрядчика до расторжения. Передача в середине проекта болезненна; отсутствие подрядчика — ещё хуже. На отбор уйдёт 4–6 недель параллельно с формальным периодом «cure or terminate».

Когда Фора Софт — НЕ ваш вариант

Честность важнее продажи. Мы — неподходящий выбор в этих сценариях:

1. Тактическая работа до 2,2 млн ₽. Недельная доработка одной фичи или двухнедельный прототип — не наша зона. Используйте Toptal, Upwork или senior-подрядчика. У нас есть рекомендации — спросите.

2. Универсальный e-commerce или маркетплейс без специфики. Если ваш продукт — «как Shopify» или «как Airbnb» без видео/AI/реального времени/видеонаблюдения, десятки бутиковых студий построят это дешевле нас. Мы хороши там, где сложность важна.

3. Многолетняя трансформация Fortune 500. Accenture, EPAM, Cognizant заточены под такой масштаб. Мы можем вести проект на 25 инженеров; не справимся с 250 инженерами на 8 потоках работ в течение 5 лет.

4. Чистый офшоринг без участия senior-архитектуры. Если вам нужны «руки в час» под спецификацию, написанную вашим внутренним архитектором, услуги staff augmentation (Toptal, AWS Staff Aug) обойдутся дешевле. Мы добавляем ценность там, где важна senior-архитектура.

5. Гипер-итеративная работа до product-market fit. Если объём меняется еженедельно, потому что пользовательский ресёрч пересобирает продукт, формат time&materials с небольшой студией подойдёт лучше. Наш процесс рассчитан на большую стабильность объёма, чем выдерживают недельные пивоты.

Если, читая это, вы видите, что мы вам явно не подходим, скажите об этом на созвоне — порекомендуем подходящих партнёров, которым доверяем.

Мини-кейсы — от идеи до полученных инвестиций

BrainCert — от MVP до 750 млн ₽ годовой выручки под управлением фаундера. Соло-фаундер с педагогическим бэкграундом и без технического сооснователя пришёл к нам в 2017 году с идеей интегрированной e-learning-платформы. Мы провели 4-недельный discovery, описали 6-месячный MVP. К Series A платформа обслуживала 50 тыс.+ учеников; в 2024 году она перешагнула 750 млн ₽ годовой выручки.

TransLinguist — от концепции до контракта с NHS Великобритании. Фаундер с экспертизой в медицинском устном переводе, но без программного бэкграунда. Мы спроектировали платформу устного перевода с поддержкой требований HIPAA, в реальном времени, на базе WebRTC с маршрутизацией к живым переводчикам. 7 месяцев до версии 1. Сейчас контрактует с NHS Великобритании и несколькими госпитальными системами США.

Sprii — от pre-seed-фаундера до раунда Series A на 727 млн ₽. Фаундер презентовал концепцию live-shopping в 2020 году. За 5 месяцев мы построили MVP с iOS-приоритетом, включая видео-коммерческий оверлей, спонсорский брендинг и чат в реальном времени. Sprii затем поднял 727 млн ₽ в Series A и расширился на несколько рынков.

StreamLayer — от идеи до 1 млрд ₽ инвестиций. Фаундеры с опытом в спортивных трансляциях обратились к нам с концепцией интерактивного спортивного видеостриминга. Мы построили исходную платформу; компания привлекла 1 млрд ₽ за 7 раундов и обслуживает NBC, CBS, Red Bull, Live Nation, Chelsea FC. Поддержала Lollapalooza и фестиваль Made In America. Смотрите кейс.

Каждый проект начинался с нетехнического или экспертного фаундера, чёткого ТЗ, discovery-этапа и senior-архитектурной команды. Эта схема воспроизводима.

Фреймворк решения — выбор архетипа за пять вопросов

В1. Размер проекта? До 2,2 млн ₽: фрилансер. 2,2–37 млн ₽: бутиковая студия. 15–225 млн ₽ при сложной предметной области: средняя компания. От 375 млн ₽: корпоративный интегратор.

В2. Сложность предметной области? Универсальный SaaS: подойдёт любой уровень. Видео / AI / реальное время / видеонаблюдение / телемедицина / финтех: предпочтительна средняя компания с опытом в вертикали.

В3. Time-to-market? До 8 недель: managed-SDK, фрилансер или бутиковая студия. 6-месячный MVP: бутиковая студия или средняя компания. Многолетняя трансформация: корпоративный интегратор.

В4. Соответствие требованиям? HIPAA, SOC 2, FedRAMP: подрядчик с подтверждёнными комплаенс-поставками (средняя компания или специализированная бутиковая). Общий уровень обработки данных: подойдёт любой уровень.

В5. Внутренняя инженерная мощность? Ноль внутренних инженеров: фуллстек-подрядчик (бутиковая студия или средняя компания). Команда есть, но нет доменной экспертизы: подрядчик с вертикальной экспертизой. Команда и доменная экспертиза есть: staff augmentation.

Чего избегать

1. Соглашаться на самое дешёвое предложение, не сравнив объёмы работ. Дешёвые ставки выигрывают сделку и проигрывают проект. Всегда сравнивайте предложения по одному и тому же объёму.

2. Пропустить discovery, чтобы сэкономить 750 тыс. ₽. 750 тыс. ₽, сэкономленные на discovery, оборачиваются 3,7 млн ₽+ переделкой архитектуры в середине проекта. Всегда оформляйте discovery как отдельный платный контракт.

3. Позволять подрядчику самому набирать команду в середине проекта. Закрепляйте поимённый список в контракте. Подмена senior-архитекторов на этапе продажи на мид-инженеров на этапе поставки — самый частый сценарий провала.

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

5. Скрывать бюджетные ограничения. Подрядчики, угадывающие ваш бюджет, либо заваливают цену (и вы уходите), либо занижают её (и потом съедают резервы и удивляют вас). Назовите диапазон — они будут планировать соответствующе.

KPI, которые нужно измерять

KPI качества. Стабильность скорости спринта (цель: в пределах 20 % от средней). Количество багов за спринт (цель: меньше 5 критических багов в проде). Доля принятых на первом демо историй (цель: 90 %+).

Бизнес-KPI. Проект укладывается в исходную оценку с разбросом до 15 %. Своевременная поставка к ключевым датам. Время от подписания контракта до первого пригодного демо (цель: 2–4 недели).

KPI надёжности. SLA на ответ в коммуникации (цель: до 4 рабочих часов на некритичные запросы, до 30 минут на критичные). Стабильность команды (цель: меньше одной смены ведущего разработчика за проект).

FAQ

Что почитать дальше

Готовы выбрать правильного партнёра?

Большинство фаундеров нанимает не тех, потому что выбирает по цене, пропускает discovery, пишет размытое ТЗ и забывает о условиях выхода. Лечится не везением, а процессом. Подберите архетип под стадию, напишите ТЗ из 12 разделов, проведите платный discovery, оцените предложения по 7 сигналам и закрепите в контракте поимённую команду, условия по интеллектуальной собственности и условия выхода.

Если мы подходим (средняя компания, сложная предметная область, 15–225 млн ₽, видео / AI / реальное время / телемедицина / видеонаблюдение) — скажем об этом. Если нет — скажем об этом на созвоне и порекомендуем партнёров получше. На шестимесячном проекте честность побеждает гладкость.