Если вам нужна виральность, а бюджета на рекламу нет, то самый дешёвый канал роста уже сидит внутри самого продукта, и это результат, которым человеку самому хочется поделиться. В Картаре я решил сделать ровно так: получаешь ссылку на свой расклад, кидаешь её другу или партнёру, он открывает её безо всякой авторизации и регистрации, читает целиком, а внизу страницы уже висит кнопка «сделай свой». И вот тут, когда человек уже зацепился, продукт просит логин. То есть сначала ценность, потом регистрация, а не наоборот, как почти у всех. Сделали мы это за один заход сразу на все семь типов расклада, единым модулем, бэк плюс два фронта, и по дороге ревью поймало пару красивых багов, про которые я и хочу рассказать честно.
Сама идея родилась из простой мысли, я её даже надиктовал ассистенту почти дословно: «Чтение то по ссылке которую тебе дали может без авторизации сделать то. А там уже потом кнопка сделать типа свое и потом уже авторизацию конечно просит». Звучит банально, но если вы посмотрите как обычно устроены приложения с астрологией, нумерологией и прочей эзотерикой, то там стена регистрации стоит прямо на входе, и человек, которому друг просто хотел показать прикольный результат, упирается в форму и уходит. А я хотел убрать эту стену ровно до того момента, пока у человека не появился интерес сделать своё, потому что стена регистрации убивает конверсию сильнее любой рекламы, и про это у меня есть отдельная история на цифрах.
Почему сразу на семь продуктов, а не на один
Тут важный момент про то, как я вообще строю такие вещи. У Картары семь разных раскладов: синастрия, натальная карта, карта дня, сны, архетипы, нумерология и таро, и можно было сделать шаринг сначала для одного, обкатать, а потом копировать. Но это путь, на котором ты семь раз пишешь почти одно и то же и семь раз получаешь чуть разные баги. Я дал команду по-другому: «упакуй систему шаринга как компонент . и бэк и фронт». То есть один контракт на бэкенде, один способ сгенерировать ссылку, один способ её отрендерить, а дальше просто семь рендереров поверх общего ядра.
По факту это вылилось в довольно большую параллельную сборку: единый share-модуль на бэке, семь web-рендереров под каждый тип расклада, четырнадцать интеграций самой кнопки (семь на вебе и семь в Telegram Mini App), плюс отдельная SSR-страница, которая отдаёт расклад по ссылке вида /р/[хеш]. Я не писал это руками, я код писать не умею и не скрываю этого, я оркестрировал: запустил десятки агентов разом, каждый делал свой кусок, а я держал в голове общую картину и контракт. Когда у тебя один источник правды на бэке, то параллелить такую тупую механическую работу одно удовольствие, агенты не мешают друг другу, потому что лезут в разные рендереры, а не в одно ядро.
Хеш на расклад и почему имя партнёра скрыто по умолчанию
Техническая основа простая: на каждый расклад генерится уникальный хеш, и публичная ссылка ведёт именно на него, а не на айдишник пользователя, который можно перебрать. Открываешь, видишь конкретный расклад, и всё, ничего лишнего про автора оттуда не достать.
Дальше начинается то, что я считаю не технической, а человеческой частью. Расклады в Картаре часто про отношения, это синастрия, это совместимость, это вот вся история про «он и она». И если вы делаете расклад про партнёра, то в нём фигурирует его имя и его данные. А теперь представьте, что человек шарит такую ссылку, и в публичной странице торчит имя того самого партнёра. Поэтому имя партнёра в публичной выдаче маскируется по умолчанию, есть тоггл, которым можно его открыть, но дефолт — закрыто. И сырые координаты карт наружу тоже не отдаются, в публичную ссылку уходит только то, что человек реально хочет показать, а не вся внутренняя кухня.
Отдельная боль — это шаринг чата. В Картаре можно поговорить с AI про свою ситуацию, и там люди пишут очень откровенные вещи про близких. Если дать возможность шарить ещё и переписку, то возникает совершенно реальный риск: человек на эмоциях написал что-то про партнёра, а потом случайно отправил эту ссылку ему же. Это не гипотетика, это ровно тот сценарий, на котором можно крепко обжечься. Поэтому шар чата сделан отдельной опцией, по умолчанию выключенной, и перед отправкой вылезает предупреждающая модалка: стоп, ты сейчас делишься перепиской, ты точно этого хочешь и точно понимаешь кому. Лучше лишний раз ткнуть человека носом, чем потом разгребать чужую драму.
Два бага, которые поймало ревью
Вот тут самое интересное, и я специально не приглаживаю, потому что в этом вся правда про разработку с ИИ. Когда десятки агентов лепят четырнадцать интеграций поверх одного контракта, то ошибки лезут не там, где ты их ждёшь.
Первый баг — это инверсия семантики тоггла маскировки имени между Telegram Mini App и вебом. На одном и том же бэкенде, на одном и том же контракте, два фронта поняли булевый флаг противоположно: то, что на вебе означало «скрыть имя», в приложении означало «показать». То есть юзер ставит галочку, думая что прячет имя партнёра, а на деле открывает его всем по ссылке. Это ровно тот класс багов, который не ловится на «работает же», ведь оба фронта работают, оба что-то делают, просто делают противоположное, и заметить это можно только если сознательно сверять поведение на одном контракте с двух клиентов. Та же природа, что и в истории, как бэк брал 20 токенов, а фронт требовал 30: один контракт на два клиента всегда даёт шанс, что клиенты разойдутся в понимании. Я про опасность смешать поведение клиентов на одном бэке уже как-то обжигался раньше, есть отдельная история про то, как друг открыл моё приложение с моего телефона и AI рассказал ему мою жизнь, и здесь снова та же природа: код есть, тесты есть, а смысл инвертирован.
Второй баг — это гонка на идемпотентном создании ссылки. Идемпотентность тут значит, что если человек дважды нажал «поделиться», то ссылка должна получиться одна и та же, а не два хеша на один расклад. Но при параллельных запросах вылезала гонка, и можно было получить два share-объекта вместо одного. Само по себе не катастрофа, но это именно та мелочь, которая в проде превращается в «почему у меня две разные ссылки на одно и то же» и тихо подрывает доверие к фиче.
Оба бага нашло ревью, а не я глазами и не «вроде работает». И это, кстати, мой главный аргумент в споре про вайбкодинг и говнокод, а что, разве кожаные разработчики не пишут говнокод? не смешите меня. Разница не в том, человек писал или нейросеть, а в том, есть ли у тебя слой, который сознательно ищет вот эту инверсию семантики и эти гонки. У меня этот слой — обязательное ревью на каждом куске, и без него параллельная сборка на четырнадцать интеграций превратилась бы в минное поле.
Что я из этого вынес
Главный вывод даже не про шаринг, а про подход. Когда вы делаете виральную механику типа «поделись результатом по ссылке без регистрации», то технически она простая: хеш, публичная страница, CTA на регистрацию внизу. А вся реальная работа сидит в двух местах: в приватности и в том, что вы строите это как один модуль, а не семь копий. Маскировка личных данных по умолчанию, предупреждающая модалка перед шарингом откровенного, ссылка на хеш а не на пользователя, вот это и отделяет фичу, которой не страшно пользоваться, от фичи, на которой кто-то спалит свою личную жизнь.
А единый компонент на семь продуктов сразу — это даже не про скорость, это про то, что баг ты чинишь один раз в ядре, а не ищешь его в семи местах. Да, при этом всплывает своя плата: один контракт на два фронта даёт шанс на инверсию семантики, как у меня и вышло. Но это управляемый риск, его ловит ревью, а вот семь расходящихся реализаций ты не починишь уже никогда. И если из всего этого вынести одну мысль для своего MVP, то такую: стройте механику роста внутрь продукта с первого дня, но приватность закладывайте дефолтом, а не опцией, ведь виральность без доверия живёт ровно до первого случая, когда человек случайно поделился тем, чем не хотел. Вот и делайте выводы.