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

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

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

Почему заказчики теряют предоплату?

Главное: деньги теряют не из-за одного неудачного выбора, а из-за схемы, где крупная сумма уходит вперёд за обещание, а у заказчика нет ни кода, ни способа рано увидеть проблему.

Готовя эту статью, мы разобрали больше 500 открытых историй, отзывов, вопросов и заявок о заказе разработки. Это не клиенты Diaverse, а открытый русскоязычный рынок. В плохих историях повторяется один и тот же набор:

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

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

Кого искать: фрилансера, студию, свой штат или команду помесячно?

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

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

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

Возможно, задачу закрывает готовый сервис или конструктор — спросите исполнителя прямо: «Что из этого можно сделать на готовом?» А если прототип вы уже собрали с ИИ, прочитайте, когда его хватает, а когда нужна разработка.

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

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

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

1. Работающие продукты вместо скриншотов

Среди условий в заявках из нашей выборки чаще всего встречается требование доказательств опыта: живые ссылки и понятная роль исполнителя в проекте. Это разумный фильтр.

• Попросите 2–3 ссылки на работающие продукты: сайт, приложение в App Store или Google Play, бота. Пройдите главный сценарий сами.
• Спросите, что именно делал исполнитель: весь продукт, интерфейс или одну интеграцию.
• Посмотрите, живой ли продукт: когда приложение обновлялось, проходит ли оплата, отвечает ли бот.
• Если получится, поговорите с заказчиком одного из проектов: уложились ли в срок и что делал исполнитель, когда что-то шло не по плану.

2. Разговор о вашей задаче, а не о технологиях

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

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

3. Маленький оплачиваемый первый этап

Сильнее всего проверяет совместная работа на небольшой сумме: этап на 1–2 недели с фиксированной ценой и результатом, который можно открыть. Это может быть прототип главного сценария, один рабочий экран на реальных данных или техническая карта проекта со сметой.

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

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

Какие признаки должны насторожить?

Главное: один признак — повод задать вопрос, два-три — повод не платить.

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

Как платить, чтобы не потерять всё сразу?

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

Я бы исходил из простого правила: не платить вперёд больше, чем вы готовы потерять, если исполнитель завтра пропадёт. Ставку увеличивайте по мере доверия.

1. Разговор о задачебез оплаты; на выходе — что нужно и вилка бюджета и сроков
2. Маленький первый этап1–2 недели, фиксированная цена, результат по ссылке
3. Первый рабочий этап2–4 недели, оплата после показа или частями внутри этапа
4. Следующие этапы или месяцыкаждый оплачивается, когда показан предыдущий
5. Долгая работакогда исполнитель несколько раз сдал в срок

• Этап заканчивается тем, что можно открыть: ссылка на тестовую версию, сборка приложения на вашем телефоне. Отчёт о проделанной работе — не результат этапа.
• Этап — 2–4 недели работы. Достаточно для заметной части продукта и не так много, чтобы потеря стала катастрофой.
• Деньги за следующий этап — после приёмки предыдущего. Аванс, если он нужен, — часть этапа, а не всего проекта.
• Помесячная оплата команды устроена так же: платите за месяц, видите результат каждую неделю и можете остановиться после любого месяца, если договор это позволяет.
• Безопасная сделка на площадке снижает риск, но не заменяет проверку. Прочитайте, когда деньги уходят исполнителю и как открыть спор. Потерянное время площадка не вернёт.

На что смотреть в договоре?

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

Договор нужен даже с одним исполнителем: в нашей выборке есть истории, где все договорённости жили только в мессенджере.

• Этапы. Для каждого — срок, сумма и результат простыми словами: «пользователь записывается на занятие и получает подтверждение», а не «реализован модуль бронирования». Это и есть критерии приёмки. Как проверять работу без технических знаний — в статье «Как принять работу у разработчика».
• Приёмка и «автоприёмка». Частый пункт: если заказчик за определённое число дней не подписал акт и не прислал мотивированные замечания, работа считается принятой. Сам по себе он обычен, но проверьте, хватит ли этого срока на реальную проверку и куда отправлять замечания.
• Ограничение ответственности. Ответственность исполнителя нередко ограничивают суммой этапа или договора. Посмотрите, что будет при срыве срока или уходе исполнителя: возврат за несделанное, неустойка, передача сделанного. Совет искать эти два пункта встречается и в разобранных историях.
• Права на код. В России по общему правилу исключительное право на программу, созданную по заказу, принадлежит заказчику, если договор не предусматривает иное (ГК РФ, ст. 1296). Проверьте, что «иное» не написано мелким шрифтом, и когда права переходят к вам — например, после оплаты каждого этапа. Если исполнитель привлекает других людей, права на их работу тоже должны перейти к вам.
• Изменения по ходу. Как оформляется новая задача: допсоглашением, заменой задачи в плане или доплатой.
• Расторжение. Что происходит с деньгами за несделанное и со сделанным, за сколько дней предупреждать, в какой срок передаются код, доступы и документация.
• Канал для договорённостей. Укажите, где фиксируются решения, и записывайте туда итоги созвонов. Устные договорённости — частая причина спора «это не входило».

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

Что должно быть оформлено на вас с первого дня?

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

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

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

Как в первые две недели заметить, что что-то идёт не так?

Главное: первые две недели — продолжение проверки. Договоритесь о ритме и смотрите на работающий результат, а не на отчёты о часах.

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

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

В первую неделю исполнитель получает доступы к вашим аккаунтам, а не вы — к его. В вашем репозитории появляются изменения: читать код не нужно, достаточно видеть по датам, что работа идёт. Есть план на 2–4 недели: что и когда будет показано.

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

Сигналы, что пора вмешаться

• Показ переносится, а вместо ссылки приходят скриншоты или отчёт о часах.
• В репозитории тишина больше недели.
• На вопросы отвечают через несколько дней.
• Работает не тот человек, о котором договаривались.
• Просят доплату за то, что входило в этап.

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

Что делать, если исполнитель уже пропал?

Главное: сначала доступы и копии, потом разговоры и решения.

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

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

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

Чек-лист перед оплатой

Чек-лист не убирает риск, но с ним вы знаете размер возможной потери и можете остановиться, не теряя проект.

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

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