END-TO-END PRODUCT DELIVERY
TicketTON
От продуктовых правил до контролируемого релиза
TicketTON — игровая платформа внутри Telegram WebApp с real-time multiplayer, Player- и Admin-приложениями, server-authoritative promo/free-play Ticket-экономикой и операционными контролями на базе PostgreSQL. Реализация продукта и его release / activation проходили через отдельные контролируемые gates.
Моя зона ответственности
- Продуктовые правила и бизнес-логика
- Требования и scope
- Последовательность Delivery
- QA и критерии приёмки
- Release и активация
Engineering реализовывал приложение, базу данных и тестовую инфраструктуру.
Продуктовые домены
PLAYER
Игры · Профиль · Миссии · Рефералы · Gifts
MULTIPLAYER
Flappy · Arena · Tanchiki · Matchmaking
ECONOMY & GROWTH
Tickets · Сезоны · Referral · Rewards
OPERATIONS
Admin · Очереди · Сессии · Reconciliation · Controls
Контекст системы
- 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
Текущий статус среды
Тестовая среда · synthetic load testingБаза очищена и не содержит реальных пользовательских данных. Сейчас продукт проходит синтетические нагрузочные и функциональные тесты: проверяются стабильность сервера, игровые комнаты, очереди, matchmaking и обработка ошибок перед следующим этапом release readiness.
Дополнительные product surfacesTON-инфраструктура в Admin
DEEP DIVE
От простой реферальной механики к управляемой бизнес-системе
TicketTON — Referral Rewards
Сам факт реферальной связи не создаёт автоматического права на награду. Финальная продуктовая модель связала reward с подтверждённой активностью, периодом maturation, проверкой состояния, атомарным начислением и отдельным контролем активации.
Цель сместилась от вознаграждения за регистрацию к вознаграждению за пользователя, который действительно начал пользоваться продуктом.
Attribution ≠ Entitlement
Проблема
Простая модель
Обязательство по награде возникает от одной только регистрации.
- Приглашение
- Регистрация
- Награда
Риски, которые система должна была предотвращать
Сценарии сбоя, которые должен был закрыть продуктовый контракт.
- Низкокачественные / искусственные регистрации
- Фарминг через повторяющихся соперников
- Дублирующиеся начисления
- Одностороннее начисление
- Неконтролируемые сезонные обязательства
- Несогласованность accounting
Это риски, под которые проектировалась система, а не заявленные production-инциденты.
Продуктовый контракт
- Квалификация
- 3 активных UTC-дня
- 10 подходящих матчей
- 8 уникальных реальных соперников
- Maturation
- 7 полных дней
- Reward
- +150 Tickets приглашённому
- +250 Tickets пригласившему
- Ограничение
- Не более 5 оплаченных referral-пар на inviter за origin season
Финальный продуктовый контракт зафиксировал эти пороги как часть условий возникновения права на награду.
Дисциплина release
STATE MACHINE
Логика начисления реферальной награды
- ATTRIBUTED / ПривязанНаблюдение
3 активных дня · 10 подходящих матчей · 8 уникальных реальных соперников
КвалифицированMaturation7 полных дней
Готов к начислениюАтомарное начислениеНаграда начислена - 01ATTRIBUTED / Привязан
- 02Наблюдение
3 активных дня · 10 подходящих матчей · 8 уникальных реальных соперников
- 03Квалифицирован
- 04Maturation
7 полных дней
- 05Готов к начислению
- 06Атомарное начисление
- 07Награда начислена
Боковые / конечные состояния
Attribution входит в машину состояний; награда начисляется только после квалификации, maturation и атомарного начисления.
Риск → Продуктовый контроль
Искусственная / низкокачественная регистрация
Пороги квалификации: активные дни, подходящие матчи и уникальные реальные соперники
Повторяющийся фарминг / неоднозначное поведение
Окно maturation + HOLD / ручная проверка
Дублирующееся / частичное начисление
Идемпотентная атомарная пара наград
Неограниченные обязательства по наградам
Сезонный лимит + отсутствие переноса между сезонами
Доказательства приёмки
Обязательные acceptance-проверки
Evidence принимается только при полном прохождении набора проверок.
Категорий критических противоречий reconciliation
Негативный acceptance-кейс
- Ожидалось
- +150
- Намеренно создано
- +149
- Результат
- RECONCILIATION FAIL
- После удаления противоречия
- PASS
Примеры reconciliation-проверок5 примеров из 21 критической категории
- неверная сумма
- односторонняя пара
- дублирующаяся награда
- награда до окончания maturation
- расхождение в ledger
Обоснование негативной приёмкиСоздано +149 вместо +150
Acceptance harness намеренно создавал ошибочную сумму, чтобы доказать: экономическая несогласованность должна переводить reconciliation в FAIL.
Дополнительные доказательства
Бизнес-правилаЗафиксированный продуктовый контракт
- Первая принятая attribution
- Attribution неизменяема
- Самореферал запрещён
- Нет ретроактивной attribution с правом на награду
- Квалификация до награды
- Maturation до награды
- Пути HOLD / BLOCKED
- Нулевой перенос между сезонами
- Отсутствие побочных эффектов Gift
- Парная награда как одна атомарная бизнес-транзакция
- Активация под контролем владельца
Edge casesAttribution · Квалификация · Награда · Риски / Сезон
Attribution
- Побеждает первая принятая attribution
- После принятия attribution неизменяема
- Самореферал отклоняется
- Нет ретроактивной attribution с правом на награду
Квалификация
- Подсчёт активных дней по границам UTC
- Определение подходящего матча исключает неквалифицирующие сессии
- Подсчёт уникальных реальных соперников
- Квалификация должна завершиться до старта maturation
Награда
- Парная награда — одна атомарная бизнес-транзакция
- Идемпотентное начисление — без дублирующих строк ledger
- Односторонняя пара невозможна
- Отсутствие побочных эффектов Gift
Риски / Сезон
- Пути HOLD и BLOCKED останавливают прогресс
- Сезонный лимит оплаченных пар на inviter / origin season
- Нулевой перенос между сезонами
- Истечение при невыполненной квалификации
Приёмка и reconciliationEvidence принимается только при полном прохождении
- 44 обязательные acceptance-проверки по продуктовым правилам и accounting
- 21 категория критических противоречий reconciliation
- Негативная приёмка: +149 вместо +150 обязано переводить reconciliation в FAIL
- Количество строк ledger и суммы сходятся точно
Синтетический PostgreSQL acceptance-сценарий6 синтетических рефералов · 5 оплачены · 1 лимит исчерпан
- 6 синтетических рефералов
- 5 оплачены · 1 лимит исчерпан
- 750 Tickets приглашённым
- 1 250 Tickets пригласившим
- 10 точных строк ledger по наградам
- 0 операций с односторонней парой
- 0 побочных эффектов Gift
Синтетический сценарий приёмки — это не пользовательская или конверсионная аналитика.
Корректирующий цикл приёмкиPhase 8 → 137 → 138 → 20/20
- Основа Phase 8
- Миграция 137
- Forward-only корректирующая приёмка 138
- Валидация
- 20/20 проверок на PostgreSQL 16 пройдено
Закоммиченная реализация не считалась принятым scope; referral-основа прошла forward-only корректирующий цикл приёмки до продолжения работ.
Затронутые поверхности Delivery
- Player UI
- Backend-правила
- Состояние PostgreSQL
- Ledger
- Миграции
- Временная логика
- Reconciliation
- Автоматическая приёмка
0→1 PRODUCT DEFINITION
HeyLocal
Сначала продуктовая модель, потом алгоритм подбора
HeyLocal переосмысляет поиск локального опыта: вместо просмотра статичных предложений система должна сопоставлять путешественника с реализуемым Experience Proposal на основе реальных возможностей гида, предпочтений, логистики и доступности.
До реализации matcher я сравнил разные продуктовые модели, отказался от удобных, но неверных shortcut-решений, ограничил MVP и зафиксировал domain rules, которым должна следовать техническая реализация.
Решение по продуктовой модели
- Traveler → Tour ListingОтклонено
- Traveler → GuideОтклонено
- Traveler ↔ Experience Proposal ↔ GuideВыбрано
Static Tour Listing не является core domain entity.
MATCHING MODEL
Модель матчинга
Traveler
- дата / время
- язык
- группа
- интересы
- желаемый результат
- предпочтение по ходьбе
- бюджет
Guide
- доступность
- языки
- возможности
- экспертиза
- стиль
- guest fit
- working terms
- места
3 разных Experience Proposals
Жёсткие ограниченияОтсеивающие критерии
- гид подтверждён / доступен для матчинга
- язык
- дата
- временной интервал
- доступность
- длительность
- размер группы
- транспорт / возможности
- заказ в тот же день
- минимальный срок уведомления
- бюджет
Критерии мягкого соответствияСигналы ранжирования
- интересы
- выведенные предпочтения
- экспертиза
- аффинити к местам
- личность / стиль
- желаемый результат
- предпочтение по ходьбе
- guest fit
- география
Границы MVP и детали реализацииAvailability · pricing · продуктовая коррекция
Traveler Taste × Guide Capability × Places × Logistics × Real-Time Availability
- 04
Ограниченная availability вместо универсального calendar engine.
7 дней недели · 4 временных интервала по Риму · переопределения по датам · 2ч / 3ч / 4ч
- 05
Pricing сейчас — payments позже.
Pricing нужен для оценки реализуемости. Полная платёжная инфраструктура пока не нужна.
Сейчас
- минимальная выплата гиду
- каноническая цена для путешественника
- 10% комиссия платформы
- целые центы / BigInt
Позже
- НДС / налоги
- моделирование комиссий Stripe
- возвраты
- жизненный цикл платежей и выплат
- Прототип существовал
- Fixture-логика рекомендаций выглядела пригодной
- Соблазнительный shortcut: постепенно перевести её в production
- Продуктовое решение: не позволять прототипной логике рекомендаций стать domain contract
- Определить реальный matcher на основе реальных данных Guide и Traveler, операционных ограничений и канонического pricing
Deterministic Matching v1 — жёсткие ограничения отсеивают, мягкое соответствие ранжирует, diversity rerank исключает почти одинаковые результаты.
Продуктовые решения
- 01
Experience Proposal вместо статичного listing / direct Guide model.
- 02
Deterministic Matching v1.
Без LLM matcher.
- 03
Без winner и без «98% match».
Возвращаем три содержательно разных рекомендации.
Текущий статус: persisted foundation реализована; Deterministic Matching v1 находится на стадии product/domain specification. Recommendation UI в последнем подтверждённом состоянии остаётся fixture-based прототипом.
Стек
- TanStack Start
- React 19
- TypeScript
- TanStack Query
- Cloudflare Workers
- Supabase
- PostgreSQL
- Supabase Auth
- Resend
- Bun 1.3.14
Matching v1 — детерминированный, без LLM в runtime.
PRODUCT CONCEPT · UX · PROTOTYPING
Yerten
Групповой заказ без группового координатора
В офисе коллективный заказ еды на следующий день был удобным, но зависел от одного человека, который вручную собирал выбор, переводы и изменения. Yerten убирает координатора: каждый сотрудник выбирает и оплачивает заказ сам, а система объединяет спрос всей компании.
Групповой заказ работал. Ручная координация — нет.
Было
1 координатор
- собирает выбор
- собирает переводы
- напоминает коллегам
- обрабатывает изменения
Yerten
Сотрудник
- выбирает
- оплачивает сам
Company workspace
- агрегирует заказ
- отслеживает минимальную сумму
Yerten
- планирует приготовление
- объединяет доставку по офисам
Продуктовые правила
- 4-символьный код компании
- Индивидуальная оплата каждым сотрудником
- Минимальная сумма заказа компании: 10 000 ₸
- Отмена возможна до закрытия окна заказов
01ПОДКЛЮЧИТЬСЯ
02ВЫБРАТЬ
03ОПЛАТИТЬ
Обратная связь от целевых пользователей
Прототип показывался бывшим коллегам из целевой аудитории.
Изменения
- Добавлена новая категория еды
- Улучшены controls количества
- Добавлены состав, калорийность и БЖУ
Качественная обратная связь по прототипу, не формальное исследование.
Дополнительные продуктовые деталиРасширенные правила · операционная модель · механика привлечения · статус · scope
Расширенные правила
- Существующий заказ нельзя редактировать; можно оформить дополнительный заказ
- Количество бесплатных приборов ограничено правилами заказа
- Если минимальная сумма компании не набрана, заказ отменяется, средства должны быть возвращены
- Часы приёма заказов оставались приблизительными операционными границами
Операционная модель
- Предзаказ на следующий день — осознанный операционный выбор
- Знание спроса заранее должно было поддержать batch-приготовление и кластерную доставку по офисам
- Измеренная экономия и снижение отходов не заявляются
Планируемая механика привлечения
- Планируемый бонус 3 000 ₸ за создание новой компании
- Виральный рост не заявляется как доказанный
Статус реализации
- Полноценный интерактивный прототип
- Попытка разработки с внешней командой не достигла приемлемого уровня реализации
Scope / инструменты
Figma · IA · User flows · Wireframes · UI · Component system · Interactive prototype
COMMERCIAL DELIVERY
Коммерческие digital-проекты
Разные бизнесы. Одинаковый принцип ownership.
Два реализованных коммерческих веб-проекта: один — потребительский, второй — промышленный. Оба прошли один и тот же end-to-end путь: от понимания бизнеса до запуска.
QARAQURT
B2C / E-commerceКоммерческий B2C / e-commerce проект. Я напрямую работал с бизнесом, выявлял потребности, проектировал структуру и самостоятельно реализовал сайт. Tilda была сознательно выбрана ради быстрого time-to-market и возможности бизнеса самостоятельно управлять сайтом после запуска.
CBS PromTech
B2B / IndustrialКоммерческий B2B industrial-проект. Главной задачей было превратить широкое и технически сложное предложение компании в понятную information architecture и customer-facing digital structure. Я работал с бизнесом, структурировал предложение и самостоятельно реализовал сайт на Tilda.
