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

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

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

Почему нельзя принимать работу по отчёту?

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

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

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

Есть и юридическая причина. Для договора подряда статья 720 ГК РФ говорит: если договором не предусмотрено иное, заказчик, принявший работу без проверки, теряет право ссылаться на недостатки, которые можно было заметить при обычной приёмке. А на недостатки, найденные при приёмке, можно ссылаться, если они записаны в акте или другом документе о приёмке. Проверьте и срок приёмки в своём договоре: в историях заказчиков встречается «автоматическая приёмка», когда молчание считается согласием. Это не юридическая консультация — договор лучше показать юристу.

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

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

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

• По ссылке, а не скриншотами. Для сайта — тестовая версия по адресу, который вы открываете сами. Для приложения — тестовая сборка на вашем телефоне: на iPhone через TestFlight, на Android через внутреннее тестирование Google Play.
• Вы нажимаете сами. Место, где вы застряли, — первая находка.
• Сверка с планом. Что обещали, что сделано, что нет и почему.
• Короткая запись после показа. Что готово, что дальше, какие вопросы к вам.
• Язык пользователя. «Клиент теперь может записаться и оплатить», а не «доработали бэкенд». Непонятное слово — повод спросить, что оно меняет для пользователя.

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

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

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

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

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

Главные сценарии на разных устройствах

Выпишите 3–7 сценариев, ради которых делали продукт: для сайта студии — «найти услугу, записаться, оплатить», для приложения — «установить, зарегистрироваться, сделать главное действие».

• Проходите как новый пользователь, а не под админским аккаунтом, где всё уже настроено.
• Возьмите iPhone и Android, не самый новый телефон кого-то из близких, компьютер в двух браузерах. Сузьте окно браузера до ширины телефона.
• Проверьте на мобильном интернете, а не только на офисном Wi-Fi.
• Дайте пройти сценарий человеку, который продукт не видел, и молча смотрите, где он застрянет.

Данные, формы и оплата

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

Скорость, тексты и ошибки

Откройте продукт через мобильный интернет: главный экран не должен долго оставаться белым. Для сайта есть бесплатный сервис Google PageSpeed Insights — он покажет, что тормозит. Попросите исполнителя объяснить красные пункты.

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

Как понять, что найденное — это проблема?

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

Как проверить безопасность, если вы не технарь?

Главное: взламывать ничего не нужно. Задайте исполнителю правильные вопросы и проверьте то, что видно владельцу.

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

• Админ-доступы. У каждого свой логин, без общего «admin» на всех. На хостинге, домене, репозитории, сторах и платёжном сервисе включена двухфакторная защита — в ваших аккаунтах.
• Пароли и ключи. Спросите, где хранятся ключи от платёжного сервиса, почты и других сервисов. Ответы «прямо в коде» и «в общем чате» — повод для замечания. Пароли передают через менеджер паролей, а не открытым текстом в мессенджере.
• Пароли пользователей. Если на «Забыли пароль?» вам прислали ваш старый пароль, а не ссылку для смены, система хранит пароли так, что их можно прочитать. Это серьёзная проблема.
• Резервные копии. Как часто копируются база и файлы, где лежат копии, когда их последний раз восстанавливали. Копия, которую ни разу не восстанавливали, — это надежда, а не копия.
• Данные пользователей. Кто и какие сервисы видят данные клиентов, нет ли копий базы на личных ноутбуках. Если продукт собирает персональные данные пользователей в России, на вас как на владельце лежат обязанности по закону о персональных данных (152-ФЗ). Это не юридическая консультация — обсудите это с юристом.

Какие доступы и документы забрать до финальной оплаты?

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

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

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

Когда звать независимого специалиста?

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

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

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

Что поручить проверяющему:

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

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

Что делать, если нашли проблемы?

Главное: соберите замечания в один письменный список с приоритетами и проводите повторную приёмку по нему. Замечания по одному в мессенджере теряются.

Каждое замечание описывайте так, чтобы его можно было повторить: где (экран или ссылка), какие шаги, что ожидали и что получилось, на каком устройстве, плюс скриншот или запись экрана. И приоритет: блокирует приёмку, можно после запуска или косметика.

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

Отдельно договоритесь о гарантийном периоде: сколько времени после сдачи исполнитель бесплатно исправляет ошибки в сделанном. Сразу разведите понятия. Ошибка — продукт работает не так, как записано в критериях. Новая функция — то, о чём не договаривались. Чем точнее критерии, тем меньше споров.

Как договориться о поддержке после сдачи?

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

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

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

Что делать, если вы уже приняли работу и заплатили?

1. Соберите доступы и сделайте копии кода и базы — по списку выше.
2. Пройдите приёмку задним числом по чек-листу ниже и запишите найденное в один список.
3. Проверьте договор: есть ли гарантийный период и как подавать претензии.
4. Если продукт важен для бизнеса, позовите независимого специалиста. Если исполнитель пропал или проект брошен на полпути, порядок действий — в статье про передачу проекта.

Частые ошибки при приёмке

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

Чек-лист приёмки

Отмечайте по ходу проекта, а не только в день сдачи.

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

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