Интро

Меня зовут Михаил, я frontend разработчик и занимаюсь менторством. Одним из самых частых запросов от учеников является подготовка к техническому интервью, поэтому я и решил создать продукт именно на эту тему.

В этой статье я расскажу:

как родилась идея
какие найдены варианты решения
что за проблемы возникли в ходе реализации MVP
какие подводные камни скрываются за найденными решениями
как я обходил ограничения.

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

В этой статье не будет:

продаж
лишних технических деталей

Предыстория

Классическая схема подготовки менти следующая:

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

Одно мок интервью по времени занимает 1-1,5 часа. Моя задача на каждой встрече — не просто задавать вопросы, но и обсуждать с учеником его ответы.

Объясняю я по памяти, то есть у меня нет заготовленных материалов для переиспользования. Если нужно — рисую схемы в моменте. Из раза в раз я задаю одни и те же вопросы и рассказываю одно и то же.

У данного подхода есть очевидные недостатки:

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

Идея

Так я и пришел к мысли о необходимости создания своей базы вопросов на интервью и их разборов.

Формат каждого разбора я придумал следующий:

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

Создание контента

Для создания большого количества контента требуется подходящий инструмент.

Я выбрал Notion, потому что:

имеются все базовые блоки разметки контента
есть возможность публикации контента в сети
мне нравится дизайн-система
есть возможность экспорта контента в html/markdown формате (на случай миграции)
Пример карточки

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

Конкуренты

Сперва я начал с анализа уже готовых решений на рынке. Мои основные конкуренты:

платформа https://solvit.space/
платформа http://yeahub.ru/
платформа itbooster.ru (релиз произошел совсем недавно)
другие менторы.

Конкуренция высокая, напрашиваются 2 вывода:

есть предложения, значит есть спрос
ставку следует делать ставку на уникальное позиционирование.

На первый взгляд ниша кажется уже занятой, а конкуренты слишком мощными, однако большинство этих платформ реализованы по одному шаблону:

фокус на множество направлений одновременно (frontend, backend, QA…)
базы вопросов заполнены чем попало, и, как правило, вопросы абсолютно банальны. Таким образом создается видимость масштаба
присутствует доска объявлений с менторами. Базы вопросов как способ привелчения трафика на платформу для дальнейшей конвертации в услуги менторства
много сопутствующего функционала: чат боты, ИИ агенты, роудмапы развития, онлайн тренажеры, доступ к закрытому сообществу.

Позиция же моего продукта продукта иная:

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

Цели, задачи и ограничения

Следующий шаг — установить границы возможного. Исходя из личного опыта запусков продуктов я сформировал следующие принципы:

запуск MVP как можно скорее. Это позволяет быстро проверить гипотезу и сэкономить как время, так и ресурсы, не тратя их на убыточный проект
фокус на содержании, а не на обертке
грамотный сбор аналитики для корректных выводов
приемлемый для меня бюджет — 150$ (затраты на рекламу не входят в эту сумму).

Требования к техническому стеку:

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

Тестирование спроса

Стратегия тестирования спроса следующая:

1. Привлечение трафика на landing страницу
                     │
                     ▼
2. перевод пользователя в базу карточек, 
   часть из которых закрыта за paywall блоком
                     │
                     ▼
3. paywall страница с предложением купить полный доступ
                     │
                     ▼
4. страница для сбора контакта (email или telegram аккаунт)

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

Так как реальной оплаты нет, то моя цель — собрать контакты. Критерий успеха — 10-20 контактов. Достигнув этого порога, пойду разрабатывать продукт дальше.

В качестве первичной стратегии привлечения я выбрал прогревающие посты в LinkedIn (там целевая аудитория), а затем рекламу в нескольких frontend сообществах в телеграмме.

Способ I. Notion

Первоначально я думал справиться силами самого Notion, но его главный недостаток — отсутствие детальной аналитики и централизованного места ее анализа.

