Как выбрать подрядчика на разработку и что проверить в договоре

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

Кто вам нужен: фрилансер, студия или своя команда

Сначала определитесь с форматом исполнителя — от этого зависят и бюджет, и риски. Универсального ответа нет, есть соответствие задаче.

• Фрилансер. Дешевле всего и быстро на старте. Подходит для небольшой изолированной задачи: один экран, простой бот, доработка. Минусы — нет подстраховки, если человек заболел или пропал, и почти никогда нет юридически чистого договора с передачей прав.
• Студия полного цикла. Команда из аналитика, дизайнера, разработчиков и тестировщика, работающая по договору. Дороже фрилансера, но берёт на себя весь процесс, отвечает за результат и не зависит от одного человека. Оптимальна для приложений, CRM, веб-сервисов.
• Своя продуктовая команда в штате. Имеет смысл, когда продукт — ядро бизнеса и развивается годами. Дорого в содержании и долго собирается; для разового проекта избыточно.

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

Как оценить подрядчика до договора

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

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

Низкая цена и обещание «быстро и дёшево» — почти всегда не экономия, а отложенная переплата: демпинг оборачивается переделками, скрытыми доплатами и сорванными сроками.

Процесс работы и коммуникация

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

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

Техническое задание — фундамент договора

Договор без детального ТЗ почти ничего не защищает. Именно техническое задание определяет, что считается выполненной работой, и без него невозможно ни принять результат, ни доказать, что сделано не то. Устные договорённости «на словах» в споре не работают.

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

Что обязательно проверить в договоре на разработку

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

1. 1Тип договора. Договор подряда, возмездного оказания услуг или авторского заказа по-разному определяют результат и переход прав. Неверный тип создаёт юридические дыры — уточните, что выбран адекватный задаче вариант с понятным материальным результатом.
2. 2Предмет. Чётко описанная работа со ссылкой на ТЗ-приложение, а не общая фраза «разработка сайта».
3. 3Сроки и этапы. Календарный план с датами и тем, что сдаётся на каждом этапе.
4. 4Приёмка. Порядок сдачи-приёмки: как подписывается акт, в какой срок вы даёте замечания и что считается мотивированным отказом от приёмки.
5. 5Ответственность. Неустойка или пеня за просрочку и понятный порядок её расчёта.
6. 6Передача и закрепление прав на код за заказчиком в полном объёме — обязательный пункт (подробнее ниже).

Письменная форма обязательна. Для объектов авторского права (а программный код — это объект авторского права) условия о правах фиксируются именно письменным договором, и полагаться на устные договорённости здесь нельзя — в споре они не работают.

Права на код и интеллектуальная собственность

Самый дорогой источник споров — отношение заказчика к правам на код «по умолчанию». Закон такие случаи регулирует напрямую: по ст. 1296 ГК РФ исключительное право на программу, созданную по договору, предметом которого было её создание (то есть по заказу), принадлежит заказчику, если договором не предусмотрено иное. Но это правило легко обойти формулировками в договоре, а для разработки, где код возникает попутно при выполнении других работ, действует другая логика (ст. 1297 ГК РФ) — там права по умолчанию могут остаться у исполнителя. Поэтому не полагайтесь на «по умолчанию»: пункт о передаче и закреплении исключительных прав за заказчиком в полном объёме должен быть прописан прямо, а не подразумеваться.

Момент перехода прав важно привязать к подписанию акта по созданному результату и полной оплате — и явно это зафиксировать. Отдельно стоит урегулировать стороннее: использование готового кода и open-source библиотек должно быть раскрыто, лицензии проверены, а права на коммерческое использование улажены. Иначе вы рискуете получить продукт, который юридически нельзя использовать так, как вам нужно.

Деньги и гарантии

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

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

Передача проекта и поддержка

Запуск — не финал. Заранее пропишите, что именно вы получаете на выходе, иначе рискуете остаться с работающим, но «чужим» продуктом.

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

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

Эти риски особенно ощутимы в проектах, которые живут и растут годами — например, в CRM-системах и мобильных приложениях, где без исходников и документации развитие просто останавливается.

Красные флаги: как не остаться с заброшенным проектом

Соберём сигналы, при которых стоит как минимум насторожиться, а лучше — поискать другого исполнителя.

• Готовность работать без письменного договора, «на доверии».
• Отказ передавать исключительные права на код или размытые формулировки про права.
• Требование 100% предоплаты или непрозрачная схема платежей.
• Нежелание составлять детальное ТЗ и фиксировать критерии приёмки.
• Портфолио не по вашей задаче и невозможность показать живые проекты.
• Цена заметно ниже рынка и обещания нереальных сроков.
• Отношение к акту приёмки как к формальности — без корректной приёмки и фиксации замечаний вы не сможете требовать доработок и взыскивать неустойку.

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

Коротко: алгоритм выбора

1. 1Определите формат: фрилансер для мелочи, студия по договору для проекта, штат для постоянного продукта.
2. 2Проверьте релевантное портфолио, живые кейсы и отзывы реальных клиентов.
3. 3Оцените процесс: есть ли аналитика, ТЗ, этапы, демо и ответственный менеджер.
4. 4Согласуйте детальное ТЗ как приложение к договору.
5. 5Проверьте в договоре предмет, сроки, приёмку, ответственность, оплату по этапам и закрепление прав на код за заказчиком.
6. 6Зафиксируйте гарантию, поддержку и передачу исходников с доступами до финального платежа.

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

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