Когда я начала делать CaseSociety, я не ставила себе цель стать разработчиком. Мне нужно было другое — самой довести идею до работающего продукта.

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

1. Понимать, как продукт устроен технически

Сейчас CaseSociety — это статический сайт на Cloudflare Pages. Статьи блога хранятся в базе данных Supabase, а специальный скрипт сборки превращает каждую запись в отдельную страницу и обновляет карту сайта для поисковиков.

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

Чему научилась: прежде чем сказать «готово», проследить путь данных от кнопки до страницы, которую увидит пользователь.

2. Git и деплой — это страховка, а не формальность

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

Это спасло меня совсем недавно. Я выложила новую главную, но скопировала не тот файл — старую версию из папки «Загрузки». На сайте пропали свежие ссылки и блоки. Вместо паники хватило одной команды, чтобы вернуть файлы к предыдущему коммиту, и ещё одной, чтобы выложить сайт заново.

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

Чему научилась: коммит — это кнопка «отменить» для всего продукта. И проверять, что именно уходит на сайт, до того, как оно туда ушло.

3. Работать с данными, а не только с интерфейсом

У статей в базе есть поля: заголовок, адрес страницы, категория, текст, статус «черновик» или «опубликовано». Когда понимаешь эту структуру, многое становится проще.

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

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

Чему научилась: смотреть на продукт как на данные и действия над ними. И относиться к ключам доступа как к паролю от всего бизнеса.

4. Сначала план, потом изменения

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

Так я чинила ссылки по всему сайту. Скрипт проверки прошёл по 29 страницам и 347 ссылкам и нашёл 7 битых: часть вела на старые адреса статей, а в одной вместо ссылки стояла забытая заглушка «ССЫЛКА». Сначала — план правок, потом исправление, потом повторная проверка, что битых ссылок ноль.

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

Чему научилась: «сначала посмотреть, что будет, потом сделать» — это тот же discovery, только для кода.

5. Сделать так, чтобы продукт находили

Сайт, которого нет в поиске, почти не существует. Поэтому пришлось разобраться в технической базе SEO: карта сайта, подключение Google Search Console, Яндекс Вебмастера и Bing, отправка новых страниц через IndexNow — протокол, который сообщает поисковикам об изменениях за минуты, а не недели.

Когда я объединяла статьи в одно руководство, важно было не потерять старые адреса, которые уже попали в поиск. Для этого я настроила постоянные перенаправления: кто откроет старую статью, попадёт на новое руководство.

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

6. Проверять, что данные вообще собираются

Несколько дней Яндекс Метрика показывала ноль посещений. Можно было сделать вывод, что на сайт никто не заходит. На деле в настройках стоял пустой фильтр, который отсекал все визиты.

Чему научилась: прежде чем делать выводы из цифр, убедиться, что цифры вообще собираются.

7. Исправил одно — проверь всё остальное

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

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

Чему научилась: после любой правки проверять и телефон, и компьютер, и соседние страницы. А если «ничего не поменялось» — сначала обновить страницу без кэша.

8. И главное — техническое мышление

Наверное, именно это я забрала из разработки больше всего. Любую идею теперь раскладываю так:

что должно произойти → какие данные для этого нужны → где они хранятся → какие условия должны выполниться → как это проверить → какой результат получит пользователь.

По сути, это очень продуктовый способ мышления — просто доведённый до конкретики.

Вместо вывода

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

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

CaseSociety стал для меня таким полигоном. Не просто pet-project, а местом, где я одновременно проверяю продуктовые гипотезы, учусь строить бизнес и прокачиваю техническую сторону продукта.

Хотите так же прокачать продуктовое мышление на практике? В кейс-клубе CaseSociety за 2 недели в команде собираем продуктовый кейс — от проблемы до решения и метрик.