ГЛАВНЫЙ КЕЙС
TicketTON
От продуктовых правил до готовности к запуску
TicketTON — игровая платформа внутри Telegram WebApp: многопользовательские игры в реальном времени, отдельные приложения Player и Admin, управляемая на сервере экономика TicketTON в режиме promo/free-play и операционные механизмы контроля на базе PostgreSQL. Реализация продукта, его запуск и активация проходили через отдельные контролируемые этапы.
Моя зона ответственности
- Продуктовые правила и бизнес-логика
- Требования и границы работ
- Последовательность реализации
- QA и критерии приёмки
- Готовность к запуску и активация
Техническую реализацию приложения, базы данных и тестовой инфраструктуры выполняла инженерная часть проекта.
Продуктовые домены
PLAYER
Игры · Профиль · Миссии · Рефералы · Gifts
MULTIPLAYER
Flappy · Arena · Tanchiki · Matchmaking
ЭКОНОМИКА И РОСТ
Tickets · Сезоны · Рефералы · Награды
ОПЕРАЦИИ
Admin · Очереди · Сессии · Сверка · Контроль
Контекст системы
- Telegram WebApp
- React / Vite Player
- Fastify / Node.js API
- PostgreSQL
- Player ↔ Colyseus ↔ Multiplayer
- Admin → Fastify / PostgreSQL
Стек
- Telegram WebApp
- React 18
- TypeScript
- Vite 5
- Node.js 22
- Fastify 5
- PostgreSQL 16
- Colyseus
- Docker
- Nginx
- Vitest
- GitHub Actions
Текущий статус среды
Тестовая среда · синтетическое нагрузочное тестированиеБаза очищена и не содержит реальных пользовательских данных. Сейчас продукт проходит синтетические нагрузочные и функциональные тесты: проверяются стабильность сервера, игровые комнаты, очереди, подбор соперников и обработка ошибок перед следующим этапом оценки готовности к запуску.
Дополнительные операционные интерфейсыTON-инфраструктура в Admin
ДЕТАЛЬНЫЙ РАЗБОР
От простой реферальной механики к управляемой бизнес-системе
TicketTON — Referral Rewards
Сам факт реферальной связи не создаёт автоматического права на награду. Финальная продуктовая модель связала награду с подтверждённой активностью, периодом ожидания, проверкой состояния, атомарным начислением и отдельным контролем активации.
Цель сместилась от вознаграждения за регистрацию к вознаграждению за пользователя, который действительно начал пользоваться продуктом.
Приглашение ≠ право на награду
Проблема
Простая модель
Обязательство по награде возникает от одной только регистрации.
- Приглашение
- Регистрация
- Награда
Риски, которые система должна была предотвращать
Сценарии сбоя, которые должны были закрыть правила продукта.
- Низкокачественные / искусственные регистрации
- Фарминг через повторяющихся соперников
- Дублирующиеся начисления
- Одностороннее начисление
- Неконтролируемые сезонные обязательства
- Несогласованность учёта
Это риски, под которые проектировалась система, а не заявленные инциденты рабочей среды.
Правила продукта
- Квалификация
- 3 активных UTC-дня
- 10 подходящих матчей
- 8 уникальных реальных соперников
- Период ожидания
- 7 полных дней
- Награда
- +150 Tickets приглашённому
- +250 Tickets пригласившему
- Ограничение
- Не более 5 оплаченных реферальных пар для одного пригласившего в исходном сезоне
Финальные правила продукта зафиксировали эти пороги как часть условий возникновения права на награду.
Дисциплина запуска
ЛОГИКА СОСТОЯНИЙ
Логика начисления реферальной награды
- ATTRIBUTED / Привязка созданаНаблюдение
3 активных дня · 10 подходящих матчей · 8 уникальных реальных соперников
КвалифицированПериод ожидания7 полных дней
Готов к начислениюАтомарное начислениеНаграда начислена - 01ATTRIBUTED / Привязка создана
- 02Наблюдение
3 активных дня · 10 подходящих матчей · 8 уникальных реальных соперников
- 03Квалифицирован
- 04Период ожидания
7 полных дней
- 05Готов к начислению
- 06Атомарное начисление
- 07Награда начислена
Боковые / конечные состояния
Привязка приглашения запускает последовательность состояний; награда начисляется только после квалификации, периода ожидания и атомарной операции.
Риск → Продуктовый контроль
Искусственная / низкокачественная регистрация
Пороги квалификации: активные дни, подходящие матчи и уникальные реальные соперники
Повторяющийся фарминг / неоднозначное поведение
Период ожидания + HOLD / ручная проверка
Дублирующееся / частичное начисление
Идемпотентная атомарная пара наград
Неограниченные обязательства по наградам
Сезонный лимит + отсутствие переноса между сезонами
Результаты приёмки
Обязательные проверки приёмки
Результат принимается только при прохождении всего набора проверок.
Категория критических противоречий при сверке
Негативная проверка
- Ожидалось
- +150
- Намеренно создано
- +149
- Результат
- RECONCILIATION FAIL
- После удаления противоречия
- PASS
Примеры проверок сверки5 примеров из 21 критической категории
- неверная сумма
- односторонняя пара
- дублирующаяся награда
- награда до окончания периода ожидания
- расхождение в журнале начислений
Обоснование негативной приёмкиСоздано +149 вместо +150
Проверочный сценарий приёмки намеренно создавал ошибочную сумму: экономическая несогласованность должна переводить сверку в FAIL.
Дополнительные материалы приёмки
Бизнес-правилаЗафиксированные правила продукта
- Первая принятая привязка приглашения
- Привязка приглашения неизменяема
- Самореферал запрещён
- Нет ретроактивной привязки с правом на награду
- Квалификация до награды
- Период ожидания до награды
- Пути HOLD / BLOCKED
- Нулевой перенос между сезонами
- Отсутствие побочных эффектов механики Gifts
- Парная награда как одна атомарная бизнес-транзакция
- Активация под контролем владельца
Пограничные случаиПривязка · Квалификация · Награда · Риски / Сезон
Привязка приглашения
- Действует первая принятая привязка приглашения
- После принятия привязка приглашения неизменяема
- Самореферал отклоняется
- Нет ретроактивной привязки с правом на награду
Квалификация
- Подсчёт активных дней по границам UTC
- Определение подходящего матча исключает неквалифицирующие сессии
- Подсчёт уникальных реальных соперников
- Квалификация должна завершиться до начала периода ожидания
Награда
- Парная награда — одна атомарная бизнес-транзакция
- Идемпотентное начисление — без дублирующих строк журнала начислений
- Односторонняя пара невозможна
- Отсутствие побочных эффектов механики Gifts
Риски / Сезон
- Пути HOLD и BLOCKED останавливают прогресс
- Сезонный лимит оплаченных пар для одного пригласившего в исходном сезоне
- Нулевой перенос между сезонами
- Истечение при невыполненной квалификации
Приёмка и сверкаРезультат принимается только при полном прохождении
- 44 обязательные проверки приёмки по продуктовым правилам и учёту
- 21 категория критических противоречий при сверке
- Негативная приёмка: +149 вместо +150 обязано переводить сверку в FAIL
- Количество строк журнала начислений и суммы сходятся точно
Синтетический сценарий приёмки в PostgreSQL6 синтетических рефералов · 5 оплачены · 1 лимит исчерпан
- 6 синтетических рефералов
- 5 оплачены · 1 лимит исчерпан
- 750 Tickets приглашённым
- 1 250 Tickets пригласившим
- 10 точных строк журнала начислений по наградам
- 0 операций с односторонней парой
- 0 побочных эффектов механики Gifts
Синтетический сценарий приёмки — это не пользовательская или конверсионная аналитика.
Корректирующий цикл приёмкиPhase 8 → 137 → 138 → 20/20
- Основа Phase 8
- Миграция 137
- Корректирующая приёмка 138 без отката
- Валидация
- 20/20 проверок на PostgreSQL 16 пройдено
Зафиксированная в репозитории реализация не считалась принятой автоматически: основа реферальной механики прошла корректирующий цикл приёмки без отката до продолжения работ.
Затронутые части реализации
- Player UI
- Правила бэкенда
- Состояние PostgreSQL
- Журнал начислений
- Миграции
- Временная логика
- Сверка
- Автоматизированная приёмка
0→1 · ПРОРАБОТКА ПРОДУКТА
HeyLocal
Сначала продуктовая модель, потом алгоритм подбора
HeyLocal переосмысляет поиск локального опыта: вместо просмотра статичных предложений система должна сопоставлять запрос путешественника с реализуемым персональным предложением — сущностью Experience Proposal — на основе реальных возможностей гида, предпочтений, логистики и доступности.
До реализации алгоритма подбора я сравнил разные продуктовые модели, отказался от удобных, но неверных упрощений, определил границы MVP и зафиксировал правила продукта, которым должна следовать техническая реализация.
Решение по продуктовой модели
- Путешественник → Статичное предложениеОтклонено
- Путешественник → ГидОтклонено
- Путешественник ↔ Experience Proposal ↔ ГидВыбрано
Статичное предложение о прогулке не является основной сущностью модели.
ЛОГИКА ПОДБОРА
Модель подбора
Путешественник
- дата / время
- язык
- группа
- интересы
- желаемый результат
- предпочтение по ходьбе
- бюджет
Гид
- доступность
- языки
- возможности
- экспертиза
- стиль
- соответствие ожиданиям гостя
- условия работы
- места
3 разных персональных предложения (Experience Proposal)
Жёсткие ограниченияОтсеивающие критерии
- гид подтверждён и доступен для подбора
- язык
- дата
- временной интервал
- доступность
- длительность
- размер группы
- транспорт / возможности
- заказ в тот же день
- минимальный срок уведомления
- бюджет
Критерии мягкого соответствияСигналы ранжирования
- интересы
- выведенные предпочтения
- экспертиза
- аффинити к местам
- личность / стиль
- желаемый результат
- предпочтение по ходьбе
- соответствие ожиданиям гостя
- география
Границы MVP и детали реализацииДоступность · ценообразование · продуктовая коррекция
Предпочтения путешественника × Возможности гида × Места × Логистика × Доступность в выбранное время
- 04
Ограниченная модель доступности вместо универсального календаря.
7 дней недели · 4 временных интервала по Риму · переопределения по датам · 2ч / 3ч / 4ч
- 05
Ценообразование сейчас — платежи позже.
Ценообразование нужно для оценки реализуемости. Полная платёжная инфраструктура пока не требуется.
Сейчас
- минимальная выплата гиду
- каноническая цена для путешественника
- 10% комиссия платформы
- целые центы / BigInt
Позже
- НДС / налоги
- моделирование комиссий Stripe
- возвраты
- жизненный цикл платежей и выплат
- Прототип уже существовал
- Логика рекомендаций на тестовых данных выглядела пригодной
- Возникал соблазн постепенно перенести её в рабочий продукт
- Продуктовое решение: не превращать логику прототипа в правила работы продукта
- Определить алгоритм подбора на основе реальных данных гида и путешественника, операционных ограничений и единого ценообразования
Алгоритм подбора v1 детерминирован: жёсткие ограничения исключают нереализуемые варианты, мягкие критерии ранжируют остальные, а финальная перестановка не допускает почти одинаковых результатов.
Продуктовые решения
- 01
Experience Proposal — персональное предложение вместо статичного каталога или прямого выбора гида.
- 02
Детерминированный алгоритм подбора v1.
Без LLM.
- 03
Без единственного «победителя» и условных «98% совпадения».
Возвращаем три содержательно разных рекомендации.
Сейчас базовая модель продукта и сохранение данных реализованы. Правила подбора v1 находятся на стадии спецификации. Интерфейс рекомендаций пока работает на тестовых данных.
Стек
- TanStack Start
- React 19
- TypeScript
- TanStack Query
- Cloudflare Workers
- Supabase
- PostgreSQL
- Supabase Auth
- Resend
- Bun 1.3.14
Алгоритм подбора v1 — детерминированный, без LLM во время работы.
КОНЦЕПЦИЯ ПРОДУКТА · UX · ПРОТОТИП
Yerten
Групповой заказ без группового координатора
В офисе коллективный заказ еды на следующий день был удобным, но зависел от одного человека, который вручную собирал выбор, переводы и изменения. Yerten убирает координатора: каждый сотрудник выбирает и оплачивает заказ сам, а система объединяет спрос всей компании.
Групповой заказ работал. Ручная координация — нет.
Было
1 координатор
- собирает выбор
- собирает переводы
- напоминает коллегам
- обрабатывает изменения
Yerten
Сотрудник
- выбирает
- оплачивает сам
Общее пространство компании
- агрегирует заказ
- отслеживает минимальную сумму
Yerten
- планирует приготовление
- объединяет доставку по офисам
Продуктовые правила
- 4-символьный код компании
- Индивидуальная оплата каждым сотрудником
- Минимальная сумма заказа компании: 10 000 ₸
- Отмена возможна до закрытия окна заказов
01ПОДКЛЮЧИТЬСЯ
02ВЫБРАТЬ
03ОПЛАТИТЬ
Обратная связь от целевых пользователей
Прототип показывался бывшим коллегам из целевой аудитории.
Изменения
- Добавлена новая категория еды
- Улучшено управление количеством
- Добавлены состав, калорийность и БЖУ
Качественная обратная связь по прототипу, не формальное исследование.
Дополнительные продуктовые деталиРасширенные правила · операционная модель · механика привлечения · статус · границы проработки
Расширенные правила
- Существующий заказ нельзя редактировать; можно оформить дополнительный заказ
- Количество бесплатных приборов ограничено правилами заказа
- Если минимальная сумма компании не набрана, заказ отменяется, средства должны быть возвращены
- Часы приёма заказов оставались приблизительными операционными границами
Операционная модель
- Предзаказ на следующий день — осознанный операционный выбор
- Знание спроса заранее должно было поддержать приготовление партиями и кластерную доставку по офисам
- Измеренная экономия и снижение отходов не заявляются
Планируемая механика привлечения
- Планируемый бонус 3 000 ₸ за создание новой компании
- Виральный рост не заявляется как доказанный
Статус реализации
- Полноценный интерактивный прототип
- Попытка разработки с внешней командой не достигла приемлемого уровня реализации
Что проработано / инструменты
Figma · информационная архитектура · пользовательские сценарии · схемы экранов · UI · система компонентов · интерактивный прототип
КОММЕРЧЕСКИЕ ПРОЕКТЫ
Коммерческие веб-проекты
Разные бизнесы, один подход: понять задачу, спроектировать решение и довести до запуска.
Два реализованных коммерческих веб-проекта: один — потребительский, второй — промышленный. В обоих случаях я прошёл путь от выяснения задач бизнеса и проектирования структуры до реализации, согласований и запуска.
QARAQURT
B2C / E-commerceКоммерческий B2C / e-commerce проект. Я напрямую работал с бизнесом, выявлял потребности, проектировал структуру и самостоятельно реализовал сайт. Tilda была сознательно выбрана ради быстрого запуска и возможности бизнеса самостоятельно управлять сайтом после передачи проекта.
CBS PromTech
B2B / промышленностьКоммерческий B2B-проект для промышленной компании. Главной задачей было превратить широкое и технически сложное предложение компании в понятную структуру сайта для потенциального клиента. Я работал с представителями бизнеса, структурировал услуги и оборудование и самостоятельно реализовал сайт на Tilda.
