Вайбкодинг школы на Next.js + Supabase с Resend
Как сделать email "частью продукта" в вайбкодинг школе: подключение Resend к Next.js + Supabase для транзакционных писем, событий доставки и учебного процесса. Практика с bolt.new и Cursor AI.
Как сделать email "частью продукта" в связке bolt.new и Cursor AI (без кода, по-человечески)
Когда вы делаете школу на Next.js + Supabase, email — это не "рассылка", а нервная система продукта. Он подтверждает, что пользователь реальный, что оплата прошла, что доступ к уроку открыт, что дедлайн приближается, что домашка проверена. Если письма не доходят — продукт выглядит сломанным, даже если код идеален.
Resend — сервис, который помогает построить email-контур по-современному: не через бесконечные SMTP-танцы, а через понятную панель, домены, DNS-аутентификацию и события доставки. В вайбкодинге это важно: вы быстро собираете рабочую версию (bolt.new), а затем превращаете её в устойчивую систему (Cursor AI).
Почему именно "вайбкодинг с Resend"
Вайбкодинг — это подход "быстро собрал → увидел сигнал → улучшил". В email-контуре сигнал — это не "настроение", а конкретика:
- письмо отправлено,
- доставлено,
- отбито (bounce),
- на него пожаловались (complaint).
Resend делает эти статусы наблюдаемыми. И это ключевой момент: вы перестаёте гадать "почему студент не получил письмо" и начинаете видеть факты.
Где в этой картине Next.js, Supabase, bolt.new и Cursor AI
Чтобы не смешивать роли:
- Next.js — ваш продукт: лендинги, кабинет, уроки, оплаты, интерфейсы.
- Supabase — база данных + аутентификация (логин/регистрация) + хранение данных.
- Resend — почтовый слой: отправка писем и контроль доставки.
- bolt.new — ускоритель сборки: быстро развернуть MVP, связать блоки.
- Cursor AI — усилитель качества: правила, порядок, безопасность, "не развалится через месяц".
Два типа писем в школе — и две разные стратегии
1) Auth-письма (логин/регистрация/сброс пароля)
Эти письма часто отправляет сама система авторизации. В вашем случае — Supabase Auth. Логика простая: Supabase должен уметь отправлять "подтвердите email" и "reset password".
Правильная стратегия для начинающих: подключить Resend как SMTP-провайдера для Supabase.
То есть Supabase продолжает отправлять системные письма, но делает это через Resend — с вашим доменом и нормальной доставляемостью.
2) Продуктовые письма (уроки/дедлайны/домашка/сертификат)
Это то, что делает школу "живой": уведомления и поддержка учебного процесса. Эти письма лучше отправлять из вашего приложения (Next.js), потому что у вас больше свободы по смыслу, дизайну и событиям.
Самое важное: домен и DNS — "паспорт доверия" для ваших писем
Большинство проблем начинающих не в тексте письма и не в сервисе. Проблема в том, что письмо выглядит для почтовых систем как подозрительное. Чтобы оно выглядело "официальным", нужен базовый набор DNS-настроек:
- SPF — разрешает сервису отправлять от имени вашего домена.
- DKIM — ставит криптоподпись, доказывая, что письмо не подделано.
- DMARC — задаёт правила: что делать, если SPF/DKIM не сошлись.
Идея вайбкодинга тут в том, что вы не спорите с реальностью: пока SPF/DKIM не настроены, любая "красота письма" — косметика.
Практика для школы: отдельный сабдомен
Чтобы защитить репутацию основного домена сайта, почти всегда лучше отправлять с сабдомена:
- notifications.вашдомен — транзакционные и учебные уведомления
- updates.вашдомен — новости и апдейты (если появятся массовые рассылки)
Это снижает риск "всё сломалось сразу", когда один тип писем портит репутацию другим.
bolt.new: как быстро собрать работающий email-контур
bolt.new хорош тем, что помогает собрать MVP без недельного "инфраструктурного болота". В контексте Resend и Supabase ваша цель в MVP проста:
- Auth-письма Supabase начинают уходить через Resend
- Продукт умеет отправлять хотя бы одно "продуктовое" письмо (например, "доступ открыт")
- Вы видите в панели Resend, что происходит с доставкой
На этом этапе главное — не усложнять: один домен, базовые DNS записи, один тип продуктового письма.
Cursor AI: превращаем "оно работает" в "оно безопасно и поддерживаемо"
Cursor нужен не для того, чтобы "писать больше кода", а чтобы закрепить правила, которые начинающие часто нарушают:
- секреты (ключи) не должны утекать
- отправка письма должна происходить только на серверной стороне, а не из браузера
- события доставки должны быть проверяемыми и не подделываемыми
- система должна быть устойчивой к повторным событиям (в реальном мире одно и то же событие может приходить несколько раз)
Если сказать по-вайбкодинговому: Cursor помогает сделать так, чтобы "ускорение" не превратилось в "хаос".
События доставки: ваш "датчик качества" обучения
Вот что отличает зрелый продукт от "у нас письма как-то отправляются":
- если письмо доставлено, а студент говорит "не видел" — проблема уже не в доставке (возможно, фильтры, вкладки, невнимательность, неверный адрес).
- если письмо bounce — адрес плохой, нужно попросить обновить email и не портить репутацию домена.
- если complaint — это красная лампа: такие адреса нужно исключать из отправки немедленно.
В школе это практично: вы не спорите, вы действуете по фактам.
"Чистота базы" — главный секрет доставляемости для новичков
Сервисы любят рассказывать про "магические алгоритмы доставляемости". Реальность проще и жестче:
- не шлите на несуществующие адреса,
- уважайте отписку,
- не долбите человека письмами "по привычке",
- не смешивайте транзакционные письма с массовыми рассылками.
Если вы делаете школу в долгую, репутация домена — актив уровня платежной системы.
Какие письма реально нужны школе (минимальный набор)
Чтобы не утонуть, начните с короткого списка, который ощутимо улучшает продукт:
Auth (обычно через Supabase):
- подтверждение email
- сброс пароля
Продукт (через Resend API):
- "доступ открыт" (после оплаты/регистрации)
- "урок открыт"
- "дедлайн через 24 часа"
- "домашка проверена"
- "сертификат готов"
- "один вопрос фидбека" (в конце модуля)
Правило качества: одно письмо — одно действие.
Если письмо делает три вещи сразу, студент чаще всего не делает ни одной.
Чек-лист: когда можно считать, что email-контур "встал"
✓ Вы отправляете письма с отдельного сабдомена (например, notifications…)
✓ SPF и DKIM настроены и подтверждены в Resend
✓ DMARC включён хотя бы в мягком режиме наблюдения
✓ Supabase Auth отправляет системные письма через Resend (custom SMTP)
✓ В Resend видны статусы доставки
✓ Есть правило: bounce/complaint → адрес больше не получает письма
✓ Есть минимум продуктовых писем (не меньше 3–5), которые улучшают учебный цикл
Что будет следующим шагом (когда школа вырастет)
Когда появятся дедлайны, автоповторные напоминания, массовые потоки и разные сегменты студентов, почти неизбежно придёте к:
- разделению потоков на "транзакционные" и "обновления"
- системной очереди на отправку (чтобы ретраить и не терять события)
- аналитике "какие письма реально помогают обучению"
Но это уже следующий уровень. Для вайбкодинга важно другое: сначала сделать устойчивый базовый контур, который не стыдно масштабировать.

