~/oybek.dev
статьи
Agencies18 марта 2026 г.· 8 мин чтения

White-label для senior-разработчика: как агентства подключают меня без хаоса

Операционная модель, по которой я подключаюсь к агентствам как white-label инженер и fractional CTO: помощь в предложениях, еженедельные демо, владение кодом и передача без узких мест.

Большинству агентств не нужен очередной фрилансер — им нужен senior-инженер, который сможет оценить проект, поговорить с клиентом, выпустить продукт и аккуратно исчезнуть, и всё это под брендом агентства. Именно это на деле и означает быть white-label-разработчиком для агентств, и за годы работы в роли фракционного CTO внутри дубайского агентства я превратил это в повторяемую операционную модель. Клиенты, для которых я строил продукты, так и не узнали о моём существовании. Агентство сохранило и маржу, и отношения с клиентом. Ничего не загорелось. Вот как это работает — с обеих сторон стола, потому что я сидел в обоих креслах.

Хаос, которого все боятся при работе с внешним senior-разработчиком, реален, но его можно избежать. Он возникает из четырёх предсказуемых пробелов: размытый объём работ, ритм поставки, который никто не видит, коммуникация через три слоя испорченного телефона и передача дел, которая живёт в голове одного человека. Закройте эти четыре пробела — и white-label перестаёт быть риском и превращается в самый дешёвый способ для агентства купить senior-мощности.

Оценка объёма начинается в коммерческом предложении, а не после выигрыша сделки

Большинство агентств привлекают разработчика уже после того, как сделка выиграна (или проиграна). Это задом наперёд. Самое ценное, что я делаю для агентства, происходит во время питча, когда ещё есть шанс корректно оценить объём работ.

Я помогаю написать техническую половину предложения: архитектуру, выбор стека, реалистичные сроки и — то, в чём агентства регулярно ошибаются — что явно *не входит* в объём работ. Когда менеджер по продажам обещает «и оно будет синхронизироваться с их ERP» без разработчика в комнате, именно эта строчка съедает маржу за три недели до запуска. Я тот человек, который поднимет этот вопрос прямо на звонке, а не обнаружит его во втором спринте.

Здесь же важна честность в выборе стека. Агентство, продающее маркетинговый сайт, не должно котировать сборку headless-коммерции, и наоборот. Я скажу клиенту, когда Shopify Hydrogen — правильный выбор вместо MedusaJS с учётом размера каталога и команды (я написал целый разбор этого решения) или когда маркетинговый сайт на Sanity и Next.js — это всё, что им на самом деле нужно. Правильно решить это в предложении — вот что делает фиксированную цену безопасной для обеих сторон. Отдельно я писал о том, как оцениваю проект за 48 часов без раздувания сметы; если коротко, грамотная оценка объёма — это senior-задача, а не что-то второстепенное.

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

Ритм спринтов: демо каждую неделю, без исключений

Когда мы начинаем строить, ритм не обсуждается, и именно он наглухо убивает «хаос»: работающее демо на живом staging-URL каждую неделю, с разбором в Loom. Не апдейт статуса. Не сообщение в Slack «всё идёт хорошо». Работающий продукт, который агентство может покликать, каждую пятницу.

Этот ритм делает три дела одновременно. Он заставляет работу быть настоящей — деплой на staging не подделаешь. Он рано вскрывает отклонение от курса, пока неделю работы дешево перенаправить, а не месяц. И он даёт агентству что-то конкретное, что можно показать клиенту, при том что я ни разу не появляюсь на клиентском звонке. Когда что-то срывается — а на долгом проекте всегда что-то срывается, — агентство узнаёт об этом от меня первым, вместе с планом восстановления, ещё до того, как это заметит клиент. В этом и есть разница между партнёром и подрядчиком.

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

Коммуникация с клиентом: основную работу делают Loom-видео

Вот в чём противоречие white-label: мне нужно общаться ясно, но обычно я не могу выступать как я сам. Loom решает это лучше, чем встречи.

Двух-пятиминутная запись экрана с обзором того, что было выпущено за неделю, делает то, чего не может живой звонок. Агентство смотрит её первым, решает, что переслать, и при желании может перебрендировать или перезаписать вступление, чтобы на видео было их лицо. Клиент получает ясное, спокойное объяснение прогресса без четвёртого человека в их Slack. И никто не теряет час на статус-митинг, который мог бы быть видео.

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

Превью Loom поверх staging-окружения, рядом боковая панель с записями еженедельных демо
Асинхронные разборы заменяют статус-митинги и оставляют поисковый след.

Право собственности на код с первого дня

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

Это значит, что работа идёт в GitHub-организации агентства (или клиента), в их CI/CD, с их управлением секретами, на инфраструктуре, которую они контролируют — обычно Vercel для Next.js-части, их собственное облако для Laravel-API. Я не строю в приватном репозитории, чтобы «передать потом». Никакого «потом» нет. Если бы я завтра исчез, у агентства был бы каждый коммит, каждая задокументированная переменная окружения, каждый деплой воспроизводим. White-label, при котором код живёт на машине подрядчика, — это не white-label, это захват заложника.

