Главная мысль: продукт легко, а вот вес — нет
Роман начинает с шутки, которую сам же скинул в чат эфира: вайб-кодеры напоминают мужиков, впервые научившихся готовить, — «пока не встретил ни одного, кто на домашней кухне приготовил бы то, что захотел бы есть кто-то ещё».
Свою платформу он считает частичным опровержением этой шутки. Но тут же ставит главную оговорку всего доклада, и она важнее технической части.
Создавать продукты легко и просто. Но без какого-либо маркетинга или, как в случае с «Тупиком», без накопленного личного бренда, личного веса в маркетинговой среде, платформа бы не выстрелила.
Он подкрепляет это наблюдением с площадок вроде Product Radar: стартапов огромное количество, 80% из них про ИИ, и проблема каждого одна — он решает одну конкретную задачу того человека, который его придумал. «Тупик» же решал сразу несколько: задачу Романа как исполнителя GEO, задачи его клиентов и задачу авторов, которым нужно место для публикаций.
Зачем вообще нужна ещё одна площадка
Логика простая. GEO Роман считает не продолжением SEO, а контент-маркетингом — а для контент-маркетинга нужны две вещи: хороший контент и место, где его размещать.
Места он собирал вручную: Хабр, VC, Пикабу, РБК, «Состав», Cossa, SEO-новости, Дзен, соцсети. У каждой площадки свои форматы, свои требования, где-то жёсткая редактура, где-то публикация только через редакцию. Плюс цены на размещение растут, а хорошие авторы с части площадок уходят.
Отсюда идея: сделать собственный сайт, полностью подконтрольный, где можно размещать и рекламные статьи, и ссылки, — и заодно подхватить тех самых уходящих авторов.
Работает это через консенсус: недостаточно вести блог на своём сайте и карточку на картах. Нужно, чтобы примерно одинаковый по смыслу контент лежал на 3–4 разных площадках — только тогда нейросеть начинает ему доверять.
Создание ещё одной площадки просто позволяет замкнуть эту историю консенсуса и разместить как можно больше статей.
При этом Роман честно снимает завышенные ожидания: нейросети действительно забирают трафик у издателей, ссылки дают, но переходить не мотивируют. «Говорить о том, что я создаю свою собственную VC.ru и скоро стану им конкурентом, — точно нет». Цель платформы — попадание в ответы нейросетей, а не трафик.
Что нужно знать про GEO, прежде чем строить площадку
Два наблюдения из доклада стоят отдельного внимания, потому что меняют подход к контент-плану.
Первое: нейросеть всё равно разбивает промт на простые поисковые запросы. Какой бы сложный prompt ни ввёл пользователь — «сравни стоимость колоноскопии в пяти клиниках Екатеринбурга, отдельно покажи цену с наркозом» — в поиск улетают простые коммерческие и информационные запросы: стоимость колоноскопии, клиника Екатеринбурга, цены. Именно они и должны быть основой контент-плана, и берутся они из обычного Wordstat.
Второе: важна точность формулировок. Роман показывает на собственном примере: статья «Топ-25 полезных ботов Telegram» на Хабре стоит первой в Яндексе и попадает в ответы по запросу про боты-планировщики. Но по запросу «топ ботов в Telegram» смысловая релевантность уже другая — нейросеть считывает вопрос как «самые популярные боты вообще», и его источник для такого ответа недостоверен.
- Яндекс — через него ищет Алиса.
- Bing — на нём построен поиск ChatGPT.
- Google — источник для Gemini и AI Overviews.
- Brave — поисковик, которым пользуется Claude.
Это и было главной технической целью «Тупика»: одна площадка, где новая статья автоматически индексируется всеми четырьмя, вместо ручной прогонки каждой публикации по вебмастерам. Отдельный лайфхак Роман показывает на Brave: добавленная постранично страница попадает в ответы Claude в течение одного дня.
Результаты: свежий домен, плохой брендинг — и рост
Платформа запущена 14 мая на новорегистрированном домене. Роман специально перечисляет всё, что играло против: никакой истории домена, никакого прогретого бренда, объективно плохой брендинг — слово «тупик» само по себе не гуглится, — плюс формат UGC-портала.
Тем не менее сайт быстро проиндексировался. Первичный толчок был отчасти искусственным: Роман попросил знакомых и коллег разместить упоминания, поучаствовал в Product Radar. Дальше люди начали публиковать контент сами — и платформа стала появляться в ответах по вполне тематическим запросам.
Измеримый результат он показывает на кейсе продвижения одной digital-конференции: до начала работы площадки в источниках не было вообще, сейчас — 56 цитирований сайта в ответах разных нейросетей, причём в разных кластерах запросов: конференция для руководителей агентств, конференция по продвижению, конференция для маркетологов. Разные статьи влияют на разные ответы.
Инструменты: почему в итоге Cursor и обязательно GitLab
Здесь Роман честно рассказывает, что пропустил половину советов, которые сам же собирал вместе с коллегами-вайб-кодерами: как обучать нейроагента, скармливать ему свои данные, описывать структуру работы.
Я на это всё забил. Мне не нужно, чтобы нейросеть понимала мою душу — мне нужен был конечный результат.
Перебор инструментов вышел таким: сначала кодовый агент от OpenAI — «не зашло»; потом агент от Anthropic — «сожрал лимиты, как человек, дорвавшийся до воды после недели в пустыне»; в итоге остановился на Cursor, где расход лимитов на не самых интеллектуально сложных задачах его устроил. Общий вывод — мультисервисы, объединяющие под капотом несколько моделей, делают работу проще.
А вот два шага, которые он рекомендует настойчиво.
Подключить GitLab (или GitHub) с самого начала. По словам Романа, репозиторий неоднократно спас его от того, что агент перезаписывал файлы, стирал данные и уничтожал комментарии пользователей. Отдельная ловушка — работа с разных устройств: правка, сделанная с телефона, была затёрта файлом с компьютера, который «не знал» о ней.
Не делегировать нейросети регистрацию домена и хостинга. Технически модель может всё сделать сама, но Роман видел слишком много бизнесов, потерявших прибыль из-за того, что домен оказался зарегистрирован не на них. «Эти шаги пройдите, пожалуйста, сами».
Главные грабли: костыли, стили и пересекающиеся сущности
Сайт с нуля Роман делать не стал: взял готовую CMS с опытом работы на ресурсах с большой посещаемостью, поставил голую коробку и дальше доводил её вайб-кодингом.
И тут же совершил ошибку, которую называет главной: просто описывал модели, что хочет получить. Та реализовывала это кусками кода, игнорируя штатные возможности CMS и создавая дублирующие функции. Осознав это, Роман ввёл жёсткое правило.
Если ты что-то делаешь — в первую очередь идёшь и проверяешь штатные возможности моей CMS, исправляешь и дорабатываешь их. Если такой возможности нет — уже делаем костыль.
Цена этого урока измерима: файл стилей разросся до 3000 строк — «прям много для такого небольшого по дизайну сайта», — и потом его пришлось вычищать тем же вайб-кодингом. Полностью, признаёт он, не получилось. Отсюда же требование просить модель вписывать в код комментарии: что это, когда и куда.
Вторая крупная категория проблем — пересекающиеся сущности. Роман хотел показывать авторам статистику и запутался в собственных формулировках: показы, просмотры и охват слились в одну кашу. Потом выяснилось, что лента главной страницы, лента внутри категории и лента вертикальных видео — это тоже разные ленты, и всё это пришлось объединять.
Когда начинается пересечение нескольких сущностей, вам мало поставить задачу — надо сесть и самому сначала придумать эту систему.
Попытка поручить разбор нейросети закончилась предсказуемо: агент проанализировал файлы сайта, нашёл не все проблемы и потратил все лимиты. Вывод: нечётко сформулированная задача = перерасход лимитов плюс нерешённые задачи.
И ещё две вещи, которые Роман не советует вайб-кодить. Первая — юридические документы: пользовательское соглашение, политика обработки персональных данных, правила применения рекомендательных технологий. Причина техническая: около половины запросов модель гуглит по иностранным источникам, где мало информации об отечественной практике. Вторая — дизайн, но по другой логике: он сознательно отложил его до момента, когда проект выстрелит, потому что в начале невозможно предусмотреть весь функционал. Часть разделов вообще родилась из советов коллег и из собственной практики использования.
Продуктовая часть: почему одной кнопки «опубликовать» мало
Изначальный функционал был минимальный: зарегистрировался, нажал «Написать статью», заголовок, тематика, контент, публикация. Роман быстро понял, что так получится «просто блог на WordPress», куда никто не вернётся.
Поэтому он пошёл достраивать вовлечение, опираясь на свою аудиторию — у него есть чат спикеров на 300 человек.
Плюс еженедельный сбор мнений — формат, подсмотренный на пресс-площадках. Логика Романа: он ходил по рынку и смотрел, что заставит людей возвращаться, потому что видел множество хорошо сделанных платформ, куда люди просто не приходили второй раз.
Ваша задача — сделать такое место, где люди получали бы ценность ежедневно или хотя бы еженедельно, публикуя контент.
Самая интересная часть — MCP-страница для нейроагентов: инструкция, по которой агент понимает, где на платформе что лежит. Теперь статью, написанную в чате с моделью, не нужно копировать и вставлять вручную — достаточно сказать агенту разместить её от вашего имени. Токен создаётся в личном кабинете, и агент умеет всё: создать аккаунт, опубликовать и отредактировать статью с картинкой, создать мероприятие, подключить Telegram-канал для трансляции постов.
Через тот же механизм Роман замкнул и свою вторую бизнес-задачу: его сервис аналитики GEO генерирует контент-план, ТЗ и статью, а последним шагом публикует её на платформу в один клик — без перехода между сервисами. Ту же интеграцию сделал и его прямой конкурент.
Где вайб-кодинг заканчивается
Финальный вывод Роман формулирует без энтузиазма и потому убедительно: вайб-кодинг подходит для стартапов, быстрого старта и тестирования гипотез.
Пока уверенности в вайб-код-решениях у меня нет, когда речь пойдёт о сложном большом проекте.
Конкретный порог он называет сам: если через год посещаемость выйдет на уровень 100 тысяч переходов в неделю, платформу он, скорее всего, будет пересобирать — либо заново вайб-кодить, либо делать дорогую, но стабильную версию с программистами. Лишний код, по его опыту, накапливается неизбежно: он вычищал стили, потом садился разбираться вместе с программистом — и файл всё равно остался перегруженным.
Отдельно про память моделей: они очень быстро забывают договорённости, поэтому всё важное надо выносить в отдельные правила. Роман приводит бытовой пример — он «заманался» каждый раз объяснять, что правильно говорить «в Тупике», а не «на Тупике».
И последнее, что он повторяет дважды: пишите качественный контент. На финальном слайде — выкладка Google, где красным отмечено то, что не признано качественным и не попало в индекс, а зелёным — то, что попало.