Как выбрать разработчика: фрилансер, студия или команда

§ 01Три модели подрядчиков — когда какая работает

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

Модель 1. Фрилансер-сеньор

Один человек, прянаш договор, прянаш диалог. Нет аккаунт-менеджеров, тимлидов, прослоек. Вы разговариваете с тем, кто пишет код. Все решения принимаются за минуты, правки — в тот же день, срочные вопросы — в чатах.

Плюсы: скорость, стоимость в 1.5–3 раза ниже студии при сопоставимом качестве, полная прозрачность. Один человек помнит весь проект целиком — не нужно пересказывать контекст каждый раз. Хороший фрилансер с 5+ годами опыта делает работу, близкую к уровню тимлида в крупной студии, потому что вырос на реальных проектах, а не на внутреннем онбординге.

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

Когда работает: проекты длиной до 3–4 месяцев, бюджет до 3 миллионов, одна-две связанные задачи, нужен опытный специалист, а не команда начинающих.

Модель 2. Небольшая студия (3–15 человек)

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

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

Минусы: цена выше фрилансера в 1.5–2 раза за ту же работу — нужно оплачивать офис, менеджмент, HR. На практике 30–50% сумя уходит не на производство, а на содержание структуры. Общение часто идёт через аккаунт-менеджера, который не пишет код — и на каждом шаге вопрос клиента проходит через «сломанный телефон».

Когда работает: проекты с бюджетом от 2 миллионов, где важно иметь резерв, нужны несколько смежных специалистов, и клиент готов доплатить за структуру.

Модель 3. Крупное агентство или inhouse-команда

Большой ресурс, формальные процессы, многолетние клиенты. Тендеры, договоры на 50 страниц, отделы продаж, PM, QA, DevOps. Это модель для корпоративных заказчиков, у которых свои требования к контрагентам — ISO-сертификаты, юрлицо с оборотом, проверка СБ.

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

Минусы: цена в 3–5 раз выше фрилансера за ту же работу. На производстве часто стоят джуниоры и мидлы под присмотром сеньора, потому что сеньоров в крупной компании мало и их время расписано на ключевых клиентов. Ответы на вопросы клиента занимают дни — проходят через менеджера, тимлида, обратно к менеджеру.

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

Когда работает: корпоративные заказчики, продукты с многолетней поддержкой, проекты с бюджетом от 5 миллионов и строгими требованиями к подрядчику.

Как выбрать свою модель

Задайте себе три вопроса. Первый: какой бюджет вы готовы обсуждать? До 2 миллионов — фрилансер, 2–5 миллионов — фрилансер или небольшая студия, от 5 миллионов — студия или агентство. Второй: насколько критичен риск «один человек — одна точка отказа»? Для MVP и некритичных задач — низкий, берите фрилансера. Для прод-систем с жёстким SLA — высокий, ищите команду. Третий: сколько у вас свободного времени на управление проектом? Фрилансер быстрый, но требует ваших решений в реальном времени. Агентство медленное, но проект движется на автопилоте.

Подробнее диапазоны цен по типам сайтов — в статье сколько стоит сделать сайт в 2026 году.

§ 02Как проверять портфолио, если большинство кейсов под NDA

Распространённая жалоба заказчиков: «пришёл на сайт студии, там 5 обезличенных кейсов, реальных имён нет, кому верить?». На самом деле это нормально. В коммерческой разработке 70–90% проектов идут под NDA, особенно в финтехе, b2b и у стартапов. Публикуется только то, что клиент разрешил.

Правильный способ проверки — задавать вопросы, на которые сложно соврать, если опыта нет.

Просите разобрать проект устно. На созвоне выбираете один кейс из портфолио и просите рассказать детально: какая была задача, какие решения предлагались, что в итоге выбрали, какие были проблемы, как их решали, что вы бы сделали иначе сейчас. Если человек действительно делал этот проект — он говорит конкретно: «В 2023 у клиента была очередь на 400 тысяч событий в сутки, мы поставили Redis Streams, потом перешли на ClickHouse». Если он кейс присвоил — говорит общо: «там была большая нагрузка, мы её решили».

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

Просите показать код. Из-под NDA нельзя достать клиентские данные, но структуру кода обычно можно. Фрилансер может открыть любой свой старый проект без имени клиента, показать экран. По коду за 5 минут становится понятно, какой уровень у человека — как именованы файлы, как разбита логика, есть ли тесты, насколько читаемо. Хороший разработчик открывает код без стыда.

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

