Как я построил маркетинговую экосистему без найма: 5 продуктов, 1 человек

2026-07-14 07:01:21 Время чтения 8 мин 41

Полтора года назад у меня не было ни одной строчки кода, написанной мной самим, ни одного продукта, который я мог бы назвать своим. Была экспертиза в маркетинге - 13, на тот момент, лет, от SEO-специалиста до CMO-уровня в компаниях вроде Auslogics и Bitrix24 - и желание построить что-то без привычной модели "найми команду, подними раунд, масштабируйся".

Сейчас у меня 5 работающих проектов: сервис мониторинга видимости в AI-поиске (AI Presence), инструмент SEO-автоматизации (SEO Templates), энциклопедия интернет-маркетинга на 3500+ статей (MarketWiki), личный блог - рабочая лаборатория и Telegram-канал. Все они связаны между собой, и всё это делаю я один.

Расскажу, как это устроено и почему я выбрал именно такой путь.

Почему без найма?

Первая причина честная: у меня не было бюджета на команду. Я в процессе долгого поиска работы, и параллельно нужно было создавать что-то, что приносит деньги и доказывает компетенции.

Вторая причина стратегическая: найм - это не только зарплата. Это, неизбежно, ещё и время на подбор, онбординг, управление, разногласия по приоритетам. На старте, когда продукт ещё не нашёл рынок, это время лучше тратить на сам продукт.

Третья причина - то, что я называю подходом "сначала дело!". Я исходил из вопроса: что из того, что обычно делает команда из 5 человек, реально можно закрыть автоматизацией и правильно выстроенными процессами, а уже потом создавать полновесную команду? Ответ оказался - на пером этапе абсолютно всё.

Как устроена архитектура?

Я не строил пять изолированных проектов. Я строил систему, где каждая часть усиливает остальные.

AI Presence - основной коммерческий продукт. Он анализирует, как бренды выглядят в ответах ChatGPT, Perplexity, Claude и других AI-систем, и даёт рекомендации по улучшению видимости.

SEO Templates - второй продукт, построенный на той же технической архитектуре, что и AI Presence, только для более узкой задачи (генерация SEO-заголовков). Я сделал его, переиспользуя 80% инфраструктуры первого продукта - то же WooCommerce-решение, тот же паттерн интеграции с AI, тот же подход к обработке заказов.

MarketWiki - энциклопедия интернет-маркетинга на MediaWiki. Формально это отдельный некоммерческий проект. По факту - источник трафика и авторитета, который поддерживает оба продукта через внутренние ссылки и демонстрирует экспертизу.

Личный блог и Telegram - слой личного бренда. Здесь я публикую размышления, кейсы, разборы - то, что нельзя написать в продуктовом блоге, потому что это слишком личное или спорное для официального тона компании.

Большая часть материалов, которые я пишу, проектируется сразу под несколько каналов. Статья в блоге превращается в 3-5 постов для Telegram, в комментарии под чужими постами, в питчи для подкастов. Практически ничего не создаётся один раз для одного канала.

Технический стек, который это тянет

Ядро - связка из no-code инструментов для управления заказами и оркестрации сценариев, поверх которой работает собственная логика на PHP. Когда клиент оформляет заказ на AI Presence, срабатывает цепочка: валидация домена, запрос к нескольким внешним сервисам для сбора данных, потом - отладка и генерация отчёта, 1 затем - конвертация в читаемый формат, и финально отправка на почту. Всё без моего ручного участия - кроме одного тарифа, где часть работы всё ещё делаю сам.

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

Для MarketWiki пришлось разбираться с MediaWiki - движком, на котором работает Wikipedia. Там я столкнулся с задачами, для которых нет готовых решений:

  1. Скрыть кнопку редактирования для неавторизованных посетителей, но оставить её для админов.
  2. Починить рендеринг таблиц в теме.
  3. Включить другую тему для мобильных устройств, а затем настроить автосвитч.
  4. Реструктурировать 856 категорий в логичную систему из 14 тематических разделов

Каждую задачу такого рода я решал через прямое погружение в код и документацию движка.

Что оказалось сложнее всего?

Как ни удивительно, это не техническая часть. Самым сложным оказалось удержать целостность системы, когда работаешь один.

Ведь когда у тебя есть команда, дизайнер спорит с разработчиком, маркетолог спорит со стратегом - и в этом трении рождается более устойчивое решение. Когда решения принимает один человек, легко скатиться либо в перфекционизм (бесконечно дорабатывать один элемент), либо в противоположность - делать поверхностно, потому что никто тебе не укажет на слабые точки.

Я решил эту проблему через жёсткую дисциплину по времени: фиксированный график, конкретные часы на конкретные задачи, регулярный пересмотр приоритетов по факту метрик, а не по ощущениям. Это не заменяет команду полностью, но снижает риск потеряться в собственных решениях.

Что я узнал о масштабировании без людей?

Первое: автоматизация ещё не означает "автоматизировать всё". Некоторые вещи - стратегические решения, тон коммуникации, приоритизация - должны оставаться ручными. Автоматизация хороша там, где процесс повторяем и предсказуем.

Второе: экосистема сильнее суммы частей, только если части действительно связаны. 5 изолированных проектов - это 5  источников усталости. 5 связанных проектов, где контент и трафик перетекают между ними - это система с нарастающей эффективностью.

Третье: одному человеку доступен масштаб, немыслимый десять лет назад, но не безграничный. Я не строю следующий Bitrix24 в одиночку. Вместо этого создаю нишевые продукты с конкретной аудиторией, где глубокая экспертиза гораздо важнее размера команды.

Стоит ли повторять этот путь?

Если у вас есть глубокая экспертиза в узкой области и время - однозначно да, стоит попробовать. Инструменты для этого сейчас доступны как никогда: ИИ снимает часть технической и контентной нагрузки, no-code решения вроде Make.com закрывают оркестрацию без найма разработчика.

Если вы рассчитываете на быстрый взрывной рост - этот путь не для вас. Он медленнее, чем путь с командой и инвестициями. Но он даёт то, чего не даёт венчурная модель: полный контроль над продуктом и возможность проверить гипотезу без чужих денег и чужих ожиданий.

Я выбрал такой подход не из-за того, что он оптимален во всех случаях. В моей ситуации - между работами, с большим опытом и ограниченным бюджетом - он оказался единственным реалистичным способом создать что-то своё, пока идёт поиск следующей роли. И в итоге я "втянулся" и останавливаться не хочу.