Почему Resend часто берут вместо «просто SMTP» — и где на нём ломаются

Resend закрывает типичную боль: письма для продукта, а не для «почтового сервера в вакууме». У него удобный API, нормальная работа с шаблонами, webhooks по статусам и понятная интеграция в веб-приложение. Для транзакционных писем это обычно быстрее, чем поднимать свой SMTP-обвязку и потом разбираться с логами.

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

Ещё одна ошибка — не проверять idempotency и ретраи. При сбоях API письмо может уйти повторно, если приложение не защищено от дублей. И не забывайте про bounce/complaint события: без обработки webhooks список адресов быстро портится, а доставляемость падает 📩

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

Resend хорош не как «ещё один SMTP», а как быстрый слой для product email

Если у вас транзакционные письма, Resend обычно берут за три вещи: понятный API, нормальные шаблоны и минимум боли с интеграцией. Это удобно, когда письма нужны как часть продукта: регистрация, сброс пароля, уведомления, инвайты, чеки.

На практике смотреть стоит не на «фичи», а на операционку:
— есть ли отдельные домены и ключи под dev/stage/prod;
— как устроены webhooks и retry при сбоях;
— можно ли быстро проверить доставку, а не гадать по логам;
— насколько легко менять шаблоны без правок в бизнес-логике.

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

Ещё один важный фильтр — миграция с другого провайдера. Сначала проверьте, как переносится suppression list, как обрабатываются bounce/complaint и есть ли возможность параллельного прогона на тестовых доменах. Если этого нет, красивый API быстро превращается в дорогую точку отказа.

Итог простой: Resend имеет смысл там, где email — продуктовая функция, а не вспомогательная скрипт-рассылка. Перед выбором проверьте не маркетинг, а маршрут письма от триггера до inbox.

Vercel удобен, пока проект не начинает жить своей инфраструктурой

Vercel хорош для фронта, превью и быстрых деплоев: подключил репозиторий, получил build, preview и домен без лишней возни. Для лендингов, маркетинговых сайтов и Next.js-проектов это часто самый короткий путь до продакшена.

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

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

Если проект уже включает очереди, WebSocket, тяжёлую API-логику или много server-side вычислений, Vercel лучше считать витриной для фронта, а не местом, где держится вся система.

Лонгрид о мемном кейсе Melbet vs Pepper Partners - реально ли оценить в аффилейтке репутационный ущерб в деньгах?

История на $2,000 вряд ли разрушит крупный бренд. Но она вполне может стоить ему сотен тысяч долларов и более, если публично остаётся без внятного решения.

Я в аффилейт-маркетинге более 25 лет, а последние пару лет одно из моих основных направлений - B2B matchmaking. Поэтому я регулярно вижу споры между компаниями о выплатах и претензии, и таких ситуаций в рынке явно становится больше.

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

Вот например про один из таких кейсов писал уже здесь весной.

Если неконструктивны обе стороны (а бывает и так), то можно к этому относиться просто как к развлекательному контенту.

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

Сейчас самый заметный в аффилейт рынке пример это кейс Melbet <> Pepper Partners, который уже более месяца развивается в публичном поле и о нем уже писали и многие аффилейт медиа, и отдельные блоги, я наверно один из последних, кто у себя в блоге еще об этом не писал)

Изначальное заявление кейса и описание претензии от Pepper Partners можно почитать здесь.

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

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

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

Не знаю конечно их точные цифры затрат на PR в рамках афф рынка (участие в конфах, собственные ивенты, реклама в афф медиа и т.п.), но из того, что вижу как организатор ивентов с приличным опытом, этот бюджет явно измеряется в миллионах $ в год, если не выходит за $10млн+.

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

И вот уже более месяца в паблике незакрытый и не откоммуницированный публично кейс на $2k (две тысячи долларов).

В публичной дискуссии сейчас преобладает позиция, что Melbet в этом споре неправы.

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

Какие материальные потери может понести бренд в такой истории?

Многие люди, даже очень опытные и умные, почему-то к таким ситуациям относятся бинарно.

Рухнет бренд (закроется, обанкротится) - значит плохо на них повлиял кейс.

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

Но это же совсем не так, ситуация не бинарная.

Представим не фактические цифры Melbet, которых у нас нет, а консервативную модель крупного рекламодателя.

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

Я не знаю внутренний LTV партнёра у Melbet. Но если принять для активного опытного аффилейта условные $10,000 LTV, десять таких потерянных партнеров - это уже шестизначная сумма $ недополученного дохода. И это без учёта крупных команд, в случае которых эффект может быть кратно выше и оказаться семизначным.

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

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

Одна известная в рынке команда публично рассказала о своем таком решении в моем чатике про scam-кейсы.

А теперь вернемся к миллионам долларов в год, которые Melbet тратит на публичный PR среди аффов через конфы и прочие активности.

У этих трат же есть определенные ожидаемые и реальные результаты, верно?

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

Вообще без понятия какая там ожидаемая сумма выхлопа на каждый потраченный миллион, поэтому обозначим ожидаемую сумму выхлопа с потраченного на PR миллиона в X.

При таком незакрытом публичном кейсе, вызывающем большой отклик и возмущение в рынке - останется эта сумма выхлопа с PR X без учета прочих факторов или она станет меньше X?