Можно посмотреть, сколько пользователей посетило твою страницу, но нельзя:

узнать, сколько пользователь провел времени на странице
составить воронку
добавить кастомные события
Пример аналитики Notion страницы

Поэтому пришлось искать другое решение.

Способ II. Fruition

Следующий найденный способ — Fruition. Это обвязка, позволяющая захостить ваш notion лендинг с помощью claudflare workers. Настраивается быстро (потратил около часа, включая покупку домена).

Структура моего проекта в notion:

root-page/
  topic-1/
    card-1.1/
    card-2.2/
 
  topic-2/
    card-2.1/
    card-2.2/
  
 ...

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

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

Способ III. Super.so

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

real-time обновление контента
встроенная аналитика
возможность подключить Google аналитику.

Единственный минус — платно. Несмотря на это, решил попробовать — не грех заплатить за инструмент, закрывающий твои боли и экономящий время.

В super.so есть trial тариф, позволяющий опубликовать 1 сайт. У меня же было 2: landing и сама база карточек.

Поэтому решил сделать следующую вложенность notion страниц, чтобы обойтись trial режимом:

landing/
  card-base/
    topic-1/
      card-1.1/

Проблема #1

И тут столкнулся с первыми проблемами:

приложение поддерживает 3 уровня вложенности включительно (фатально для меня)
на landing странице появляется ссылка на card-base страницу (это внутренний механизм notion, не критично, но портит эстетику).

Тогда я решил разнести основные страницы по разным teamspaces. Это позволит решить проблему с вложенностью, но зато придется платить больше, так как trial версия позволяет иметь лишь 1 активный сайт.

Teamspace: landing
landing/

Teamspace: Demo
card-base/
  topic-1/
    card-1.1/

Отлично, сайты опубликованы, все работает. Но тут всплывает другая проблема.

Проблема #2

Большинство заголовков моих тем и карточек написаны кириллицей. Пример: “Какие виды тестирования бывают?”.

Superso автоматически создает роутинг и slug для путей, исходя из заголовков страниц, вырезая все не латинские символы. Если заголовок страницы не содержит ни одного латинского символа, то путь до страницы выглядит примерно так:

/--29ae3422cca481cab858d78c98fd4fa4

Не годится. Это помешает мне анализировать статистику, потому что придется маппить id страниц на адекватные имена.

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

Тогда я придумал обходной путь, решив вшивать slug прямо в названия страниц. Выглядит не слишком привлекательно, но зато решает проблему:

Какие  виды тестирования существуют? [tests-types]
Что такое HTTPS? Чем отличается от обычного HTTP? [what-is-https]
...

Тогда superso брал единственные латинские символы и делал из них путь до страницы. Таким образом это позволило бы мне легко в аналитике идентифицировать страницу.

Проблема #3

Настало время аналитики. Чтобы подключить аналитику к 1 сайту, нужно ежемесячно отваливать 10$. В моем случае — 20$. Жирно, но я уже начал работу и решил довести дело до конца.

Оказалось, что встроенная аналитика в superso крайне примитивна. Одна из самых больших проблем в том, что она собирается не на основании уникальных пользовательских сессий, то есть один пользователь может сгенерировать кучу событий, и пойди разбери сколько в итоге к тебе людей зашло. Теоретически, по косвенным признакам все же можно понять, сколько было уникальных пользователей (тип устройства, страна), но это лишняя головная боль, потому что кол-во уникальных пользователей — это одна таблица, а самые посещаемые страницы — другая.

Плюс здесь нельзя строить интересующие тебя отчеты и использовать кастомные события.

Подлючение google аналити��и мне не помогло. Собираются стандартные события, из которых воронку не построишь.

В итоге я набрал кучу проблем, аналитики толком нет, смотрю на итоговый месячный ценник 32-40$ ($12 за сайт, 20$ за бесполезную аналитику, и что-то еще в счет мне докинули, сейчас не помню) и понимаю, что это не мой вариант.

