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

Брони и календарь занятости

Основная сложность бронирования не в интерфейсе, а в правилах: минимальный срок, заезд и выезд, пересечения, доплаты за дополнительных гостей, разные тарифы по датам. Если правила живут в голове администратора, двойные брони неизбежны. Я переношу их в сервис: календарь занятости считается на сервере, пересечения блокируются, а изменение тарифа по сезону задаётся в админке. Клиент видит доступные даты и цену по ним сразу, без переписки.

• 1календарь занятости с блокировкой пересечений
• 2тарифы по датам и сезонам
• 3правила минимального срока и доплат
• 4отмена и перенос по заданным условиям
• 5уведомления о подтверждении и напоминание о заезде

Нагрузка в сезон

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

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

Оплата и документы

Подключаю платёжный сервис для предоплаты и полной оплаты, возвраты оформляются по правилам, которые задаёт заказчик. Квитанции и подтверждения формируются автоматически и приходят клиенту. Если в компании работает 1С или amoCRM, настраиваю обмен: клиент, бронь, оплата. Так администратор не вносит одно и то же в два места. Правила возвратов описываются явно и хранятся отдельно от кода, поэтому их можно менять без разработчика.

Отдельно проговариваем правила отмены и возврата, потому что в бронировании они определяют половину спорных ситуаций. Условия задаёт ваша сторона, я переношу их в код так, чтобы клиент видел их до оплаты, а не узнавал при отмене. Автоматически считается только то, что описано явно: срок бесплатной отмены, удерживаемая часть, перенос на другие даты. Всё, что не описано правилами, уходит на решение администратора.

• 1предоплата и остаток суммы
• 2подтверждение брони документом
• 3обмен с amoCRM по обращениям и сделкам
• 4сверка поступлений с бронями

Размещение в сторах

Сборки и метаданные готовлю я, отправляю на проверку и отвечаю на замечания площадок. У App Store и Google Play свои требования к описанию собираемых данных, разрешениям и правилам оплаты, и они периодически обновляются. Поэтому часть правок выясняется уже после первой отправки, а срок прохождения проверки предсказать нельзя, и дат я не обещаю. Аккаунты разработчика оформляются на заказчика. Политику конфиденциальности готовит ваша сторона или юрист.

Условия работы

Цена от 300 000 ₽, точная сумма после разбора сценариев и правил бронирования. Работаю один и удалённо, офиса в Краснодаре нет. Проект идёт этапами: сценарии, сервер и правила, приложение, оплата, подготовка к публикации. Оплата по факту сдачи этапа, на каждом этапе показываю работающий результат. Исходный код, доступы и инструкция по обновлению передаются заказчику. Писать в Telegram @inter1ark или на vitoscarasel@gmail.com.