SakhSwim — сервис оплат и договоров

Sakhswim — школа плавания в Южно-Сахалинске. Её основатель и тренер Михаил пришёл к нам не за новым маркетинговым сайтом и не за увеличением трафика.

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

Михаил лично отправлял новым ученикам и родителям до 11 сообщений с правилами, расписанием, ссылками на групповые чаты и другой актуальной информацией. Отдельно приходилось контролировать оплаты, просить клиентов присылать подтверждения, напоминать об оплате и только после проверки отправлять нужную ссылку на группу.

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

Поэтому исходная задача звучала не как «сделать сайт», а значительно конкретнее:

автоматизировать обслуживание уже существующего потока клиентов и максимально убрать Михаила из рутинных операций.

Sakhswim работает в Южно-Сахалинске и принимает детей и взрослых.

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

Дополнительное привлечение клиентов не было приоритетной задачей: значительная часть аудитории уже находила Михаила через рекомендации, поисковые системы, 2ГИС и карты.

Поэтому мы сознательно не стали строить проект вокруг SEO, рекламных посадочных страниц, лид-магнитов или сложной аналитики.

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

Нам нужно было построить единый сценарий:

запись → выбор расписания → оформление договора → расчёт стоимости → оплата → получение доступа к группе → последующие оплаты.

При этом система должна была:

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

И всё это необходимо было сделать без избыточной автоматизации и функций, которые не решали текущую бизнес-задачу.

Почему мы не стали дорабатывать существующую систему

У Михаила уже был сервис на Django.

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

Однако проект был написан другим разработчиком, практически не имел документации и содержал технические и security-проблемы, детали которых мы не раскрываем.

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

Для заказчика это означало бы оплачивать не развитие продукта, а исследование существующего legacy.

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

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

Почему мы не стали дорабатывать существующую систему

У Михаила уже был сервис на Django.

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

Однако проект был написан другим разработчиком, практически не имел документации и содержал технические и security-проблемы, детали которых мы не раскрываем.

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

Для заказчика это означало бы оплачивать не развитие продукта, а исследование существующего legacy.

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

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

Проектирование бизнес-логики

Работу начали не с интерфейсов, а с интервью с заказчиком.

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

В результате сформировали несколько основных сущностей:

Клиент → Запись → Договор → Оплаты

Отдельно система управляет сезонами, расписаниями, стоимостью занятий и доступными формами записи.

Так сформировалась основа продукта, а уже поверх неё — пользовательский интерфейс.

Mobile-first интерфейс для аудитории разного возраста

Сайт проектировали прежде всего под смартфоны.

Возраст аудитории сильно различается: на занятия записываются взрослые и дети, а оформлять запись ребёнка могут, например, родители или бабушки и дедушки.

Поэтому одним из требований Михаила было буквально следующее:

разобраться, как записаться, оформить договор и оплатить занятия, должен и ребёнок, и пожилой человек.

Мы сознательно сокращали количество интерфейсных решений и несколько раз вместе с заказчиком переписывали тексты.

В интерфейсе использовали:

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

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

Сайт как посадочная страница

Маркетинговая часть проекта намеренно осталась компактной.

На одностраничном сайте пользователь может понять:

• кто проводит занятия;
• кому подходит обучение;
• какие направления доступны;
• как проходит обучение;
• как записаться.

Мы не стали превращать проект в большой корпоративный сайт.

Не было задачи строить сложную SEO-структуру или performance-маркетинговую воронку: у школы уже существовал устойчивый спрос.

При этом мы учитывали локальную специфику Южно-Сахалинска, в том числе привычные аудитории сервисы и каналы коммуникации.

Автоматизированная запись

Клиент выбирает доступную программу и расписание непосредственно на сайте.

Расписания управляются через CMS и отдельно настраиваются для разных типов записей и сезонов.

Например, Михаил может самостоятельно:

• изменить расписание детских групп;
• изменить расписание взрослых;
• открыть или закрыть сезонную запись;
• включить отдельную летнюю форму;
• изменить стоимость занятия.

Эти данные автоматически используются и при записи, и при последующем оформлении договора.

Расчёт стоимости занятий

Одна из наиболее сложных частей проекта находилась не в интерфейсе, а в billing logic.

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

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