Способ IV. nextjs-notion-starter-kit (NNST)

https://github.com/transitive-bullshit/nextjs-notion-starter-kit

Нашел opensource обвязку над notion, использующую nextjs фреймворк. Автор решения писал ее для себя, чтобы захостить свой notion-based блог.

Парадигма такая:

Notion как CMS
NNST как рендерер с возможностью кастомизации.

Скачал, покрутил-повертел и понял, что большинство моих главных хотелок закрывается данным инструментом:

Notion как CMS
простой деплой с помощью vercel (бесплатный)
могу подключить любой инструмент аналитики и создавать любые события
могу создавать неограниченное число кастомных страниц (пригодилось для создания paywall страницы и страницы сбора лидов).

Для себя выделил следующие негативные моменты:

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

Важный нюанс: для аналитики мне важно разделять темы и карточки. Карточка не может содержать вложенную страницу, а тема — может.

Сущность notion страницы (в ответе от notion api) содержит лишь косвенные признаки, по которым я могу определить тема это или нет. Изначально для тем я добавлял специфичный префикс:

Тестирование [t-tests]
Сеть [t-network]
...

Соответственно, в коде по символу “t” в теге я понимал, что это именно тема.

Поскольку тегирование нужно было сугубо для решения на базе superso, то я от них вообще избавился. А проблему с идентификацией тем решил с помощью хардкода коллекции в приложении.

const TOPICS_LIST = new Set([
  'React',
  'Сеть',
  'Безопасность',
  'State managers',
  'JavaScript',
  'TypeScript',
  'Архитектура',
  'Тестирование',
  'Инженерные практики',
  'Troubleshooting',
  'Надежность, эксплуатация, наблюдаемость',
  'Тестовые задания'
])

export function parseContentMeta(rawTitle: string): ContentMeta {
  // ...

  const topicMatch = TOPICS_LIST.has(rawTitle)

  if (!topicMatch) {
    return {
      contentType: 'card',
      title: rawTitle,
      topicKey: null
    }
  }

  return {
    contentType: 'topic',
    title: rawTitle,
    topicKey: rawTitle
  }
}

Аналитика

В качестве системы аналитики я взял GA4. До этого никогда с ним плотно не работал, использовал ЯндексМетрику, но в ней не хватало гибкости.

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

В коде NNST я наткнулся на интеграцию с инструментом аналитики Posthog. До этого с ним не сталкивался и решил дать ему шанс.

Настроив все за 10 минут, я стал слать события как в Posthog, так и в GA4. И мне Posthog зашел:

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

Чтобы получить больше опыта и шире возможности, я оставил оба инструмента — карман не трет.

Метрики и отчеты

Для себя я выделил следующие ключевые метрики и отчеты.

Топы:

сколько лидов принесла каждая карточка + источник лида (tg/email)
топ поисковых запросов
топ просмотренных карточек
топ просмотренных тем.

Retention:

тем
карточек.

Конверсии:

topic → card → CTA → paywall → lead
какие карточки лучше доводят до paywall.

Продвижение

Решил начать с серии прогревающих постов в LinkedIn и посмотреть на отклик. Выбрал LinkedIn, потому что:

это бесплатно
высокая концентрация целевой аудиториию.

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

Далее найду тематичные группы в telegram и закажу рекламу там.

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

Итак

В итоге у меня получился не «идеальный продукт», а рабочий MVP с аналитикой и понятными метриками.

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

Если вам откликается подход — сложные вопросы, разборы без воды и фокус на понимание, а не заучивание — буду рад фидбэку.

👉 sobesin.vercel.app

Любые комментарии, замечания и критика приветствуются — именно ради них MVP и запускался.

Спасибо, что дочитали до конца. С удовольствием отвечу на все вопросы.

Notion как CMS для MVP: мой опыт, ошибки и подводные камни