SunDrSunDr
Назад к блогу
case-study

SaaS для покерной аналитики: кейс разработки

Как один разработчик создал SaaS покер-аналитики: 67K строк TypeScript, 43 эндпоинта, симулятор Монте-Карло и биллинг Paddle — от идеи до продакшена.

Опубликовано 27 марта 2026 г.9 мин чтения
TypeScriptSaaSNext.jsPostgreSQLCase StudyMonte CarloPaddleFull-StackAPI DesignTesting
SaaS для покерной аналитики: кейс разработки

Когда берёшься за разработку SaaS приложения в нишевом домене, быстро понимаешь: 80% сложности лежит не в CRUD-операциях, а в бизнес-логике, которую невозможно загуглить. Этот кейс разработки веб-приложения — про то, как я в одиночку построил полноценный SaaS-трекер покерных турниров: 67 760 строк TypeScript, 43 API-эндпоинта, подписочный биллинг и математические модели, которые реально помогают игрокам принимать решения о банкролл-менеджменте.

Задача: SaaS для профессиональных покерных игроков

Идея звучит просто: игрок вносит результаты турниров, приложение показывает статистику. На практике это далеко не CRUD. Серьёзным покерным игрокам нужен инструмент, который учитывает природу дисперсии в покере — короткие серии проигрышей (даунстрики), которые статистически неизбежны даже у прибыльных игроков.

Вот что в итоге вошло в продукт:

  • Симулятор дисперсии Монте-Карло с бутстрап-ресемплингом — рассчитывает вероятность даунстрика заданной длины, доверительные интервалы профита и требования к банкроллу.
  • Парсеры истории рук для PokerStars и GGPoker — автоматический импорт результатов из файлов румов.
  • 30 достижений с 5-уровневой системой — геймификация, которая удерживает пользователей.
  • Мультивалютная система с двойным фолбэком для 25+ валют — игроки со всего мира играют в разных валютах, конвертация должна работать всегда.
  • 6 языков (en, ru, uk, de, es, fr) и PWA с офлайн-поддержкой — многие игроки вносят результаты прямо за столом с телефона.

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

Архитектура: Next.js fullstack с 19 моделями данных

Стек: Next.js App Router + Prisma + PostgreSQL. Почему именно он? Next.js позволяет держать фронтенд и бэкенд в одном репозитории, что критично для одиночной разработки — нет накладных расходов на координацию между сервисами. Prisma даёт типобезопасность на уровне базы данных: когда у тебя 19 моделей и 43 REST API эндпоинта, возможность словить ошибку в типах до рантайма экономит часы отладки.

Весь код — строгий TypeScript. 67 760 строк без единого any в продакшен-коде. Это не перфекционизм — это необходимость, когда один человек поддерживает кодовую базу такого размера. Компилятор ловит то, что мозг пропускает на ревью собственного кода.

Отдельная история — 24 кастомных React-хука, которые инкапсулируют повторяющуюся логику: работу с фильтрами, пагинацией, формами, мультивалютной конвертацией. Авторизация реализована через три провайдера: Google OAuth, Facebook OAuth и email/password с верификацией. PWA-манифест и сервис-воркер обеспечивают офлайн-доступ.

Сложные задачи: симулятор дисперсии и парсеры рук

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

Ключевая сложность — производительность. Симуляция должна работать быстро на клиенте, потому что игроки экспериментируют с параметрами в реальном времени. Пришлось оптимизировать алгоритм так, чтобы 10 000 итераций отрабатывали без заметных задержек.

Парсеры рук — другой уровень боли. Парсер PokerStars поддерживает 15+ форматов таймзон, потому что PokerStars исторически менял формат записи времени в истории рук. Парсер GGPoker принёс другую головную боль — дедупликация. GGPoker иногда отдаёт один и тот же турнир в нескольких файлах экспорта. Без надёжной дедупликации пользователь получает задвоенные результаты и искажённую статистику.

Подписочный биллинг: Paddle и борьба с рейс-кондишенами

Для интеграции платёжной системы выбрал Paddle — они берут на себя налоговый комплаенс по всему миру, что критично для SaaS-продукта с пользователями из десятков стран. Подписочная модель: бесплатный тариф с лимитом 1 000 турниров, месячная подписка, годовая подписка и lifetime-доступ.

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

Ещё одна неочевидная проблема — пропущенные вебхуки. Для этого реализован авто-синк: периодическая сверка статуса подписки напрямую через API Paddle. Feature gating для 6 Pro-фич реализован на уровне и API, и UI. Бесплатные пользователи видят заблокированные фичи с предложением апгрейда — это одновременно и ограничение, и маркетинговый инструмент.

Тестирование: 1 400+ тестов на трёх уровнях

Для SaaS-продукта с биллингом тестирование — не опция, а необходимость. Баг в обработке платежей — это не "ой, кнопка не того цвета", это реальные деньги пользователей. Поэтому 1 400+ тест-кейсов в 341 тестовом файле:

  • Unit-тесты — покрывают бизнес-логику: расчёт статистики, Монте-Карло симулятор, мультивалютную конвертацию, парсеры рук.
  • Интеграционные тесты — Prisma + PostgreSQL в Docker-контейнере. Проверяют, что API-эндпоинты корректно работают с реальной базой данных.
  • 26 E2E-сценариев на Playwright — полные пользовательские флоу: регистрация, добавление турниров, запуск симулятора, оформление подписки.

Когда ты единственный разработчик и у тебя нет QA-инженера, тесты — твоя страховочная сетка. Каждый деплой проходит через полный прогон.

Строите SaaS-продукт?

Вот так выглядит fullstack-разработка веб-приложения, когда она сделана правильно: строгая типизация, трёхуровневое тестирование, надёжный биллинг и архитектура, которая выдерживает рост. За 9+ лет в разработке я прошёл путь от OTT-платформ на 80M+ зрителей до SaaS-продуктов с подписочной моделью. Если вам нужна разработка SaaS приложения — от архитектуры и API до биллинга и деплоя — запишитесь на бесплатный 30-минутный звонок или попробуйте калькулятор проекта для предварительной оценки.

Есть проект?

Запишитесь на бесплатный 30-минутный звонок или попробуйте калькулятор для быстрой оценки.

Aleksandr Sakov

Александр Саков

Основатель SunDr. 9+ лет разработки OTT-стриминговых платформ, мобильных приложений и веб-продуктов. Платформы, которые я построил, обслуживают 80M+ зрителей на 15+ типах устройств.