Now I have the full picture. The most relevant posts for the dogfooding article:
- supabase-rls-multi-tenant-saas — RLS section directly discusses multi-tenant security
- mcp-studio-infrastructure — studio's own infrastructure as moat
- ai-agents-in-product-dev — AI agents in production (Amelia)
- sdvig-fokusa-na-digital-pod-klyuch — strategy pivot SaaS→agency
Let me now produce the markdown with 4 internal links woven naturally into the text.
Догфудинг — почему мы ведём клиентов на своём движке, а не на чужом SaaS
14 мая 2026 года, 23:40, я зашёл в админку M.Sight под аккаунтом второго агентства и увидел клиентов первого. Тринадцать RLS-политик на пяти таблицах пропускали данные между тенантами. Если бы на платформе было реальное чужое агентство, его клиенты увидели бы чужую базу. Этот баг не нашёл бы ни один QA-инженер, ни один пентестер по чеклисту. Его нашёл я, потому что каждый день работаю в продукте, который сам построил. Это и есть dogfooding, только не в версии Microsoft и Slack, а в версии сервисного бизнеса, где на кону не абстрактные метрики, а живые клиенты с реальными рекламными бюджетами.
Agency-as-lab: когда ты и разработчик, и первый клиент с реальным бюджетом
Есть классическое понимание dogfooding: Microsoft пользуется Windows, Slack общается в Slack, JetBrains пишет код в IDEA. Продуктовая компания юзает свой продукт. Логично. Но что если ты не продуктовая компания, а сервисный бизнес? Агентство, которое одновременно строит инструмент и обслуживает на нём живых клиентов с реальными рекламными бюджетами?
Milakhin Studio ведёт клиентов через собственные M.Sight (агентский дашборд) и M.Flow (CRM + AI + реклама). Не потому что это модно, а потому что другого способа контролировать качество на каждом этапе воронки я не нашёл. Когда ты работаешь в чужом SaaS, ты видишь то, что вендор решил тебе показать. Когда работаешь в своём, ты видишь всё: от сырого API-ответа до конверсии в продажу.
Разница между продуктовым и сервисным dogfooding в одном: я ставлю на кон не только свой продукт, а свои деньги и репутацию перед клиентом. Каждый день. Если M.Flow сломается, это не абстрактный тикет в Jira. Это живой лид, который ушёл к конкуренту моего клиента.
Формула получается такая: собственный движок плюс реальные рекламные бюджеты клиентов = feedback loop, которого нет ни у кого на рынке. Ты одновременно разработчик, тестировщик и пользователь. И пользователь не вежливый бета-тестер, а человек, который платит за результат.
Один из наших клиентов, официальный дилер грузовиков, при первом созвоне описал свою боль дословно: «Автоматизировать процесс полностью. Получать уже готовые горячие заявки. До меня клиент должен ознакомиться, ответить на нужные вопросы, и только когда он горячий, попадать ко мне на обработку». Он не знал, что описывает ровно то, что делает M.Flow плюс AI-консультант в продакшене плюс рекламная связка. Это не описание digital-услуги, это описание продукта. Валидация без опросов и custdev-сессий.
Feedback velocity: баг утром, фикс вечером
Индустриальный стандарт: пользователь нашёл баг, написал в саппорт, саппорт завёл тикет, тикет попал в бэклог, продакт приоритизировал, разработчик взял в спринт. Две-четыре недели если повезёт. Шесть, если нет.
У нас путь другой. Я открываю CRM утром, вижу что один контакт дублируется три раза, и к вечеру три корневые причины найдены и починены. Первая: три разных создателя лидов (быстрый лид, AI-консультант Амелия, авто-лид по intent) не дедуплицировались между собой. Вторая: Амелия складывала информацию о клиенте в текстовое поле summary вместо структурных полей, и дедуп не мог сопоставить данные. Третья: stale React state в канбане, useState помнил старые лиды при переключении pipeline-табов. Три разных слоя, три разных фикса, шесть чистых лидов в «Продажи» к концу дня.
Или другой случай. Первый живой лид в M.Flow: ИП из Сарыагаша, грузовик за 19.9М, лизинг. Амелия квалифицировала автоматом, но когда я открыл карточку, поля были пустые. Причина: payload.fields был nested вместо flat, и drawer не видел данных. Баг починен в тот же вечер.
Клиент не знает, что баг был, потому что баг жил четыре часа, а не четыре спринта. Feedback velocity тут не метрика из презентации, а конкурентное преимущество, которое невозможно купить. Оно возникает только когда разработчик и пользователь, это один человек с одним Slack и одним репозиторием.
RLS-утечка: как dogfood спас от катастрофы до запуска
Одна ночная сессия в M.Sight. 27 пунктов фидбека, 13 коммитов, 2 root-cause фикса. Среди мелочей типа сломанного density toggle и контраста кнопок на пяти темах была одна находка, ради которой dogfooding и существует.
Я зашёл в админку второго агентства (тестового, на жену) и увидел клиентов чужого агентства. Расследование показало: целый класс RLS-политик, 13 штук на 5 таблицах, гейтил доступ через голый is_admin() без привязки к агентству. Любой пользователь с ролью admin мог видеть и менять данные всех агентств на платформе.
Это не теоретическая уязвимость из OWASP-чеклиста. Это реальная утечка данных, пойманная на живой системе. Если бы на платформу пришло второе настоящее агентство, его клиенты увидели бы чужую базу. Или хуже, чужое агентство увидело бы их.
Поймали потому что на платформе были два агентства, оба фактически мои. Внешний пользователь не стал бы проверять: он бы просто увидел данные, которые не должен видеть, и либо ушёл, либо (что хуже) промолчал. Фикс: миграция 064, agency-scoped функции вместо голого is_admin(). Подробнее о том, как выстроить multi-tenant RLS без дыр, я разбирал в отдельном гайде.
Урок для любого multi-tenant продукта: в RLS is_admin() без tenant-scoping это дыра. Не «потенциальная угроза», не «рекомендуется исправить». Дыра. Мы её поймали до реального онбординга, и ради этого dogfood и нужен.
Пивот на ходу: когда продукт говорит тебе что ты не прав
M.Flow начинался как классическая связка: лендинг, форма, CRM. Первый тенант, Skin&Water (студия подводного массажа, друзья), быстро показал: лендинг-форма не ядро. Их аудитория покупает через IG Direct и WhatsApp. Никто не заполняет формы. Приоритет сместился на модуль «Мессенджеры»: IG DM плюс WhatsApp в единый Inbox.
Это не аналитика рынка и не custdev из учебника. Это ежедневное использование продукта на реальном клиенте, который показывает тебе, где ты ошибся.
Второй пивот случился на клиенте-дилере грузовиков. Продукт проектировался под бьюти с коротким циклом сделки: пришёл, записался, купил. Дилер вскрыл целый класс требований для B2B high-ticket: стадия лизинга в воронке, глубокая квалификация по семи параметрам до передачи лида менеджеру, приоритизация по объёму сделки, постпродажная воронка. Ничего из этого не было в бэклоге, потому что я не знал, что это нужно, пока не начал работать с реальным бизнесом.
Третий пивот был болезненнее. Неделя танцев с Meta App Review: IG API не привязывался, Telegram-бот работал криво. Решение: убрали зависимость от Meta полностью, поставили виджет на сайт плюс Telegram-бот для уведомлений владельцу. Полный цикл (клиент приходит, AI-консультант квалифицирует, лид в CRM, пуш владельцу) заработал без единой вертикали Meta. Когда нужен будет нативный IG/WA, добавим как опцию поверх.
Каждый из этих пивотов родился не из Notion-борда с гипотезами, а из того, что я каждый день открывал свой продукт и работал в нём на живых клиентах.
Движок = моат: почему чек выше рынка
Конкурент ведёт клиента в Excel или в чужом CRM. У него нет AI-первой линии, нет единой воронки spend-lead-sale, нет автоматической квалификации лидов. Он продаёт руки. Мы продаём систему.
Движок, это моат студии. Конкурент ведёт клиента в Excel, мы в системе с AI-первой линией. Поэтому наш чек кратно выше среднерыночного. Не потому что мы «премиум-агентство» с красивой презентацией, а потому что клиент получает технологию, которой у конкурентов физически нет. Под капотом у студии собственная инфраструктура на 29 MCP-инструментах, которая связывает рекламу, аналитику и CRM в единый контур.
В какой-то момент встал вопрос: делать из M.Flow публичный SaaS или оставить как внутреннее оружие студии. Считал экономику. SaaS-путь: десятки мелких клиентов за небольшой чек, минус отток, минус саппорт, минус биллинг, минус инвайты. Agency-путь: один крупный клиент тянет столько же выручки, сколько десятки мелких. Без публичного биллинга, без саппорта толпы.
Выбрал второе. M.Flow из публичного SaaS превратился в оружие студии для обслуживания клиентов под высокий чек. Осознанный риск: agency не масштабируется как SaaS, упираешься в своё время и команду. Но для задачи «заработать быстро и реально» линейный доход бьёт мифический масштаб. Подробнее о логике этого разворота я писал в посте про смещение фокуса с SaaS на digital под ключ.
Параллельно строим собственный WhatsApp-коннектор вместо платных решений. Экономия на нескольких клиентах складывается в существенную сумму за год, плюс полная независимость от вендора. Код готов, деплой в бэклоге. Каждый такой шаг, собственный коннектор, собственный AI-экстрактор полей, собственная дедупликация лидов, это ещё один кирпич в моат, который конкурент не может скопировать, купив подписку на SaaS.
Client-as-testbed dilemma: этика dogfooding на чужих деньгах
Прямой вопрос, который я задаю себе: если клиент платит за результат, а получает полигон для обкатки моего продукта, это честная сделка?
Контраргумент: клиент получает технологию, которой нет у конкурентов его подрядчика. AI-консультант, который квалифицирует лидов 24/7 на двух языках. Автоматическая дедупликация. Экстрактор данных из голосовых через Whisper. CTWA-атрибуция. Всё это работает в проде, не в презентации. И клиент платит за это меньше, чем стоимость этой технологии на рынке, потому что я не продаю софт, я продаю результат, а софт в комплекте.
Все цифры и способности на лендинге студии реальные из M.Flow. Ничего не выдумано. Если написано «AI-квалификация лидов», значит Амелия прямо сейчас отвечает клиентам дилера грузовиков на казахском и русском. Если написано «дедуп лидов», значит три корневые причины дублей найдены и починены на живых данных. Прозрачность, это не маркетинговый ход, это единственный способ не чувствовать себя шарлатаном.
Skin&Water ведётся бесплатно (друзья, пилотный кейс). Но когда пошли платные клиенты, уровень инструмента уже был боевой, потому что полгода обкатки на пилоте сделали своё дело. Первый платный клиент получил не бета-версию, а систему, прошедшую через десятки багов, три пивота и одну серьёзную RLS-утечку.
Разница между «использую клиента как guinea pig» и «даю клиенту доступ к технологии, которую рынок ещё не продаёт» в том, несёшь ли ты ответственность за результат. Если баг, я его чиню за вечер, а не через четыре спринта. Если пивот, я перестраиваю продукт под реальную боль, а не отправляю feature request вендору.
Слепые зоны: где dogfooding врёт
Founder bubble, это когда ты знаешь свой продукт настолько хорошо, что перестаёшь замечать проблемы онбординга. Я могу найти нужную кнопку за секунду, потому что я её туда поставил. Новый пользователь будет искать три минуты. Dogfooding ловит баги инфраструктуры (дубли, утечки, сломанный стейт), но не ловит UX-слепоту. Для этого нужен внешний взгляд, и я это понимаю.
Второе ограничение: dogfooding не заменяет product-market fit. Я могу построить идеальный инструмент для своих пяти клиентов и при этом полностью промахнуться мимо рынка. Slack, это исключение из правил и survivorship bias. 95% internal tools так и остаются internal, просто об этом не пишут посты.
Третье, и самое актуальное в 2026: vibe coding плюс dogfooding без code review это бомба замедленного действия. Скорость драфта растёт кратно, но баги в первом проходе тоже. Когда ты генеришь код с AI и тут же катишь в прод на живых клиентах, цена ошибки не абстрактная. Она измеряется в потерянных лидах и репутации.
Противоядие одно: осознанный dogfooding с дисциплиной. Каждый баг, пойманный в продакшене на своих клиентах, это не «ну ладно, починим потом». Это архитектурный урок, который записывается, анализируется и превращается в правило. RLS-утечка превратилась в миграцию и чеклист. Дубли лидов превратились в три отдельных фикса и AI-экстрактор. Сломанный Meta API превратился в архитектуру, независимую от вендора. Не «быстро и сломалось», а «на своих, поэтому крепко».