Смотрите на косвенные сигналы. Публичные выступления на конференциях, открытые репозитории, статьи, ответы в сообществе. Это не гарантия, но показывает, что человек часть профессии, а не живёт в вакууме. Отсутствие любой публичной активности при 5+ годах опыта — странно.

Отдельный совет по видам проектов. Если вам нужен сайт, спрашивайте, какие фреймворки использует и почему. Если мобильное приложение, — выбор между React Native и нативной разработкой должен быть обоснован задачей, а не модой. Если Telegram-бот, — спросите про хостинг, мониторинг и что делать, если бот упадёт ночью.

§ 03Договор: на что смотреть и что ненормально

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

Пройдусь по блокам, которые должны быть.

Предмет договора

Максимально конкретно: что разрабатывается, для какой платформы, на каком стеке. «Разработка сайта» — недостаточно. «Разработка корпоративного сайта на 12 страниц, включая блог и форму обратной связи, на Next.js 15, с админкой на Sanity» — нормально.

Объём работ

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

Срок и этапы

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

Стоимость и график оплат

Цена фиксированная. «От 500 до 900 тысяч, уточним в процессе» — это способ получить счёт на 900. Платежи разбиты по этапам: предоплата 20–30%, затем поэтапно за каждый спринт, финальная оплата после сдачи. 100% предоплата — ненормально, 100% постоплата — тоже ненормально, никто не будет работать 6 недель на доверии.

Права на код и передача

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

Проверьте: где будет жить репозиторий (ваш GitHub / GitLab с самого начала), на кого зарегистрированы хостинг и домен, кто имеет доступ к аналитике и админке. Всё — на ваше имя, не на имя подрядчика.

Ответственность и штрафы

За задержку по вине подрядчика — пени, обычно 0.1–0.5% от стоимости этапа за день. Не слишком мягко, не хищнически. Иначе у подрядчика нет мотивации укладываться в срок. Но и клиенту нужны адекватные штрафы за свою задержку — если он неделю не даёт обратную связь, сроки двигаются.

Поддержка после сдачи

Стандарт: 30 дней гарантийного исправления багов после подписания акта. Баг — это когда что-то не работает, как прописано в ТЗ. «Хочу теперь иначе» — это доработка, отдельно. Проговорите границу явно.

Расторжение

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

Что ненормально в договоре: штрафы только на клиента, а на подрядчика нет. Размытые формулировки «в разумный срок», «в соответствии с пожеланиями заказчика». Права на код остаются у подрядчика. «Оплата по факту» без аванса. NDA без срока и территории (обычно 3–5 лет, РФ).

§ 04Почему «быстро, дёшево и хорошо» — почти всегда ложь

Есть старая проектная максима: «быстро, дёшево, хорошо — выбирай два из трёх». Она работает не потому, что подрядчики — плохие, а потому что это закон сохранения ресурсов. Хорошее решение требует либо времени (медленно), либо специалистов (дорого), либо и того и другого.

Типичные ситуации, когда клиент получает не то, что ждал:

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

Быстро + хорошо. Команда 5 человек, работают в три смены, срочный запуск. Получается отлично, но стоит как три обычных проекта. Имеет смысл, когда есть дедлайн (запуск к конференции, сезону) и деньги есть.

Дёшево + хорошо. Один талантливый разработчик вкладывается на совесть, но делает в комфортном темпе — 3 месяца вместо 6 недель. Клиент получает качество, но ждёт.

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

Реалистичный взгляд на срок: хороший сайт под ключ делается 4–8 недель, MVP — 4–6 недель, мобильное приложение — от 6 недель. Если подрядчик обещает вдвое меньше без объяснения — спросите, что срежут, и как это скажется на результате через год.

§ 05Правильный брифинг: как с первого созвона понять компетенцию

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

Вопросы, которые полезно задать именно разработчику, а не менеджеру:

