Как я за месяц создал 5 SEO-инструментов и дважды чуть не опозорился на старте

В июне этого года у меня уже было 2 полноценных продукта: AI Presence - сервис, который проверяет, что о бренде знают и говорят ChatGPT, Perplexity и другие нейросети, и CMO Analytics - инструменты для аналитики и отчётности маркетинг-директоров. Руки чесались сделать третий. Так появился набор из 5 SEO-инструментов для малого бизнеса: генератор Title и Description, генератор FAQ, аудит по критериям E-E-A-T, анализатор структуры сайта, парсер конкурентов.

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

Плюс - бесплатные шаблоны на разные случаи, которые возникают в работе SEO-специалиста / вебмастера.

От первой строчки до запуска - 25-30 дней, по 2-4 часа в день, без выходных как таковых, но и без геройства. Технические детали архитектуры оставлю за скобками - не потому что стесняюсь, а потому что расскажу про другое: два раза за этот месяц я реально мог опозориться, и оба раза спасло только то, что тестировал сам, руками, как обычный пользователь. Плана как такового не было

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

Уведомления с готовым результатом либо тонули в спаме, либо доходили - но пустые. Заголовок есть, тело письма - ничего.Заметил это не потому что кто-то пожаловался (продукт ещё даже не запустился), а потому что тестировал себя же: оформил заказ ровно так, как это сделал бы клиент, и полез проверять почту. Если бы я просто пробежался глазами по коду - скорее всего, ничего бы не заметил. С точки зрения кода письмо честно отправлялось, просто внутри было пусто.

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

Он был неприятнее, потому что вылез не во время целенаправленного тестирования, а уже после того, как я мысленно посчитал (наивно), что всё готово.

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

То есть буквально там была целая махина кода, начиналась она со строки:

<?php echo $product_name; ?>

Дальше больше. Вместо кнопки «Оплатить»:

<?php $price = get_price($product_id); ?>

Весь исходник страницы лежал как открытая книга. Любой посетитель мог увидеть названия переменных, логику запросов к базе - и самое страшное, что это выглядело не как сбой, а как будто я специально выложил в общий доступ свой «черновик». Я обновил страницу. Кэш? Нет. Очистил кэш браузера - тот же результат. Зашёл с телефона через мобильный интернет, увидел всё то же самое. Сердце ушло в пятки.

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

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

QA-отдела у меня, понятное дело, нет. Поэтому единственный рабочий способ поймать проблему до пользователя это самому пройти весь путь от начала до конца, без скидок на "я и так знаю, как это должно работать".Именно так поймались оба косяка. Не код-ревью (кому его делать, если ты один), а буквально повторение действий постороннего человека: выбрать нишу, заполнить форму, оплатить, дождаться письма, открыть его.

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

Меня спрашивали потом несколько раз: какой из 5 дался тяжелее всего? Ждали, наверное, историю про один особенно проклятый компонент. Но только вот на самом деле мне все инструменты примерно одинаково.

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

У меня все 5 используют одну и ту же базовую логику обработки заказа и генерации результата, различаясь только содержанием - какие данные тянуть под какую нишу. Основу я строил 1 раз, довольно медленно и внимательно, и остальные 4 легли на неё почти без трения.Осознанным планом это не было - скорее повезло, что первый инструмент делал не торопясь, и заложенная структура оказалась достаточно универсальной.

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

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

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

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