Очевидно станет меньше, доверие к бренду ниже, а значит и вложения в PR дают меньшую отдачу.

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

Когда бренд инвестирует миллионы в доверие рынка - через конференции, медиа, партнёрские активности и PR, игнорирование аргументированного публичного конфликта снижает отдачу от всех этих вложений. Репутация не выглядит отдельной строкой в P&L, но её потеря вполне превращается в недополученный доход, более дорогой PR и менее лояльных партнёров.

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

Всем отличной недели и благоразумия)

5 ошибок с Sentry, из-за которых алерты шумят, а баги всё равно проходят мимо

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

— Не размечают среду и релиз: без environment, release и нормального naming один и тот же баг размазывается по разным группам.
— Ловят всё подряд: лишние warning'и, обработанные исключения и повторные ретраи лучше фильтровать на входе.
— Не отправляют контекст: user id, маршрут, feature flag, breadcrumb'ы и request id экономят часы ручного дебага.
— Не настраивают grouping: одинаковые по смыслу ошибки могут распадаться на десятки задач, если сообщение слишком «шумное».
— Не чистят alert rules: если триггеров много, команда перестаёт реагировать даже на важные инциденты.

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

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

$80 за FTD на СНГ — казино-оффер от ПОКЕРОК Partners

Ищете новый оффер для теста? Рассказываем, что предлагаем партнёрам:
• CPA $80 за FTD на все гео СНГ
• $100 к первой выплате для новых аффилиатов
• 5% по саб-реферальной программе
• прозрачная статистика в партнёрском кабинете
• поддержка личного менеджера

Принимаем различные источники: social, мессенджеры, YouTube / Twitch / Kick, SEO, PPC, in-app и медийный трафик.

В казино ПОКЕРОК также доступна GG99 — линейка из 20+ игр с RTP 99%, включая слоты, настольные игры, видеопокер и аркады. Это весомое преимущество для новых игроков в дополнение к приветственным бонусам.

И ещё один повод подключиться уже сейчас: 27 августа состоится Friendly Tournament для партнёров ПОКЕРОК Partners. Успейте подключиться до 25 августа, чтобы принять участие!

Присоединяйтесь к ПОКЕРОК Partners и начинайте зарабатывать на своём трафике уже сейчас!

Convex берут не за хайп, а чтобы не собирать backend из пяти сервисов

Convex — это backend с БД, API и реактивной моделью данных в одном месте. Для MVP и внутренних продуктов он удобен, когда нужно быстро поднять авторизацию, хранение сущностей и обновление UI без ручного polling.

Но ловушка простая: Convex хорошо выглядит, пока логика остаётся «CRUD + подписки». Как только появляются сложные отчёты, тяжёлые джобы, нестандартные интеграции или жёсткие требования к схеме, начинаются компромиссы. Проверяйте заранее:
• можно ли выразить ваши запросы без костылей;
• как будет жить миграция схемы;
• где исполняются фоновые задачи;
• что случится, если часть логики придётся вынести наружу.

По опыту, Convex чаще выигрывает у связки «Postgres + realtime + отдельный backend», когда команда маленькая и важна скорость сборки. Но если проект уже завязан на SQL-экосистему, аналитические запросы и внешние инструменты, цена удобства может стать слишком высокой.

Есть хорошее правило: сначала описать данные и 3-5 ключевых сценариев, потом проверить, укладываются ли они в модель сервиса. Если да — Convex экономит недели. Если нет — лучше узнать это до того, как в коде появится половина продукта.

PlanetScale удобен, пока вы не упираетесь в миграции и join-heavy запросы

Если вам нужен MySQL без боли с руками в проде, PlanetScale закрывает базовую задачу: быстрый старт, ветки схемы, безопасные deploy requests, понятная изоляция изменений. Для соло-проектов и небольших команд это часто лучше, чем сразу собирать собственный кластер и режимы отказоустойчивости.

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

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

Если проект растёт в сторону сложной аналитики, многошаговых транзакций и плотных join’ов, лучше закладывать миграцию заранее. PlanetScale хорош как ускоритель старта, но его сильная сторона — не универсальная база, а аккуратный MySQL для команд, которые умеют держать схему простой.

Railway удобен, пока проект маленький: дальше начинает решать дисциплина деплоя

Railway любят за низкий порог входа: поднял сервис, подключил БД, накинул переменные — и поехали. Но это не «магический хостинг», а платформа, где быстро всплывают слабые места проекта: неявные зависимости, забытые миграции, фоновые задачи в web-процессе.

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

Если нужен Railway надолго, делите приложение на минимум 3 роли: web, worker, scheduler. Базу держите отдельно от кода, а секреты — только в переменных окружения. И ещё: любой deploy должен быть повторяемым без участия человека. Если сборка или старт требуют «докинуть руками», значит схема уже хрупкая.

Есть наблюдение которое стоит проверить: Railway хорошо показывает, насколько ваш проект контейнеризован по-настоящему. Если после первого масштабирования всё разваливается, проблема не в платформе. Обычно это значит, что у вас не описаны healthcheck, не выделены фоновые задачи и не продуманы миграции.

Итог простой: Railway — отличный старт для MVP и аккуратного продакшена, если архитектура разнесена по ролям. Чем раньше вы отделите web от worker и миграции от ручного запуска, тем меньше сюрпризов будет при росте.