• Какой стек предлагаешь и почему именно такой? Если ответ «потому что мы на этом работаем» — это не ответ. Хороший ответ — «под вашу задачу подходит X, потому что..., альтернативой было бы Y, но тогда бы мы потеряли...»
• Что может пойти не так в этом проекте? Если ответ «ничего, мы всё предусмотрим» — опасно. Хороший разработчик знает, где его проекты обычно спотыкаются, и проговаривает это честно.
• Как ты будешь поддерживать проект после сдачи? Если внятного ответа нет — значит, не думал. Если ответ есть и он встроен в смету — хорошо.
• Что произойдёт, если на финальной неделе обнаружится критичный баг? Хороший ответ — есть план, например, откат на предыдущий релиз за 5 минут. Плохой — «такого не будет».
• Можешь показать, как это будет выглядеть в админке? Даже если админки ещё нет, хороший разработчик может набросать структуру или показать похожее у другого клиента.

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

Для разных типов проектов полезно готовить разные тематические вопросы заранее. Для Telegram-бота спрашивайте про хостинг, CI/CD и мониторинг. Для MVP стартапа — про методологию скоупинга. Для веб-приложения — про архитектуру и масштабирование.

§ 06Красные флаги на первом созвоне

За 7 лет соло-практики мы видел, как клиенты попадали на типовые сценарии «не тот подрядчик». В 90% случаев признаки были видны на первом же созвоне — просто клиент их не считал важными.

• «Мы делаем всё, от кода до видео». Когда одна небольшая команда обещает покрыть и разработку, и SMM, и контекст, и съёмку рекламного ролика, и брендинг — почти всегда это прикрытие для «берём любую задачу, разберёмся по ходу». Настораживать должно смешение совершенно разных отраслей: код, маркетинг, продакшн. Full-stack разработка — это другое: фронт, бэк, инфраструктура, технический SEO, боты, LLM-интеграции — всё остаётся в одной инженерной плоскости и нарабатывается на годах похожих проектов одной головой. Это цельная компетенция, а не универсализм. Важно не перепутать.
• Обещает срок на старте, до понимания задачи. «Сайт за неделю, не вопрос!» — не зная, сколько у вас экранов, какая CMS, есть ли дизайн, какие интеграции. Это обещание, которое не будет выполнено, и подрядчик это знает.
• Хвалится клиентами, не имея на них разрешения. Выкладывает логотипы компаний, с которыми «работал», в портфолио. При проверке оказывается, что он делал лендинг для ИП-подрядчика этой компании, а не для неё самой. Мелкая ложь — но показательная.
• Не задаёт уточняющих вопросов. Вы описываете задачу абстрактно, подрядчик говорит «всё понятно, сделаем». Здоровая реакция — задать 5–10 вопросов: для чего сайт, кто аудитория, есть ли аналитика, кто пишет тексты, какие интеграции обязательны.
• Паниковка про «ещё один клиент на этот проект». «Решайте быстрее, у нас другой заказ горит». Классическая манипуляция продажника. Хороший подрядчик загружен, но не подталкивает вас к решению искусственными срочностями.
• Противоречия между менеджером и разработчиком. Если на созвоне один обещает одно, а разработчик — другое, — у вас потом будут проблемы, потому что внутри компании нет согласования. Лучше до договора поймать эти расхождения.
• Неспособность объяснить решения. «Мы сделаем на WordPress, это стандарт». Стандарт для кого, почему именно для вашей задачи, какие альтернативы. Если развёрнутого ответа нет — решения принимаются по привычке, а не по задаче.
• Резкая реакция на вопросы про гарантию. «Вы что, нам не доверяете?». Вопросы про гарантию, права на код, поддержку — нормальная часть бизнес-разговора. Обиды здесь — знак, что человек не готов к прозрачным отношениям.
• Шаблонные предложения без привязки к вашей задаче. Если КП пришло через 20 минут и выглядит как скопированное из другой переписки с заменой вашего имени — это оно и есть.

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

Для конкретных типов проектов бывают и специфические флаги. Если выбираете подрядчика на SEO и ускорение и слышите «гарантируем топ-1 за месяц» — это заведомая ложь. Если на рефакторинг легаси — и слышите «давайте просто перепишем с нуля, это быстрее» — часто это не быстрее и не дешевле, как разобрано в отдельной статье. Если на LLM-интеграцию — и видите «давайте прикрутим ChatGPT» без анализа процесса — это игрушка, а не работа.

Частые вопросы

Самое частое, что спрашивают клиенты до того, как мы начинаю разбирать конкретную задачу.