Проект готов. Код работает. Тесты проходят. Агентство выдыхает — 22 рабочих дня позади, MVP собран, можно назначать финальную встречу с клиентом. А потом CTO клиента открывает репозиторий — и всё рушится. Не потому, что продукт плохой. Какие ошибки сдача white-label проекта вскрывает чаще всего? Те, что связаны не с качеством кода, а с подготовкой к передаче — и большинство агентств их игнорируют.
За десятки white-label проектов мы видели, как агентства теряют клиентов не из-за качества разработки, а из-за ошибок на этапе передачи. Одни и те же ошибки сдача white-label проекта обнажает раз за разом. Пять из них повторяются особенно часто — и каждая предотвратима. Давайте разберём их по порядку, чтобы ваша следующая сдача прошла безупречно.
Содержание
- Ошибка 1. Нет документации — или она под чужим брендом
- Ошибка 2. Передача продукта без управляемого демо
- Ошибка 3. Не определены критерии приёмки
- Ошибка 4. Следы субподрядчика в коде, git и метаданных
- Ошибка 5. Нет плана поддержки после сдачи
- Чек-лист сдачи white-label проекта
- FAQ о сдаче white-label проекта
Ошибка 1. Нет документации — или она под чужим брендом
Среди всех ошибки сдача white-label проекта выявляет эту чаще всего — и она самая обидная. Агентство вкладывает месяц работы в разработку, а на финальной встрече клиент получает ZIP-архив без единого сопроводительного документа. Или, что ещё хуже, в документации мелькает логотип подрядчика.
Что идёт не так
Корпоративный клиент не оценивает продукт глазами разработчика. Он оценивает профессионализм агентства. Документация — первое, на что смотрит CTO или технический директор при приёмке. Отсутствие документации сигнализирует: «Ваш подрядчик не контролирует процесс». А чужой бренд в файлах — прямое доказательство субподряда, которое разрушает доверие мгновенно.
Реальный пример
Агентство сдало клиенту MVP корпоративного портала. Код работал отлично, интерфейс выглядел безупречно. Однако в PDF-файле с API-документацией остался водяной знак другой студии. Клиент заметил это через три дня, когда передал документацию своей внутренней команде. Результат — неприятный разговор, потеря доверия и требование скидки на следующий проект. Маржинальность проекта упала с 40% до 15%.
Как предотвратить
При работе с надёжным white-label партнёром документация под брендом агентства входит в стандартный пакет. Тем не менее проверяйте каждый документ перед передачей клиенту. Вот минимальный набор:
- Техническая документация — архитектура, API-эндпоинты, структура базы данных (под вашим брендом)
- Руководство пользователя — пошаговые инструкции для конечных пользователей (с логотипом клиента)
- Руководство администратора — настройка, деплой, бэкапы (под вашим брендом)
- Release notes — что реализовано, известные ограничения, план развития
Критически важно: проведите полнотекстовый поиск по всем файлам на предмет упоминания подрядчика. Проверяйте не только текст, но и метаданные PDF, свойства файлов Word и комментарии в коде.
Ошибка 2. Передача продукта без управляемого демо
Следующие ошибки сдача white-label проекта выявляет не менее болезненно — например, отправить клиенту ссылку на тестовый сервер и ждать обратной связи. Это равносильно тому, чтобы вручить ключи от квартиры без экскурсии по дому.
Что идёт не так
Клиент открывает продукт в одиночку, натыкается на неочевидный интерфейсный элемент, не понимает логику навигации и делает вывод: «Это сырой продукт». При этом функциональность может быть полностью реализована — просто клиент не знает, как ей пользоваться. Первое впечатление формируется за 30 секунд, и исправить его потом практически невозможно.
Реальный пример
Digital-агентство передало клиенту CRM-систему по email: «Ссылка, логин, пароль — всё работает, смотрите». Клиент зашёл, нажал на кнопку «Экспорт отчётов» — а она вела на страницу настройки, потому что требовала предварительной конфигурации шаблонов. Клиент решил, что функция не работает, и написал гневное письмо. Разбирательство заняло неделю. Хотя 15-минутное демо сняло бы все вопросы.
Как предотвратить
Демонстрация — это не опция, а обязательный этап сдачи проекта. Причём проводить её должно агентство, а не подрядчик. Именно поэтому при white-label модели подрядчик готовит презентационные материалы для агентства, а агентство проводит демо самостоятельно.
Структура эффективного демо:
- Бизнес-результат (5 минут) — что реализовано и какие задачи клиента это решает
- Ключевые сценарии (15-20 минут) — пройтись по 3-5 основным пользовательским путям
- Технические детали (10 минут) — для CTO: архитектура, API, безопасность
- Вопросы и обратная связь (10-15 минут) — записать все замечания
Подготовьте сценарий демо заранее. Протестируйте его — именно в том окружении, где будет проходить встреча. Нет ничего хуже, чем «зависший» продукт во время демонстрации клиенту.
Ошибка 3. Не определены критерии приёмки
«Сделано» — понятие растяжимое. Для разработчика «сделано» означает: код написан, тесты проходят, деплой выполнен. Для клиента «сделано» может означать совершенно другое: «работает именно так, как я себе это представлял», причём представление может не совпадать с техническим заданием.
Что идёт не так
Без формализованных критериев приёмки клиент получает право говорить «это не то, что я заказывал» бесконечно. Каждая новая претензия — это дополнительные часы работы, которые не оплачиваются. Scope creep после сдачи убивает маржинальность быстрее, чем что-либо другое.
Ещё хуже — когда у клиента есть технический аудитор, а критерии приёмки не зафиксированы документально. Аудитор может предъявить собственные требования к качеству кода, покрытию тестами или производительности — требования, о которых не было речи на старте. Без документа, описывающего «что считается сданным», агентство оказывается в уязвимой позиции.
Реальный пример
Агентство сдало MVP маркетплейса: 47 из 47 функциональных требований из ТЗ реализованы. Клиент пригласил независимого аудитора, который указал на отсутствие нагрузочного тестирования. Формально оно не входило в скоуп — но нигде это не было зафиксировано. В результате агентство провело нагрузочное тестирование за свой счёт, потратив 80 000 рублей и две недели. Если бы критерии приёмки включали явный пункт «нагрузочное тестирование не входит в скоуп данного этапа» — дискуссии не было бы.
Как предотвратить
Документ «Критерии приёмки» (acceptance criteria) должен быть частью договора или приложением к нему. Вот что он обязательно включает:
РазделСодержаниеПример
Функциональные требованияПолный перечень реализуемых функций47 пунктов из ТЗ v1.3 Нефункциональные требованияПроизводительность, безопасность, доступностьВремя ответа API < 500 мс ИсключенияЧто явно НЕ входит в скоупНагрузочное тестирование, SEO, мобильное приложение Процедура приёмкиКто, когда и как подтверждает сдачуАкт приёмки в течение 5 рабочих дней после демо Гарантийный периодЧто покрывается, что нет2 недели: баги в реализованных функциях
Согласуйте критерии приёмки ДО начала разработки, а не после. Это защищает обе стороны и превращает субъективное «нравится / не нравится» в объективный чек-лист.
Ошибка 4. Следы субподрядчика в коде, git и метаданных
Эта ошибка — ночной кошмар любого агентства, работающего по white-label модели. CTO клиента открывает git log и видит коммиты от незнакомых людей. Или находит в package.json ссылку на npm-пакет с названием другой компании. Или замечает в .env.example домен подрядчика.
Что идёт не так
Разработчики думают кодом, а не бизнесом. Для них нормально подписывать коммиты своим именем, оставлять комментарии с пометкой «TODO: обсудить с {имя подрядчика}» и использовать внутренние библиотеки компании. Если агентство не проводит аудит перед сдачей — эти артефакты попадают к клиенту. А дальше — вопросы, подозрения и разрушение white-label фасада.
Реальный пример
Технический директор клиента, принимая проект, запустил стандартный скрипт проверки безопасности. Скрипт нашёл в конфигурационных файлах Sentry DSN с доменом подрядчика. Клиент напрямую загуглил этот домен — и через 10 минут знал, кто на самом деле писал код. Следствием стал не только неприятный разговор, но и требование пересмотреть условия договора: клиент посчитал, что агентство «накручивает» цену.
Как предотвратить
Аудит кодовой базы перед сдачей — обязательный этап. Минимальный чек-лист:
- Git history. Все коммиты — от имени сотрудников агентства или нейтральных аккаунтов. При необходимости — перезапись истории (git filter-branch или git filter-repo)
- Конфигурационные файлы. .env.example, docker-compose.yml, CI/CD-пайплайны — никаких упоминаний подрядчика
- Зависимости. package.json, requirements.txt, Gemfile — проверить на приватные пакеты подрядчика
- Комментарии в коде. Полнотекстовый поиск по имени подрядчика, названию компании, доменам
- Метаданные файлов. PDF-документы, изображения, шрифты — очистить EXIF и свойства документов
- Мониторинг и логирование. Sentry, Datadog, New Relic — переключить на аккаунты агентства или клиента
При работе с проверенным white-label партнёром очистка кодовой базы входит в стандартный процесс. Но финальную проверку агентство обязано провести самостоятельно — это ваша ответственность перед клиентом.
Ошибка 5. Нет плана поддержки после сдачи
Проект сдан, акт подписан, деньги получены. Агентство переключается на следующий проект. А через неделю клиент находит баг, пишет менеджеру — и получает ответ: «Мы уточним у команды». Через три дня — ещё один баг. Ещё через неделю — запрос на мелкую доработку. Без плана поддержки каждый такой запрос превращается в хаотичную переписку, которая раздражает обе стороны.
Что идёт не так
Момент сдачи — это не конец отношений, а их переход на новый уровень. Клиент, получивший MVP, неизбежно столкнётся с вопросами: баги в edge-кейсах, необходимость мелких доработок, вопросы по интеграциям. Если агентство не предложило структурированный план поддержки — клиент чувствует себя брошенным. А брошенный клиент не возвращается с повторным заказом.
Реальный пример
Агентство сдало корпоративный дашборд. Через 10 дней клиент обнаружил, что один из отчётов некорректно агрегирует данные при определённой комбинации фильтров. Написал менеджеру — тот не знал, кому передать задачу, потому что подрядчик уже закрыл проект. Переписка заняла 8 дней. Баг исправили за 2 часа — но впечатление было испорчено. Клиент ушёл к конкуренту на следующий проект.
Как предотвратить
Включите план поддержки в пакет сдачи. Клиент должен знать заранее, что происходит после подписания акта.
Стандартный план поддержки для white-label MVP:
ПериодЧто покрываетсяSLA
Гарантийный (2 недели)Баги в реализованных функциях из ТЗОтвет — 4 часа, исправление — 24 часа Постгарантийный (опционально)Доработки, новые функции, оптимизацияПо отдельному договору поддержки
Кроме того, зафиксируйте каналы коммуникации. Клиент должен знать, куда писать (email, Telegram, Jira), кто отвечает (конкретный менеджер) и в какие сроки. Отсутствие этой информации — причина 70% конфликтов на этапе поддержки.
Более того, гарантийный период — это возможность для upsell. Клиент видит, что агентство не бросает его после оплаты. Доверие растёт, и предложение о следующем этапе разработки воспринимается естественно. Подробнее о переходе от проекта к долгосрочному сотрудничеству — в материале о масштабировании агентства.
Какие ошибки сдача white-label проекта выявляет: чек-лист
Соберём все рекомендации в единый чек-лист. Используйте его как шаблон для каждого проекта — и ни одна из пяти ошибок не повторится.
За 5 дней до сдачи
- Провести аудит кодовой базы на следы подрядчика (git, конфиги, комментарии, метаданные)
- Подготовить документацию под брендом агентства (техническая, пользовательская, release notes)
- Согласовать критерии приёмки с клиентом (если не сделали на старте — сделайте сейчас)
- Подготовить сценарий демо и протестировать его в рабочем окружении
В день сдачи
- Провести управляемое демо (30-45 минут): бизнес-результат, ключевые сценарии, технические детали
- Записать все вопросы и замечания клиента
- Передать полный пакет документации
- Презентовать план гарантийной поддержки (2 недели, SLA, каналы связи)
После сдачи
- Получить подписанный акт приёмки в течение 5 рабочих дней
- Обработать замечания из демо (в рамках гарантии или как отдельный скоуп)
- Через 2 недели — контрольный звонок: «Всё ли работает? Есть ли вопросы?»
- Предложить план следующего этапа развития продукта
Итог: сдача проекта определяет будущие отношения
Все перечисленные ошибки сдача white-label проекта выявляет с пугающей регулярностью: документация, отсутствие демо, неопределённые критерии приёмки, следы подрядчика и отсутствие плана поддержки. Они происходят не из-за плохой разработки, а из-за плохой подготовки к передаче. Технически идеальный продукт может быть «провален» из-за неправильной передачи клиенту.
Хорошая новость: каждая из этих ошибок предотвратима. Чек-лист из этой статьи закрывает 90% рисков. Оставшиеся 10% — это специфика конкретного клиента, которую можно учесть при подготовке к проекту.
Хотите предотвратить ошибки сдача white-label проекта провоцирует на практике? Запишитесь на бесплатную 30-минутную Zoom-консультацию. Разберём ваш конкретный случай: какие документы подготовить, как провести демо и что включить в критерии приёмки.
FAQ о сдаче white-label проекта
Кто должен проводить демо — агентство или подрядчик?
Демо всегда проводит агентство. Это ваш клиент, ваш бренд и ваша репутация. Подрядчик готовит презентационные материалы, сценарий демо и проводит репетицию с менеджером агентства — но на встрече с клиентом присутствует только команда агентства. Это ключевое правило white-label: клиент не должен знать о существовании субподрядчика.
Что делать, если клиент требует доработки после подписания акта приёмки?
Зависит от характера доработки. Баги в реализованных функциях из ТЗ покрываются гарантийным периодом (стандарт — 2 недели). Новые функции или изменения в существующих — это отдельный скоуп работ с отдельной оценкой и договором. Именно поэтому критерии приёмки должны быть зафиксированы до начала проекта: они проводят чёткую границу между гарантийными исправлениями и платными доработками.
Как убедиться, что в коде не осталось следов подрядчика?
Минимальная проверка: полнотекстовый поиск по названию компании подрядчика, доменам и именам сотрудников в коде, конфигурационных файлах и git-истории. Продвинутая проверка: аудит метаданных документов (PDF, изображения), проверка зависимостей (npm, pip) на приватные пакеты и ревизия мониторинга (Sentry, логи). При работе с профессиональным white-label партнёром очистка кода входит в стандартный пакет — но финальную проверку агентство проводит самостоятельно.
Можно ли проводить сдачу проекта удалённо?
Да, большинство сдач проходят через Zoom или Google Meet. Формат не влияет на качество — влияет подготовка. Для удалённого демо особенно важно: стабильное интернет-соединение, заранее открытые вкладки с продуктом, запись встречи (с согласия клиента) и отправка follow-up письма с резюме и следующими шагами в течение 2 часов после звонка.