Та же дисциплина касается скучной инфраструктуры, которую основатели пропускают. Когда я берусь за проект, начавшийся как vibe-coded-прототип, первое, что я делаю, — завожу его в нормальный version control со staging, мониторингом и бэкапами, потому что «работает на моём ноутбуке» — это не право собственности. Чистота коммитов, читаемые PR и архитектурные решения, записанные по ходу их принятия, — вот что делает код по-настоящему принадлежащим агентству, а не только юридически их. Этот же стандарт я держу и на собственных сборках веб-приложений.

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

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

Чистая передача дел в моём понимании означает:

  1. README, который действительно вводит человека в курс. Как запустить, как задеплоить, откуда берутся секреты, какими были неочевидные решения и почему. Не сгенерированный шаблон — настоящая карта.
  2. Архитектурные заметки по неочевидным выборам. Почему эта очередь, почему эта стратегия кеширования, почему Server Components здесь, а не там. То, что новый разработчик иначе реверс-инжинирил бы мучительную неделю.
  3. Записанный разбор живой системы. Один Loom, который проводит следующего инженера агентства по кодовой базе сверху донизу.
  4. Живое окно перехода, а не резкий обрыв. Я остаюсь на связи для вопросов в течение согласованного периода, чтобы передача дел пережила столкновение с реальностью.

Я построил региональную EV-платформу NIO — конфигуратор автомобилей на коммерции MedusaJS с Sanity CMS — специально так, чтобы маркетинговая команда могла сама публиковать кампании и обновлять контент, без бутылочного горлышка в виде разработчика. Это тот же инстинкт, что и за хорошей передачей дел: система не должна зависеть от человека, который её построил. Лучший комплимент, который я получаю, — тишина после моего ухода, потому что ничего не сломалось и никому не пришлось мне звонить.

Чек-лист передачи дел с отмеченными пунктами README, архитектурные заметки, записанный разбор и окно перехода
Передача дел непрерывна, а затем формализуется — это не паническая записка, написанная в последний день.

Во что это обходится агентству и почему математика сходится

Я веду это как ежемесячный ретейнер, а не почасово. Агентства получают senior-огневую мощь — оценку объёма, архитектуру, ревью кода, прикладную поставку и AI-фичи на Vercel AI SDK, когда клиент их хочет, — не неся senior-зарплату, стоимость рекрутинга или риск простоя между проектами. Когда поджимают дедлайны, я руками на клавиатуре. Когда нет — я ревьюю PR команды агентства и менторю.

Честный компромисс

Это не самый дешёвый способ написать строчку кода. Junior-подрядчик на почасовке дешевле в час. Это самый дешёвый способ *корректно выпустить клиентский проект под вашим брендом* — потому что дорогая часть агентской работы никогда не была печатанием. Это были переоценка объёма, переделки, неловкие звонки, когда обещанная фича оказывалась невозможной. Вот что убирает white-label senior-разработчик.

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

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

Что на самом деле делает white-label-разработчик для агентств?

White-label-разработчик работает под брендом агентства и остаётся невидимым для конечного клиента. На практике это значит помогать оценивать объём и котировать проекты во время питча, строить сам продукт, доносить прогресс через агентство и выпускать под их именем. Для клиента это выглядит так, будто у агентства есть сильный штатный senior-инженер — что на время проекта фактически и есть.

Чем фракционный CTO отличается от подрядчика?

Подрядчик берёт спецификацию и пишет код. [Фракционный CTO](/services/service-fractional-cto) владеет техническим результатом: решениями по стеку, архитектурой, оценкой объёма, ревью кода, влиянием на найм и поставкой. Для агентства разница виднее всего на стадии предложения и при передаче дел — подрядчика нет в комнате, когда оценивают сделку, а фракционный CTO — это причина, по которой объём вообще реалистичен.

Как вы сохраняете конфиденциальность договорённости?

NDA по умолчанию, бренд агентства на всём, и я никогда публично не перечисляю white-label-клиентов. Код живёт в аккаунтах агентства или клиента, я появляюсь под почтой агентства, когда нужен контакт с клиентом, а конечный клиент видит агентство, и точка. Конфиденциальность — это вся суть модели.

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

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

Под какие стеки вы работаете в white-label?

В основном [Next.js](/technology/nextjs) и React на фронтенде, Laravel для API и бэкендов, Sanity для контента, MedusaJS и Shopify Hydrogen для headless-коммерции и [React Native](/technology/react-native) для мобайла. Также работаю с [Umbraco](/technology/umbraco) для enterprise-сборок CMS. Стек следует за проектом, а не наоборот.

Можете ли вы подключаться к клиентским звонкам при необходимости?

Да — как член команды агентства, на их почте и под их брендом. Большая часть коммуникации асинхронная, через Loom и письменные резюме, потому что так быстрее и остаётся поисковый след, но для discovery-воркшопов или сложных технических обсуждений присутствие senior-инженера на звонке того стоит. Клиенту не нужно знать оргструктуру.

Есть похожая задача?

Начать проект