При расчёте учитываются:

• конкретные дни выбранного расписания;
• количество таких дней в месяце;
• официальные праздничные дни;
• неполный первый месяц;
• локальное сахалинское время;
• момент заключения договора.

Например, если занятие должно состояться сегодня, но договор оформляется слишком поздно и клиент физически уже не успеет приехать, это занятие не должно автоматически попадать в стоимость.

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

Таким образом, мы переносили в код не просто формулу:

количество занятий × тариф,

а реальные правила, по которым школа определяет стоимость для конкретного клиента.

Договор без хранения паспортных данных

Для оформления договора пользователь вводит необходимые данные непосредственно на сайте.

После этого сервер формирует PDF из актуального шаблона, подставляя:

• данные клиента;
• реквизиты Михаила;
• выбранное расписание;
• рассчитанную стоимость;
• другие параметры договора.

При этом паспортные данные не записываются в базу.

Они существуют только в оперативной памяти в момент формирования и отправки документа. Сам PDF с паспортными данными сервер также постоянно не хранит.

Юридически используется офертная модель: клиент принимает условия посредством оплаты.

Это позволило минимизировать объём чувствительных персональных данных внутри системы по принципу data minimization.

Работа с персональными данными

При проектировании мы отдельно прорабатывали требования к обработке персональных данных.

В системе реализованы, в частности:

• минимизация хранимых данных;
• разграничение доступа;
• rate limiting;
• антифрод-механизмы;
• резервное копирование.

Используемые технические меры и процессы обработки данных также учитывались при подготовке уведомления в Роскомнадзор совместно с заказчиком как оператором персональных данных.

Оплата первого месяца

После оформления договора клиент сразу получает возможность оплатить первый месяц.

Если в текущем месяце осталось всего одно или несколько занятий, система может предложить оплатить одновременно следующий месяц.

После успешной оплаты сайт самостоятельно фиксирует платёж.

Клиенту больше не нужно отправлять чек Михаилу, а Михаилу — вручную проверять банковские операции.

После подтверждения платежа система понимает, в какую группу записан клиент, и предоставляет соответствующую ссылку.

Таким образом, значительная часть прежней цепочки:

«оплатите → пришлите чек → я проверю → отправлю ссылку»

исчезла полностью.

Оплата последующих месяцев

Для повторных платежей мы намеренно не стали вводить полноценную систему аккаунтов и паролей.

Клиент вводит номер телефона и видит связанные с ним активные договоры, по которым можно провести оплату.

Чувствительные персональные данные в этом интерфейсе не раскрываются.

Такое решение оказалось достаточным для бизнес-сценария и позволило не добавлять регистрацию только ради формального наличия «личного кабинета».

Клиент может самостоятельно выбрать месяцы, которые хочет оплатить.

Свободная сумма оплаты

Полностью жёстко автоматизировать расчёт для школы плавания невозможно из-за специфики региона.

Занятия могут отменяться, например, из-за погодных условий или других обстоятельств.

Поэтому кроме автоматически рассчитанной суммы мы предусмотрели возможность провести платёж на свободную сумму.

Это сознательный escape hatch в бизнес-логике.

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

Напоминания об оплате

Следующая ручная операция — ежемесячные напоминания.

Мы рассматривали использование внешних решений вроде DashaMail или UniSender и обсуждали, нужен ли вообще собственный механизм рассылок.

В итоге по бизнес-требованию Михаила уведомления реализовали внутри системы.

Из административной панели можно запускать массовые email-напоминания вручную или автоматически.

Система ведёт журнал событий и позволяет видеть:

• кому письмо было отправлено;
• какие отправки завершились успешно;
• какие сообщения не удалось доставить.

Административная панель

CMS стала полноценным операционным интерфейсом школы.

Из неё Михаил может управлять:

• клиентами;
• записями;
• договорами;
• платежами;
• взрослыми группами;
• детскими группами;
• сезонными формами записи;
• расписанием;
• стоимостью занятий;
• содержанием договора;
• блогом;
• документами об образовании;
• реквизитами и контактами;
• Telegram и другими каналами;
• сервисным режимом сайта.

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

