SaaS · SEO
Задача: школа не видит, что творится у конкурентов с ценами
Ко мне пришёл запрос от онлайн-школы: у них систематически «утекали» продажи в моменты, когда конкурент запускал скидку или менял цену на похожий курс. Отдел маркетинга узнавал об этом постфактум — через две недели, когда уже видно проседание в конверсии. Ручной мониторинг был: раз в неделю кто-то открывал десяток сайтов конкурентов и переписывал цены в таблицу. Занимало полдня, обновлялось редко, ошибки были нормой.
Идея простая: сделать SaaS, который сам ходит по страницам курсов конкурентов, вытаскивает цену и присылает уведомление, если она изменилась. Задача не «построить платформу мониторинга рынка», а закрыть конкретную боль: увидеть изменение цены раньше, чем это увидят клиенты, у которых упадёт конверсия.
Развилка: писать свой парсер или купить готовый скрейпинг
Первое архитектурное решение — и оно же оказалось главным на весь проект — как получать HTML страниц конкурентов. Очевидный путь: поднять Playwright, написать headless-браузер, который заходит на страницу и парсит DOM. Так делает каждый, кто хоть раз писал скрейпер.
Я сознательно от этого отказался ещё на этапе MVP. Причина — не в сложности написания самого скрипта, там пара часов работы. Проблема в том, что происходит после первого релиза: сайты конкурентов защищены от ботов по-разному, у кого-то Cloudflare-челлендж, у кого-то капча при частых запросах, у кого-то верстка меняется раз в месяц и парсер молча начинает возвращать пустоту. Свой парсер на Playwright — это не разовая задача, это открытая война на выживание: нужны ротация прокси, обход антибот-защиты, мониторинг падений парсинга, поддержка под каждый новый сайт. Для одного разработчика, который должен ещё и сделать интерфейс, базу и биллинг, это съедает всё время.
Инсайт
На старте продукта вопрос не «как мне спарсить страницу», а «сколько часов в неделю я готов тратить на то, чтобы парсер просто продолжал работать». Свой Playwright отвечает на первый вопрос за пару часов и на второй — бесконечным количеством часов каждую последующую неделю.
Вместо своего парсера я взял Firecrawl — API, который на входе получает URL, а на выходе отдаёт очищенный контент страницы: без рекламных скриптов, без вёрстки, без необходимости самому разбираться, как обойти защиту конкретного сайта. Firecrawl берёт на себя рендеринг JS, обход большей части антибот-механизмов и стабильность выдачи. Моя задача сузилась до одной вещи: из чистого текста страницы вытащить число — цену курса.
Как собран продукт: три сервиса вместо одного самописного стека
Дальше архитектура выстроилась вокруг того же принципа — не строить то, что уже продаётся как сервис.
Next.js
приложение и интерфейс отслеживания цен
Supabase
база данных и авторизация пользователей «из коробки»
Firecrawl
движок скрейпинга конкурентных страниц
Next.js закрывает и фронт, и серверную логику — там, где раньше пришлось бы держать отдельный бэкенд, здесь достаточно API-роутов внутри того же приложения. Supabase закрывает сразу две задачи, которые обычно съедают недели в начале проекта: хранение данных (список отслеживаемых курсов, история цен, уведомления) и авторизацию пользователей — регистрацию школ, сессии, разграничение доступа. Ничего из этого не пришлось писать руками.
Сам цикл мониторинга получился короткий:
- Школа добавляет ссылку. В интерфейсе школа указывает страницу курса конкурента, за которой нужно следить.
- Firecrawl забирает контент. По расписанию приложение дёргает Firecrawl API по сохранённым URL и получает чистый текст страницы.
- Из текста вытаскивается цена. Простая логика разбора текста находит цену курса и записывает её в Supabase с меткой времени.
- Сравнение с прошлым значением. Если цена отличается от последней сохранённой — фиксируется изменение.
- Школа получает уведомление. Об изменении цены сообщается сразу, а не через две недели постфактум.
Ключевое здесь — сколько кода вообще не пришлось писать. Не было ни одной строчки для рендеринга браузера, обхода защиты, управления прокси, хранения сессий пользователей или проверки паролей. Всё это — чужая ответственность, оплаченная через API-запросы.
Результат: рабочий SaaS в одиночку и в разумные сроки
Итог — работающий продукт, который решает исходную боль: школа видит изменение цены конкурента практически сразу, а не когда уже упали продажи. Собран он одним человеком с помощью вайбкодинга, без команды разработки под парсинг, без отдельного инженера по антибот-обходу, без DevOps под свою базу данных.
Важно понимать, чего в этом MVP нет: нет своей инфраструктуры для скрейпинга, нет своего решения для авторизации, нет ручного администрирования базы. Это осознанный выбор границ на старте, а не недоработка. Если завтра выяснится, что Firecrawl не тянет объём или не справляется с каким-то конкретным сайтом конкурента — это станет задачей для решения, когда продукт уже подтвердил спрос. Не раньше.
Урок: на MVP покупай инфраструктуру, а не строй
Главный вывод из этого проекта простой и универсальный для любого MVP: на этапе проверки гипотезы скорость важнее «правильной» инженерии. Собственный парсер, своя система авторизации, своя база данных с нуля — всё это звучит как «более надёжное» решение, но на деле это отложенная на недели проверка того, нужен ли продукт вообще кому-то.
Скрейпинг, база данных, авторизация — в 2026 году это не то, что отличает продукт от конкурентов. Это то, что можно и нужно купить через API, чтобы освободить время на то, что действительно отличает: понимание боли клиента и скорость итераций.
Firecrawl вместо своего Playwright, Supabase вместо своей базы и системы логина — это не компромисс в качестве продукта, это разница между «запустил MVP за дни» и «полгода строил инфраструктуру, которая никому ещё не доказала, что нужна». Свой велосипед для скрейпинга или авторизации стоит строить только тогда, когда продукт уже взлетел, объёмы выросли настолько, что готовые API стали дороже собственной разработки, и у вас уже есть данные, а не гипотеза, ради которой всё это затевалось.