Неделя 137. Пять лендингов за пять дней и скрытая цена скорости
Разбор этой статьи
Эту тему разобрали в подкасте. Слушай параллельно с чтением.
За одну неделю мы выкатили новый лендинг, пройдя пять версий дизайн-концепции за пять дней. Запустили биллинг для WhatsApp Business API. Построили White Label для партнёров. Переименовали и прокачали новый продукт. 315 коммитов в девяти репозиториях - самая продуктивная неделя в истории компании на тот момент.
И в этой же неделе мы заложили ошибку, которая стоила нам семи дней разгребания. Если вы читали ретроспективу недели 138, вы уже знаете, чем закончилась история: Lighthouse Mobile 0. Сегодня расскажу, откуда взялся этот ноль.
Я Дмитрий Дьяконов, основатель Botseller AI. Это четвёртый выпуск серии «Ретроспектива» - бортжурнал в прошлое, от настоящего к первому коммиту.
Пять версий лендинга за пять дней
Старый лендинг Botseller выглядел как «ещё один SaaS»: hero-блок, три колонки преимуществ, тарифы, футер. Работал, конвертил посредственно, не запоминался. В начале недели мы решили: делаем визуальную концепцию заново.
Хронология недели:
Вторник, 17 марта. Первая визуальная концепция. Скролл-хореография: контент раскрывается по мере прокрутки, как в презентации.
Среда, 18 марта. Четвёртая итерация - уровень «Awwwards-quality»: плавность анимаций, кинематографичные переходы, внимание к микродеталям.
Четверг, 19 марта. Пятая версия плюс параллельная ветка «Cinematic»: пружинные анимации, keynote-ритм повествования, социальные доказательства, видео-отзывы.
Пятница, 20 марта. GSAP ScrollSmoother, скролл-снаппинг, якорная навигация, CTA основателя. И главное - выкат concept-v2 на главную страницу продакшена.
Суббота, 21 марта. Слайдовая презентация с iPad-подобными переходами для десктопа.
Пять дней от идеи до продакшена. Звучит как история успеха - и в части скорости это она и есть. Мы не собирали фокус-группы, не рисовали макеты по три недели в Figma. Каждая версия жила в коде, смотрели на реальный лендинг, резали и переделывали.
Скорость итераций - реальное преимущество маленькой команды. Проблема была не в скорости.
Бомба замедленного действия: что мы не проверили
GSAP ScrollSmoother, пружинные анимации, полноэкранные слайды с графикой, видео-отзывы, кинематографичные переходы. Каждый элемент по отдельности - украшение. Вместе - сотни DOM-узлов, десятки скролл-триггеров и вся графика, загружающаяся разом.
На мощном MacBook с быстрым интернетом лендинг летал. Красота, плавность, «вау». Мы смотрели на него именно так - глазами владельца, а не глазами Google-краулера и не глазами клиента с бюджетным Android в метро.
Что мы НЕ сделали перед выкатом на главную:
- Не прогнали Lighthouse на мобильном профиле
- Не проверили LCP на throttled-соединении
- Не посмотрели, сколько весит страница целиком
- Не задали себе вопрос «а что увидит человек на слабом устройстве»
Ответ на последний вопрос мы получили через неделю, когда наконец запустили аудит: Lighthouse Mobile - 0. Ноль. Слайды монтировались все сразу, LCP уходил за 10 секунд, мобильная версия фактически не работала. Неделя 138 целиком ушла на разгребание: LazyMount, ленивый рендеринг, отдельная лёгкая мобильная страница без GSAP.
Справедливости ради - частично мы это предвидели: уже в субботу появился коммит «мобильная версия: отдельная лёгкая страница без GSAP». Но выкат на главную случился раньше аудита. Порядок был неправильный.
Урок: скорость без ворот - это кредит под скрытый процент
Главный фаундерский вывод недели 137 звучит так: каждый выкат без проверки метрик - это кредит. Тело кредита - сэкономленные десять минут. Процент - неделя работы потом.
Мы не сделали ничего необычного - так выкатывается половина редизайнов в индустрии. Дизайнер показывает на большом экране, основателю нравится, разработчик мержит. Все смотрят на продукт через своё железо и свой вкус. Google и пользователи смотрят через другое.
Практический фреймворк, который мы внедрили после этой истории - performance-ворота перед мержем. Три проверки, десять минут:
-
Lighthouse Mobile ≥ 85. Прогон в Chrome DevTools на мобильном профиле с throttling. Ниже порога - не мержим, точка. Красота не аргумент: страница, которую не дождались, не конвертит.
-
LCP ≤ 2.5 секунды. Largest Contentful Paint на медленном 4G. Если главный контент приезжает дольше - убираем из критического пути всё, что можно отложить.
-
Вес страницы ≤ 2 МБ на первом экране. Всё остальное - лениво, по мере скролла.
Правило работает только если оно ворота, а не рекомендация. «Выкатим сейчас, оптимизируем потом» - это то самое «потом», которое стоило нам недели. Дешевле всего чинить то, что ещё не выкачено.
И второе правило, которое мы вынесли: у красоты должна быть бюджетная версия. Тяжёлая скролл-хореография - для десктопа с хорошим каналом. Для мобильных - отдельная лёгкая страница: тот же контент, та же конверсионная логика, ноль тяжёлых анимаций. Это не компромисс, это уважение к половине аудитории.
Параллельный трек: неделя, когда WhatsApp начал приносить деньги
Пока лендинг переживал пять итераций, продуктовая команда строила инфраструктуру денег. WhatsApp Business API (WABA) - официальный канал массовых рассылок - получил полный цикл монетизации.
Embedded Signup. Раньше подключение WhatsApp Business API требовало ручной настройки: заявки, токены, конфигурации. Теперь - встроенный флоу: клиент проходит авторизацию Meta прямо из интерфейса Botseller, и номер подключается за минуты. Онбординг из «напишите в поддержку» превратился в «нажмите кнопку».
Биллинг разговоров. WhatsApp тарифицирует бизнес по «разговорам» - 24-часовым окнам общения. Мы построили полный цикл: провайдер шлёт billing-событие, оно сохраняется, стоимость списывается с баланса клиента.
Три инженерных решения в этом биллинге, которые пригодятся любому, кто строит списания на вебхуках:
-
Save-first паттерн. Сначала сохраняем событие в базу, потом списываем деньги. Если списание упало - событие есть, можно доначислить. Если наоборот - деньги ушли в никуда.
-
Идемпотентность по внешнему ID. Провайдер может прислать один и тот же billing-event дважды. Дедупликация по уникальному ID события, а не по timestamp: у ретраев время меняется, ID - нет. Отдельный fallback-ключ для событий без ID.
-
Себестоимость рядом с ценой. Для каждого события храним не только сколько списали с клиента, но и сколько заплатили провайдеру. Маржа видна на уровне каждого разговора, а не «в конце месяца по счетам».
White Label: платформа под чужим брендом
Третий трек недели - партнёрская программа выросла до White Label. Партнёр теперь может продавать Botseller под собственным брендом: свой домен, свой логотип, свои цвета на страницах входа и регистрации, свои клиенты в изолированном кабинете.
Под капотом это потребовало новой роли в системе доступа, модели лицензий с self-service, динамического брендинга (сайдбар, auth-страницы и email-шаблоны подстраиваются под домен партнёра) и аккуратной работы с cookie: авторизация должна жить на домене партнёра, а не на нашем.
Отдельный урок из этого трека - безопасность брендинг-эндпоинтов. Публичный endpoint «отдай брендинг по домену» - это дверь, в которую постучатся не только партнёры: пришлось добавить regex-валидацию домена и защиту от path traversal в первые же дни. Любой публичный endpoint, принимающий строку от клиента - это поверхность атаки, даже если он «просто отдаёт логотип».
Зачем это бизнесу: White Label превращает агентства и интеграторов в канал продаж. Они приводят клиентов под своим брендом, мы получаем объём без затрат на привлечение. Подробнее о моделях партнёрства мы писали в статьях про White Label SaaS и бизнес на нейросетях, а условия программы собраны на странице для партнёров.
Рой агентов и тиры вместо моделей
Два решения недели, которые касаются ИИ под капотом.
Двухуровневый анализ в «Рое агентов». Новый продукт для работы с Telegram-сообществами получил экономичную архитектуру ИИ: лёгкая быстрая модель делает triage (стоит ли вообще реагировать), тяжёлая включается только там, где нужен качественный ответ. Расход на инференс падает в разы, потому что 90% событий отсеиваются дешёвым первым уровнем. Этот паттерн - triage перед дорогой операцией - применим к любому ИИ-продукту с потоком событий.
Тиры вместо имён моделей. Мы убрали из интерфейса названия конкретных ИИ-моделей и заменили их на тиры: Botseller Low, Medium, High, Ultra. Причина простая: имена моделей меняются каждый квартал, а обещание «быстрее и дешевле» против «умнее и дороже» - стабильно. Клиент выбирает уровень качества, а какая модель под капотом - наша забота: мы можем менять провайдера без миграций и переобучения пользователей. Если строите ИИ-продукт - не привязывайте UI к именам моделей, привяжите к уровням сервиса.
Контент: пять статей и документация
На фоне трёх продуктовых треков сайт получил пять новых SEO-статей: про внедрение ИИ-ассистента в продажи, крауд-маркетинг, партнёрскую экосистему, ИИ-рекрутера. Плюс полная документация по WhatsApp Business API: подключение, шаблоны, рассылки - и шесть страниц документации по «Рою агентов».
Заметьте: это ещё стихийный контент, до системы. Статьи писались по наитию, без семантического ядра и кластеров - до content pruning недели 138 и контент-машины недели 140 оставалось две и три недели соответственно. Ретроспектива в обратном порядке хорошо показывает эволюцию: сначала пишем «что-то полезное», потом учимся удалять, потом строим систему.
Был - стал: до и после недели 137
| Метрика | До (15 марта) | После (21 марта) |
|---|---|---|
| Лендинг | Классический SaaS-шаблон | Скролл-хореография, GSAP, слайды |
| Performance-гейт перед мержем | Нет | Нет (появился после недели 138) |
| Подключение WhatsApp Business API | Вручную через поддержку | Embedded Signup за минуты |
| Биллинг WABA-разговоров | Нет | Полный цикл со списанием с баланса |
| White Label | Нет | Роль, брендинг, лицензии, кабинет |
| Имена ИИ-моделей в UI | Видны | Тиры Low/Medium/High/Ultra |
| Статей в блоге за неделю | - | +5 и документация |
Цифры недели 137
| Метрика | Значение |
|---|---|
| Коммитов всего | 315 |
| Репозиториев с активностью | 9 |
| Версий дизайн-концепции лендинга | 5 за 5 дней |
| Коммитов во frontend платформы | 97 |
| Новых SEO-статей | 5 |
| Lighthouse Mobile после выката | 0 (обнаружено на неделе 138) |
| Дней на устранение последствий | 7 |
Что я сделал бы иначе
Ретроспектива честна, только если в ней есть эта секция.
Поставил бы performance-ворота до редизайна, а не после. Десять минут на прогон Lighthouse перед мержем concept-v2 сэкономили бы неделю. Теперь это правило: метрика - часть Definition of Done, не «оптимизируем потом».
Выкатил бы мобильную версию первой, а не последней. Мы строили десктопную красоту и в конце добавили «лёгкую мобильную страницу». Правильный порядок обратный: сначала работающая мобильная версия (большинство трафика), потом десктопные украшения.
Не менял бы лендинг и блог одновременно. Параллельный редизайн лендинга и главной блога размазал фокус и удвоил поверхность для багов. Одна большая визуальная стройка за раз.
А вот скорость итераций - пять версий за пять дней - оставил бы как есть. Проблема была не в скорости, а в отсутствии ворот. Быстрая машина без тормозов - опасна. Но решение - поставить тормоза, а не пересесть на телегу.
В следующем выпуске ретроспективы - неделя 136: рождение WABA-интеграции, с которой начался весь WhatsApp-трек.
Это серия «Ретроспектива Botseller» - путешествие от первого коммита до рабочего продукта. Читайте в любом порядке. Подписывайтесь на Telegram-канал, чтобы не пропустить новые выпуски.
FAQ
Как проверить производительность сайта перед выкатом?
Минимальный набор - три проверки за десять минут: Lighthouse в Chrome DevTools на мобильном профиле (порог 85+), LCP на throttled 4G (порог 2.5 секунды), суммарный вес первого экрана (до 2 МБ). Важно сделать их воротами: ниже порога - релиз не выходит, без исключений «на этот раз».
Влияют ли тяжёлые анимации на SEO?
Напрямую: Core Web Vitals - фактор ранжирования Google, а скролл-библиотеки, полноэкранные слайды и синхронная загрузка графики убивают LCP и TBT на мобильных. Google индексирует mobile-first, поэтому красивый десктопный лендинг с мёртвой мобильной версией теряет позиции целиком.
Что такое Embedded Signup в WhatsApp Business API?
Это встроенный флоу подключения: клиент проходит авторизацию Meta прямо в интерфейсе платформы, без ручных заявок и передачи токенов. Подключение номера занимает минуты вместо дней. Для SaaS-платформ это стандарт онбординга: чем меньше шагов до работающего канала, тем выше активация.
Как правильно строить биллинг на вебхуках провайдера?
Три правила: save-first (сначала сохранить событие, потом списывать деньги), идемпотентность по внешнему ID события (провайдеры повторяют вебхуки при ретраях), и хранение себестоимости рядом с ценой (маржа видна по каждой операции, а не в конце месяца).
Зачем скрывать названия ИИ-моделей за тирами?
Имена моделей меняются каждый квартал, и привязка UI к ним создаёт постоянные миграции и путаницу у пользователей. Тиры (Low/Medium/High/Ultra) описывают стабильное обещание - баланс скорости, качества и цены - и позволяют платформе менять модели под капотом без изменений для клиента.
Что даёт White Label модель SaaS-платформе?
Партнёрский канал продаж без затрат на привлечение: агентства и интеграторы продают продукт под своим брендом со своим доменом и логотипом, а платформа получает объём подписок. Ключевые инженерные задачи - изоляция клиентов по партнёрам, динамический брендинг и корректная работа авторизации на чужих доменах.
Стоит ли делать редизайн сайта быстро или тщательно?
Скорость итераций и качество результата - не противоположности. Быстрые итерации в коде (версия в день) эффективнее недель в макетах: вы смотрите на реальный продукт. Но выкат должен проходить через ворота: performance-метрики, мобильная версия, базовое SEO. Быстро итерируйся, медленно выкатывай.