Одной из задач discovery было определить не только то, что нужно разработать, но и то, за что заказчику платить не имеет смысла.

Мы не стали делать приоритетом:

• сложное SEO-продвижение;
• CRM;
• лид-магниты;
• маркетинговую аналитику;
• сложную многостраничную структуру;
• полноценную регистрацию пользователей;
• автоматизацию редких исключительных сценариев.

Михаил даже отказался от подключения Яндекс Метрики: для текущей бизнес-модели эти данные не влияли на основную задачу.

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

Несмотря на относительную простоту реализации, мы исключили его из scope: два дополнительных товара не оправдывали усложнение продукта и отвлекали от главного пользовательского сценария.

Четыре платёжные интеграции вместо одной

Отдельной частью проекта стала интеграция эквайринга.

Изначально требование Михаила было жёстким: сохранить максимально низкую комиссию, близкую к привычной для него оплате через СБП.

Поэтому окончательная платёжная архитектура появилась не сразу.

Первым вариантом стал Сбербанк QR.

Интеграцию написали, реализовали взаимодействие с API и дошли до тестовых платежей, однако затем банк ограничил работу из-за требований к сайту. Получение разъяснений затянулось из-за недоступности ответственных специалистов.

Следующим вариантом стала ЮKassa — знакомый нам и технически предсказуемый сервис.

Мы убедили Михаила принять, что при выборе банковской карты комиссия может быть выше, чем при СБП. Однако в процессе выяснились дополнительные условия тарификации, которые заказчика не устроили.

После этого протестировали ATOL Pay.

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

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

Поэтому мы перешли непосредственно на API Т-Банка.

Все дополнительные переделки платёжной интеграции выполнили без увеличения стоимости проекта, хотя изначально договором предусматривалась интеграция с ЮKassa.

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

503 на production перед стартом сезона

Даже после полностью успешных тестов интеграция с Т-Банком дала ещё один edge case.

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

Мы локализовали проблему до TLS verification.

Причиной оказалась работа trust chain сертификатов в production-окружении после необходимых изменений сертификатной инфраструктуры.

Проблему исправили, после чего система начала принимать реальные платежи.

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

Когда проблема оказалась не в приложении

После запуска появился ещё более неприятный инцидент.

Часть пользователей в Южно-Сахалинске не могла открыть сайт с мобильного интернета.

При этом приложение, сервер и само соединение с нашей стороны работали штатно.

Из-за выборочного характера проблемы её диагностика заняла значительно больше времени, чем обычный application-level incident.

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

Для бизнеса это уже было не просто технической ошибкой.

По оценке Михаила, около 100 новых и существующих клиентов не могли записаться из-за недоступности сайта.

То есть инфраструктурный incident напрямую блокировал продажи.

В результате мы сменили IP-адрес сервера, после чего проблема исчезла.

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

В итоге сайт стал не маркетинговой оболочкой школы, а основной системой обслуживания клиентов.

Сейчас типовой путь выглядит так:

пришёл на сайт → выбрал расписание → записался → Михаил подтвердил целесообразность записи → клиент оформил договор → система рассчитала стоимость → клиент оплатил первый месяц → получил доступ к своей группе → последующие месяцы оплачивает самостоятельно.

Автоматизированы полностью:

• запись;
• расчёт стоимости;
• формирование договоров;
• фиксация платежей;
• выдача ссылки на нужную группу;
• последующие оплаты;
• email-напоминания.

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

Первые показатели

За первые 10–15 дней одного из новых сезонов через систему прошло:

215 клиентов

129 договоров на сентябрь 2026 года

61 платёж

377 отправленных email

100% зафиксированных платежей прошли успешно

До этого система уже отработала полный летний сезон — июнь и июль.

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

Что изменилось для бизнеса

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

Раньше Михаилу приходилось:

отправить инструкции → получить подтверждение оплаты → проверить платёж → определить группу → отправить ссылку → позднее напомнить о следующей оплате.

Теперь большую часть этой цепочки выполняет система.

Михаил остаётся тренером и владельцем школы, а не оператором собственного мессенджера.

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

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

Next.js · PayloadCMS · PostgreSQL · Docker · nginx · Timeweb · T-Bank API · SMTP

Проект остаётся у нас на техническом сопровождении.